RFC: GSM flowcontrol handling, GTA01 and GTA02
mwester at dls.net
Thu Jun 5 06:20:55 CEST 2008
Werner Almesberger wrote:
> Mike (mwester) wrote:
>> 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) ?
Actually, I'm not even that far along. I'm only referring to the GTA0x-specific
implementation that I put together -- it does exactly what we need for the GTA01
and GTA02, but nothing more. The s3c24xx serial driver has absolutely no code
to manage RTS and CTS at all. So as written, the patch I put together would not
be accepted upstream since it is not complete nor does it completely follow the
expected behavior (for example, it leaves (and actually relies on) crtscts mode
being set *while* we override the RTS signal).
One could fix all of that, I expect -- by adding full support for the RTS and
CTS signals to the driver, and then addressing the resulting potential race
conditions that, as you described in detail, will result. But frankly, I don't
see that as a good use of time when we can just leave the serial driver
untouched and accomplish the same end goal in neo1973_pm_gsm.c. All we really
want is to leave the UART in auto-flowcontrol mode, but override the RTS line by
switching it to GPIO mode. A dozen lines of code in neo-specific source, versus
some unknown amount of code with sweeping impact to all users of s3cx24xx
devices? -- I've switched from my original position to support the more
practical solution :-)
>> 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.
It's easy to remove the sysfs entry; that's a half-dozen lines of code in
neo1973_pm_gsm.c that can be pulled out at any point. But I'd love to hear the
opinion from the folks working on the user-space stuff, especially the next
generation replacements for neod and gsmd -- do they need anything from the
kernel, and if so, how would they like to see it? Who was going to use the
wakeup reason interface, and is the GSM wakeup one of those of interest?
> - Werner
More information about the openmoko-kernel