Hi! > > Arguably, though, this isn't the only possible way to implement a > > mechanism allowing the system to be suspended automatically when it appears > > to be inactive. > > > > Namely, one can use a user space power manager for this purpose and actually > > the OLPC project has been doing that successfully for some time, which clearly > > demonstrates that the Android approach to this problem is not the only one > > possible. Moreover, the kernel's system suspend (or hibernate for that matter) > > code has not been designed to be started from within the kernel. It's been > > designed to allow a privileged user space process to request the kernel to > > put the system into a sleep state at any given time regardless of what the > > other user space processes are doing. While it can be started from within the > > kernel, this isn't particularly nice and, in the Android case, starting it from > > within the kernel requires permission from multiple user space processes > > (given by not taking suspend blockers these processes are allowed to use). > > > > Why is starting suspend from within the kernel not nice? Personally I > think reentering suspend from within the kernel is nicer than being > forced to wake up a user space thread for events that are fully > handled within the kernel (for instance the battery monitor on the > Nexus One). For events that are fully handled within the kernel -- like battery monitor on Zaurus/spitz -- doing wakeup all the way to the userspace is not neccessary. But that's implementenation detail with no impact on user/kernel interface, and we are doing that today. (Or were doing that few releases ago; charging is broken on spitz just now). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
