Occasional fail to initiate resume by incoming call, easy workaround proposed

Andy Green andy at openmoko.com
Mon Feb 9 20:28:12 CET 2009

Hash: SHA1

Somebody in the thread at some point said:

| Andy, there exists an _open_ ticket with detailed description. It
| doesn't seem that anybody did any additional real-life testing or
| verification as there is nothing except original report. I know
| mwester did huge amount of testing especially with GTA01 where this
| behaviour can be easily triggered and observed.
| Please, don't dismiss it that easily.
| URL (to bug tracker that is not used to track bugs properly) for your
| reference:
| http://docs.openmoko.org/trac/ticket/1376

Well first thanks for not keeping the trac a big secret.

The Trac talks about a behaviour seen by binding s3c2410 UART behaviour
with flow control to the GSM chip.  Due to differences in the CPU UART
behaviour, it's a leap in the dark to claim the GTA02 problem is due to
"multi character" granularity in GSM device.

s3c2442 has 64-deep FIFO, not 16, the thresholds are different and this
was not reported for GTA02 until post 2.6.24 kernels.

'' In AFC, nRTS depends on the condition of the receiver and nCTS
signals control the operation of the transmitter.  The UART's
transmitter transfers the data in FIFO only when nCTS signals are
activated (in AFC, nCTS means  that other UART's FIFO is ready to
receive data). Before the UART receives data, nRTS has to be activated
when its receive FIFO has a spare more than 32-byte and has to be
inactivated when its receive FIFO has a spare under 32-byte (in AFC,
nRTS means that its own receive FIFO is ready to receive data).'' (p11-4
on s3c2442 datasheet about UART).

The GTA02 behaviour seems to revolve around an inserted \00 byte as far
as I can make out, that doesn't seem to be the same behaviour as this
GTA01 issue.

''...it does not appear that the overrun is by some small, constant
number of characters (which might indicate a timing issue in the GSM or
perhaps the hardware between it and the host UART). Instead all
remaining characters in the message being transmitted are lost,
regardless of the length of the message.''

That's not what is being seen with this current issue on GTA02.

Werner says he's eyeballed the code and doesn't see a problem.

Therefore I don't see that there is a "multi character" handshake
granularity in the GSM device from all this.  Do you see how to work
that out from this?

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


More information about the openmoko-kernel mailing list