GSM flow-control non-functional on GTA01 (and possibly GTA02)
mwester at dls.net
Mon Apr 28 06:27:55 CEST 2008
Figuring out what's going on with the GTA01 GSM overrun problem has been
an obsession with me for the past week or more. After taking a day or
two this weekend to clear my head, I went back one more time to take a
new look and try some new tests.
Beyond a shadow of a doubt, the flow-control between the GSM and the SoC
is not functioning the way it should.
Specifically, in some certain cases, the GSM fails to get the signal to
cease transmitting data to the host UART, or it fails to respond to that
signal in a timely fashion, resulting in the overrun of the UART's FIFO,
and loss of data. While this is possibly the result of the hardware mux
between the UART and the GSM on the GTA01, or even a flaw in this
particular version of the S3C2410 SoC, one needs to consider that it
might well be the GSM module that is at fault, in which case this would
affect the GTA02 as well.
(I'll be happy to bend anyone's ear for hours on everything that has
been done to test and investigate in order to come to this conclusion,
but I'm trying to keep this email brief and to-the-point!)
So, we need a solution. Some of the things I've tried have made it
better (it doesn't overrun quite so often), but not fixed it. In order
to do so, several possibilities come to mind, but a little guidance from
the kernel experts here would be welcome.
A) Can we simply bump up the priority of the RX IRQ for port 0 to some
very very high value? Is there a guarantee in terms of latency for IRQs?
B) Can we use a FIQ for this? I'm envisioning an FIQ handler that does
nothing other than empty the FIFO into a small kernel ring-buffer, and
then signals the standard UART driver to read data from that ring
buffer. (Is it possible to logically connect both the normal RX IRQ and
the FIQ together, so that the FIQ runs, and the IRQ is also triggered?
This would eliminate the need for notification.)
C) Or is any messing around with the serial port driver code just a case
of "putting lipstick on a pig" -- is it time to write a native
high-speed, low-overhead fixed-purpose driver (/dev/gsm0, for instance)?
This can't be the first time someone with this or a similar SoC has run
into a recalcitrant device or even a device with no flow control at all
-- any pointers to pre-existing patches or drivers? (Google comes up
with 10,000 useless links; I'm not even sure what the right keywords
would be to find such a driver!).
More information about the openmoko-kernel