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.)
- Suspend/Resume oversight wrt GSM handling Mike (mwester)
-
