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

andrzej zaborowski balrogg at
Mon Apr 28 14:38:43 CEST 2008

On 28/04/2008, Mike (mwester) <mwester at> wrote:
> 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.)

My first idea would be do a similar thing in the sleep.S or in pm.c
(e.g. s3c2410_pm_resume) to be able to read out the data after resume
without waiting for all the drivers before s3c-uart, and store it in a
ring buffer. Busy-waiting there should be better than FIQ. This path
should be taken only if it's asserted that the wake-up is from modem.

Another thing would be trying to put the serial in 9600 bps before
suspend if that's possible.

Please do not print this email unless absolutely necessary. Spread
environmental awareness.

More information about the openmoko-kernel mailing list