Re: Attempted summary of suspend-blockers LKML thread, take three

Pavel Machek
2010-08-14T10:41:30Z

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