Suspend/Resume oversight wrt GSM handling
mwester at dls.net
Wed May 14 21:16:18 CEST 2008
Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
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
> | 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