Re: [PATCH 01/13] PM: Add wake lock api.

[Matthew Garrett <mjg59@srcf.ucam.org>]

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 arrives)
inhibit_suspend();
(input queue is emptied)
uninhibit_suspend();

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 | mjg59@srcf.ucam.org