Suspend/Resume oversight wrt GSM handling

Mike (mwester) mwester at
Wed May 14 21:16:18 CEST 2008

Andy Green wrote:
> Hash: SHA1
> Somebody in the thread at some point said:
> | 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.
> Huh.

This is the same reaction I got on the IRC conversation.  That reaction 
confused me then, and now I'm even more confused.  Perhaps I'm missing 
something very basic here.

I'll be happy to provide my logic and reasoning for why this is a 
problem, but if there's something else that guarantees this (hardware 
somewhere?), perhaps it we could avoid needlessly discussing something 
that's a non-issue -- what is it that would force the GSM to be 
flow-controlled during suspend/resume processing and while in the 
suspended state?

> | 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!
> Wah I dread to hear why such a low level issue has to take care about if
> we are running Qtopia or not.

The IRC conversation implied that Qtopia uses the modem control signals 
as it prepares for suspend; we would need to worry about that because 
the sum-total content of the serial driver function that handles modem 
control signals for the s3c24xx device is this:

  /* todo - possibly remove AFC and do manual CTS */

> By all means send out a patch on the list and it will be read by at
> least one pair of interested eyes.

Ok, but before we do that, if there is some other reason to believe that 
  the RTS line from the UART to the GSM will automatically enter the 
"flow controlled" state during a suspend, I'd like to know about that - 
it would change the current kernel from "won't work" to "will work most 
of the time" as it relates to this need.

> - -Andy


More information about the openmoko-kernel mailing list