RFC: GSM flowcontrol handling, GTA01 and GTA02
werner at openmoko.org
Wed Jun 4 03:14:21 CEST 2008
Mike (mwester) wrote:
> A mechanism is required that ensures that the GSM modem wakeup is handled
> correctly and completely by the kernel, for both the GTA01 and GTA02
First of all, let me remark that I'm impressed by your analysis of this
extremely tricky issue. I'm actually a bit overwhelmed by the amount of
information you dug out ;-) So I hope my comments below don't point in
directions that you've already explored and discarded.
In this thread, issues with crossing component boundaries have been
mentioned. So I'm trying to suggest ways how such dependencies could
perhaps be avoided by expressing them as solutions to more general
> B) The preferred means for user-space programs to signal the kernel that
> the GSM should be forcibly flow-controlled in the fashion described above
> will be for the user-space program to make use of the TERMIO mechanism on
> the serial port to assert and de-assert RTS.
Wouldn't it make sense to clear RTS on suspend in general, when CRTSCTS
is set ? So there would be no need for special case handling. Perhaps
something to check with Ben ?
> C) From a practical point-of-view (neither gsmd nor qtopia presently use
> the TERMIO mechanism, and it is also useful for debugging purposes), a
> sysfs-based mechanism should exist to permit user-space to both determine
> the current status of the forced flowcontrol, and to enable or disable
> this forced flowcontrol. This mechanism can be easily used from apmd, for
Hmm, that seems a bit ugly. If we can avoid making a special case out
of this (as explained above), do we really need this functionality ?
> D) A mechanism-of-last-resort would be desirable; this would be triggered
> during suspend by the GSM power-management driver to automatically force
> flow-control if no other mechanism has done so.
But that would be a configuration error anyway, wouldn't it ?
If there are any bugs in gsmd, Qtopia, or the init scripts, we should
fix them there, not in the kernel, no matter how tempting this may
> E) If an interrupt occurs after one of the above mechanisms forcibly
> flow-controls the GSM but before the system has actually completed the
> suspend process, the suspend process should detect that this has
> happened, and abort the suspend.
Does this need to be conditional on flow-control ? I think if a GSM
interrupts occurs while we're about to suspend, we want to get out of
suspend anyway, no matter what happened with flow control.
> F) Upon resume, the value of the GSM interrupt counter should be made
> available to user-space via the sysfs. This flag may be useful to the
> application stack to provide priority to the program managing the GSM,
> for example. Note that the wakeup-reason recorded in sysfs (added by a
> recent kernel and uboot patch) may often serve this same purpose -- but
> not always.
We could of course change the semantics of the wakeup reason, so that
it also reflects the reason why we didn't even suspend. Thus, no new
mechanism would be needed.
This also makes sense for the application triggering the suspend - it's
better if it doesn't have to guess whether the suspend request was
actually honored or not.
More information about the openmoko-kernel