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