Andy Green <[email protected]> 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:[email protected]
