RFC: GSM flowcontrol handling, GTA01 and GTA02

Werner Almesberger werner at openmoko.org
Wed Jun 4 09:26:43 CEST 2008

Mike (mwester) wrote:
> Thanks for your feedback - I was actually kinda wondering when you would 
> find this hairball of patches and comment on it!

I've taken some time off for the last three weeks, hence the silence :)

> 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

Hmm, you mean that the ugliness is in the semantics of having crtscts
set (thus telling the serial subsystem that we want it to be in charge
of handling RTS) _and_ TIOCMBIx'ing TIOCM_RTS (thus changing RTS
"manually", hoping that the serial subsystem won't override this in
the next microsecond) ?

That looks twisted indeed. What we'd basically need is an atomic way
for turning off crtscts _and_ clearing RTS.

We'd need this for avoiding race conditions, as outlined below. If it
wasn't for that, I think just making sure the serial driver clears RTS
when it's about to suspend should be sufficient.

One not-so-pretty approach could be to approximate atomicity in user
space by executing the "turn off crtscts" and "clear RTS" sequence
under real-time constraints, and hope that we're quick enough to not
lose any data. Not sure what the odds are.

One could also argue that the driver should always make sure that a
"normally responsive" peer will not lose data when flow control is
enabled and we suspend. One could make this configurable.

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

Ah, right, I forgot this one. So I guess one way to avoid race
conditions here is then:

- clear RTS

- wait for the maximum time until the modem would respond to an RTS

- wait for the maximum time until any data that may have been sent
  before the modem reacted to RTS will have been retrieved from the
  UART hardware

- check if we've received any new data into the kernel's serial buffer
  or if we have a modem interrupt. If not, suspend really.

Does this sound right ?

If yes, and if

- we can put the onus of making sure suspend doesn't lose data on the
- the modem does indeed respond quickly to RTS being cleared,

then I think all we need is to check at the end of the suspend sequence
if we have an interrupt or undelivered data, with no further
special-casing needed in the serial driver.

> Or, we could signal both, I 
> suppose, with multiple asterisks in the wakeup reason?

That looks like the most logical solution, yes.

> Perhaps we really don't need to worry about this at this time

Yeah, I think the wakeup reason isn't something an application should
actually try to make sense of. Since many of the events there could
happen while suspended and while awake, there must be a mechanism to
signal that event already. So this mechanism should just signal it
after the resume. Anything else is likely to lead to race condition hell.

- Werner

More information about the openmoko-kernel mailing list