Bug#640391: ark3116 driver regression: oscilloscope shows no transmission
On Mon, Oct 03, 2011 at 09:45:23AM +0200, Bart Hartgers wrote:
> 2011/10/3 ael <law_ence.dev@ntlworld.com>:
> >
> >
> > Under the old working kernel, I saw packets in both directions.
> > For the record, the gps tx line was swinging between +5.6V and -5.4V,
> > while the ark3116 board was driving the gps rx line between 0V and 3.2V.
> >
> >
> > But under kernel 3.0.0-1, I could not get the 'scope to trigger
> > on either line, nor could see any activity.
> >
> > So my conclusion is that the module is somehow setting the ark3116
> > into a mode whereby it cannot transmit if only the tx & rx (plus
> > grnd=pin5) are connected. Whereas the old version of the module
> > sets it up so that this is possible. Agree?
> >
> > So rather than the gps failing to reply, it seems that the ark3116
> > never sends anything.
> >
>
> Hi ael,
>
> Excellent work! Thanks a lot.
>
> Initially I suspected either somekind of problem between the USB and
> UART parts of the ark3116, or some handshaking mismatch, but from your
> experiments I get the impression that the ark3116 is more or less
> switched off on the 9-pin side. The fact that there is no response by
> the 3.0-kernel to grounding cts is unexpected. There should be a
> response to that, even if the actual transmissions are blocked by
> handshaking.
>
> The ark I have works with 0 and 3.3V, while RS232 uses -12 and +12 or
> so. Usually there is a level-shifter that converts one into the other.
> Maybe that part somehow gets disabled by the new driver.
Yes, I was a bit surprised to see only 0V and 3.2V - but that was on
the working kernel, and the gps saw the data properly, so that
level shifting doesn't seem to be necessary with the garmin, at least.
So the old working version wasn't level shifting, so that alone
can't be the new problem. I wouldn't be surprised if most "modern"
uart circuits actually use edge detection to avoid level problems,
but I am only guessing.
>
> There are some registers in the ark of which it is not clear what they
> do. I copied the values and indices from the windows driver for my
> ark, but perhaps there is something more suble going on. I'll take
> another close look at the old and new driver and see if I can find
> anything.
Ah. I had assumed that you had a data sheet. I hadn't got around
to searching for one: sounds as if I needn't bother.
> If I find something that way, would a patch against 3.0 be okay for
> you? Alternatively, I can make a sort of stand-alone buildable version
> of the driver that you can just 'make' and 'insmod', provided you have
> the right tools/package installed, if that is more convenient for you.
I am used to compiling my own stock kernels, but on this netbook
I have limited tools installed. I think debian have a special
module-compile-and-install package which I have never used. I will
have to look into it.
While git.kernel.org is still down, I guess I will need you to
send me the whole module, or I can do a git-pull if you have your
own server.
Otherwise, if it is not too much trouble, and make and insmod package
might be easier. Not sure without looking...
Best of luck with tracking this down.
ael
Reply to: