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

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


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

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




More information about the openmoko-kernel mailing list