Occasional fail to initiate resume by incoming call, easy workaround proposed
fercerpav at gmail.com
Mon Feb 9 20:42:18 CET 2009
Andy Green <andy at openmoko.com> writes:
> 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
> 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.
Hm, sorry, i might be mixing several different issues here. I now see
that you're concerned about reported overruns that is being
investigated now with the help of Michael.
I intepreted you latest message as "there is no known issues wrt hardware
flowcontrol of datastreem between Calypso and SoC". Therefore i
immediatly remembered this bugreport that seems to be valid, related
to flowcontrol and uninvestigated. Sorry for the confusion.
> s3c2442 has 64-deep FIFO, not 16, the thresholds are different and this
> was not reported for GTA02 until post 2.6.24 kernels.
Probably having bigger FIFO makes triggering weird behaviour a lot
> 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?
Sorry for the confusion again.
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com
More information about the openmoko-kernel