GSM flow-control non-functional on GTA01 (and possibly GTA02)

[Mike (mwester)]

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!).

Thanks,
Mike (mwester)