Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Matthew Garrett <mjg59 <at> srcf.ucam.org>
Subject: Re: [PATCH 01/13] PM: Add wake lock api.
Newsgroups: gmane.linux.power-management.general
Date: Friday 13th February 2009 14:06:54 UTC (over 8 years ago)
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 | [email protected]
 
CD: 30ms