backlight device, suspend/resume... / Cesar's power handling

andrzej zaborowski balrogg at
Fri Jul 11 16:09:00 CEST 2008

2008/7/11 Andy Green <andy at>:
> Hash: SHA1
> Somebody in the thread at some point said:
> |> I'm not certain which position you are advocating. I disagree that
> userspace
> |> is too late to check certain conditions. In fact, I would say that only
> |> userspace has all the necessary information to make such a determination.
> |
> | All necessary information can be passed on to u-boot or kernel before
> | suspending so it can make the correct decision upon waking up and
> | reading what the modem has to say. But I kind of agree that with
> | TS07.10 muxing enabled, the decoding is a bit heavy for u-boot/linux,
> | especially considering there's no TS07.10 in kernel still.
> For sure the GSM semantic stuff does belong in userspace I think, we
> shouldn't take that on in kernel side.  It can decide to do massive UI
> actions like set up a call or start ringing or whatever.

Definitely yes, the only thing kernel is really good at is going back
to suspend - whenever the decision is different you need to finish
resuming and let userspace handle it. But everyone is right that it's
ok to let the userspace make that decision and handle all cases.
Afterall there is a rather fine-grained control of wake-up sources
(through irq masking, and through unsolicited responses enable/disable
in AT) so the going back into suspend should occur rarely?  I
understand the potential use is CBs, which can be very frequent on
some networks, but I take it's only potential as they don't normally
have any information worth alerting the user. Plus you can subscribe
to only specific CB channels.

> But already
> that userspace code has to block itself one way or another until new
> traffic comes of interest, or it wants to do something itself under a
> timer or other event.
> Accepting that if we woke on GSM for example, we must then resume enough
> to unfreeze userspace processes -- complete resume -- and allow
> userspace handling of whatever happened (it will just see new GSM UART
> traffic come).  But if we know we woke from non-user interaction cause,
> it should be open to us to go straight back to sleep again if we are
> told that the "handler" for the cause goes idle after dealing with it.
> GSM is just one input into wake, we can also wake from motion sensors
> and so on, so a generic "oh, I saw you just woke for me, but actually, I
> just noted it and you can go back to sleep now" interface is needed.
> Because we use Carsten's Daemon, he really has to take care about this
> now.  Hmmm, another Pina Colada.
> | Another fun idea is: shut down and resume all the hardware manually
> | from the userspace daemon with sysfs writes. This way we can resume
> This is what I wrote yesterday, I believe it's actually Cesar's (of
> cpufreq fame) idea IIRC.

Uh I came to rely too much on gmail thread handling, which always gets
horribly confused on this particular list due to constant subject line
changes (my guess). So I'm too often answering to only a part of a
thread thinking nothing more had been said already.

More information about the openmoko-kernel mailing list