RFC: GSM flowcontrol handling, GTA01 and GTA02

Mike (mwester) mwester at dls.net
Wed Jun 4 07:20:50 CEST 2008

Werner Almesberger wrote:
> 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.

Thanks for your feedback - I was actually kinda wondering when you would find 
this hairball of patches and comment on it!  I continue to work on this and will 
have some patches to cleanup the worst of these issues by the end of this week, 
I expect.

> 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 ?

Doing this automagically in the suspend/resume handlers for the serial driver 
makes a lot of sense to me; this will actually be completely adequate to solve 
the general problem for many devices.  It doesn't quite do the job for the GSM, 
however (it leaves open the possibility of missed messages from the GSM -- see 

Running the idea past Ben for some advice would be worthwhile.  However, your 
comment (below) on not fixing user-space bugs in the kernel may apply to this...

>> 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 ?

Can I criticize my own RFC? :)  After consideration, I am convinced that I 
screwed up on that one.  To use the TERMIO mechanism to "hijack" the modem 
control functionality as I described in B, and implemented in the patch, is not 
quite right.  It certainly works to solve the problem, but it's actually a 
subtle perversion of the documented intent of the interface.  So that part of 
the RFC and the patches will never be accepted upstream, regardless of how 
elegant I might think the user-space/kernel interaction would be!

Further, there seems to be no user-space implementations that currently do this; 
no GSM interface code (gsmd) currently running uses any technique, and I can 
find no trace that the modem control lines are manipulated by other 
vendor-specific GSM code in Qtopia, for example.  So, since my preferred 
solution (TERMIO mechanism) won't ever make it upstream, and nobody actually 
implements that in user-space anyway, it seems that the sysfs-based solution is 
the one that wins by default (as ugly as it might be (but keep in mind that 
user-space apps are already grubbing about in /sys to power-on and enable the 
GSM anyway, one more /sys file to manipulate won't make it that much worse)).

>> 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 :-)

Yes, this code needs to go.  A few simple apm scripts to manipulate the sysfs 
file described in C replaces this kernel code.  And even if you didn't want to 
do anything with apm in user-space, a better way to implement a fall-back 
solution is to do it in the suspend/resume handler for the serial driver, as you 
noted above.

Further tests and experiments this week prove that the horrible patch for the 
GTA01 overrun problem (which was the original need that drove this patch) needs 
to be removed as well; the horrible patch is actually no more reliable in fixing 
the problem than is a user-space workaround -- so until a better solution is 
found, we should stick with the user-space workaround instead.

>> 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.

If we do not have flow-control forced on the GSM from the time when the 
user-space app is frozen until we suspend, then the serial driver may simply 
read the data from the GSM -- and we'll get no GSM interrupt at all.  The data 
won't be lost; it just won't be picked up by the user-space process until the 
phone resumes for some other reason - which would be far too late of course. 
This is why we need to have a user-level task somewhere flow-control the GSM 
just before suspend freezes processes and begins suspending drivers.

>> 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.

I'll leave how we signal this to user-space open for further discussion.

For the first case I concur.  If we abort the suspend due to the GSM 
interrupting, then there is no other wakeup reason -- we might as well just tell 
  user-space that the GSM woke us.  The only case that concerns me is the 
(admittedly unlikely) case where we get a GSM interrupt while we're in the 
process of resuming for some other reason.  Do we wish to overwrite the real 
reason for the wakeup, or do we leave the real wakeup reason in place?  If we 
leave the real wakeup reason in place, then we cannot provide userspace with the 
convenience flag to signal that the GSM is waiting with something important to 
say.  On the other hand, if we overwrite the wakeup reason, then we have made a 
defacto prioritization in the kernel as to which event we feel is more 
important.  I'm not sure we should be doing that in the kernel.  Or, we could 
signal both, I suppose, with multiple asterisks in the wakeup reason?

Perhaps we really don't need to worry about this at this time -- we can just 
omit exposing this flag to sysfs until we can sort it out.  It's really there 
for future convenience.  I envision a wonderful world where we resume a minimum 
number of drivers, then based on the wakeup reason userspace can determine if we 
need to resume the display, and/or the audio, or whatever else.

> Thanks,
> - Werner

Mike (mwester)

More information about the openmoko-kernel mailing list