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

[Paul Fertser]

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

> 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