|| ||Matthew Garrett <mjg59-AT-srcf.ucam.org>|
|| ||Uli Luckas <u.luckas-AT-road.de>|
|| ||Re: [PATCH 01/13] PM: Add wake lock api.|
|| ||Fri, 13 Feb 2009 14:06:54 +0000|
|| ||"swetland-AT-google.com" <swetland-AT-google.com>,
|| ||Article, Thread
On Fri, Feb 13, 2009 at 11:55:06AM +0100, Uli Luckas wrote:
> On Friday, 13. February 2009, Matthew Garrett wrote:
> > I dislike the kernel-side use of wakelocks. They're basically equivalent
> > to a device returning -EBUSY during the suspend phase, which is
> > something that can be done without any kernel modifications.
> That's absouletely wrong. With wake locks, you are in a pre suspend state and
> stay there until all wakelocks are released. Then you go to sleep.
> With -EBUSY the kernel gives up on suspend until some source triggers it
> again. When exactly should suspend then be retried?
Ok, so let's think about this differently. What we want is simply for
drivers to be able to block an automatic suspend. For performance
reasons we want to keep track of this state without calling into the
entire driver tree. Now that the userspace API can automatically clean
up after itself, why is this not just a simple counter? Kernel API would
be something like:
(input queue is emptied)
perhaps using the device struct or something as a token for debug
purposes. Userland ABI would then be a single /dev/inhibit_suspend,
with the counter being bumped each time an application opens it. It'll
automatically be dropped if the application exits without cleaning up.
This seems simpler and also avoids any arguments about the naming
scheme. What am I missing?
Matthew Garrett | email@example.com
to post comments)