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

Mike (mwester) mwester at dls.net
Mon Apr 28 17:18:38 CEST 2008


Andy Green wrote:
> Somebody in the thread at some point said:
> | Andy Green wrote:
> | ...
> |> In practical terms, FIQ on S3C24xx works that you can cherrypick ONE
> |> normal interrupt source and elevate it to "FIQ power"...
> |
> | This problem may well exist on the GTA02 as well (although it has a
> | deeper FIFO, I suspect that will only serve to mask the problem so that
> | in accordance with Murphy's law, it will happen only when correct
> | operation is most needed).  Does the fact that the GTA02 already uses
> | the FIQ preclude this solution for that device as well, or is there some
> | other consideration for shared FIQ use?
> 
> The S3C2442 datasheet has a big NOTE by that register saying to only
> enable one source.  I guess the issue is that the ARM can't deal with
> FIQ reentrancy, it has a single set of FIQ shadow registers for high
> speed context switching: once you started using them if another FIQ
> comes you are in trouble.

:-(  This is unfortunate.

> If I understood it the problem only comes during resume... I guess the
> big question is, is all that is needed to make the problem a long period
> with interrupts off?  If that's all it takes, I would wonder if one of
> the resume handlers is spinning at a bad time, eg, LCM ASIC one has
> mdelay() in there IIRC.

I'm sorry I should have been more clear.  My original supposition was 
that this only occurs during resume, but in fact it is the case that 
resume is merely the most common scenario that sets up for this failure. 
  I have observed it on two other cases to date that are outside of 
resume processing.

The overrun does seem to correlate to times where one would logically 
assume that IRQs may be held off, but I don't have enough data-points to 
  know for certain.

Of course, hardware flow-control is supposed to fix this so that we 
don't have to worry about latency for the serial IRQ -- but that's the 
part that's not working.  So the need is to handle the worst case:

We cannot slow the GSM; it is transmitting at 115200 baud.  The best we 
can do with the S3C2410 UART is to generate the RX IRQ when the FIFO 
reaches 4 characters; that leaves 12 characters before overrun.  That's 
a latency of 1.0 milliseconds -- I'd call that real-time.


So, as I understand it, the FIQ is the only solution to meet this need, 
but the FIQ is already in-use on the GTA02.  I'm not sure where we go 
from here...

> - -Andy

Mike (mwester)




More information about the openmoko-kernel mailing list