On 28/04/2008, Mike (mwester) <[EMAIL PROTECTED]> 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.
