GSM flow-control non-functional on GTA01 (and possibly GTA02)

[Mike (mwester)]

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?


Regards,
Mike (mwester)