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

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
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.  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.  But there can be funky dependencies and it
means work on kernel side to make any userspace interface to it smart.
If we go for actually reusing the suspend and resume callbacks, work
will also be needed messing with them.  But for sure Cesar's (IIRC) idea
is very cool and useful and this work will be valuable.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh3NoUACgkQOjLpvpq7dMoJnACePWVADGvYmEC+xx0mZxHbDtI+
nYcAn0l+ZnsXAQDXM4CDdC0CsTusFSXF
=iJc1
-----END PGP SIGNATURE-----