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 > devices.
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 problems. > 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 > example. 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 seem :-) > 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. Thanks, - Werner
