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)
