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

Andy Green andy at openmoko.com
Mon Apr 28 17:47:40 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| 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:

I see.  I understand what you meant about wondering if the GSM side
honours the flow control now.

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

FIQ will typically come in at < 1us latency FWIW.

The FIQ is only lightly used actually, so as not to eat power the bulk
of the time no FIQs occur.  Only when we want to do something like read
the battery state it runs a timer to cause FIQs.  At all other times it
doesn't hurt if the FIQ source is something different since no timer
events will come.

What we could do to enforce a solution is to set the FIQ source to the
UART interrupt when not in use for timer-driven function, but either way
we can check UART interrupt status at the start of the FIQ ISR.  So even
when it is triggered off timer asynchronously to UART activity, we will
be basically polling at 20 - 100us period.

But the other side of it integrating the UART data captured this way
into the normal serial driver architecture might be a bit messy :-)

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgV8ZwACgkQOjLpvpq7dMpHvwCdG1LsxEglXtljfk9YRSHyvDKB
9rMAn1nYEAGqlca03jCkEgy5CzDbG0sy
=QQ2H
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list