GSM flow-control non-functional on GTA01 (and possibly GTA02)
mwester at dls.net
Mon Apr 28 16:39:33 CEST 2008
andrzej zaborowski wrote:
> My first idea would be do a similar thing in the sleep.S or in pm.c
> (e.g. s3c2410_pm_resume) to be able to read out the data after resume
> without waiting for all the drivers before s3c-uart, and store it in a
> ring buffer. Busy-waiting there should be better than FIQ. This path
> should be taken only if it's asserted that the wake-up is from modem.
I've already implemented a similar technique that shortly after resume
is complete has the driver release the GPIO holding the GSM
flow-controlled, and enters a tight busy-wait loop on the UART to read
the initial burst of data.
This resolves the overrun problem on resume for the vast majority of
cases -- but not all. The other observed cases occur outside of the
resume process entirely.
> Another thing would be trying to put the serial in 9600 bps before
> suspend if that's possible.
:-( Alas, this question has been asked before (although in another
context), and the answer IIRC was "impossible". There are other GSM
modules on the market that have the ability to change speed, and doing
so would not only solve this problem, but it would be key to resolving
an issue with another power-management project being worked on by
another community member. Perhaps it would be worth having one of the
Openmoko GSM team member revisit this?
More information about the openmoko-kernel