Messages in this thread | | | Date | Sat, 14 Aug 2010 12:41:30 +0200 | From | Pavel Machek <> | Subject | Re: Attempted summary of suspend-blockers LKML thread, take three |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |