Suspend/Resume oversight wrt GSM handling

Mike (mwester) mwester at dls.net
Wed May 14 16:55:29 CEST 2008


Perhaps I'm wrong, and a solution is already being worked somewhere -- 
but it seems that there remains a potentially-serious oversight with 
regard to the handling of the GSM during suspend/resume.

The vision (as expressed in the wiki and other places) is that the GSM 
will be forcibly flow-controlled during suspend.  This will result in 
the GSM causing an interrupt on one of the GPIO lines when it has data 
to send.  The interrupt will wake the host CPU, and everything Just 
Works(tm).

The missing part is that the current kernel lacks a means to ensure that 
the GSM is forcibly flow-controlled while suspended.

I have a multi-faceted solution for this coded and working on the GTA01 
with the current gpsd.  Extending it to work with Qtopia seems easy, as 
soon as I can get a current Qtopia image to build for me.  But I do not 
wish to re-invent the wheel if this is not of interest currently, or if 
OM has another project working on a solution!  :)  So let me know if 
this is something we should discuss, or if I should just wait for the 
"blessed" solution!

Thanks,
Mike (mwester)

(Any behavior that seems to indicate that it works correctly with the 
current drivers is purely by accident (relying on undocumented 
behavior), and with potential for race conditions.  There was a short 
discussion on IRC on this, and from that I am concerned that nobody has 
really examined the serial driver to discover just how full of holes it 
is.  Additionally, the recent change to disable LL debug on 
suspend/resume will result in behavior changes wrt to this, although I 
can't say if it will be good or bad at this point.)




More information about the openmoko-kernel mailing list