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@xxxxxxxxxxxxx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
