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

Brian Swetland
2009-02-13T14:24:09Z

[Matthew Garrett <mjg59@srcf.ucam.org>]
>
> 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?

If we can enable keeping stats (probably as a config option that
defaults off) to help answer the "battery life is down 20% in this
build, are we preventing suspend more than before?" question, this
seems like a reasonable direction to me.

For the case where somebody wants to release the hold on suspend after a
timer expiration, that can be built on top of this, so that's covered.

I think the "what happens when a process crashes and its suspend
inhibits are released" issue still needs some thought -- if say a
background/service process crashes while holding a lock we want to
have the process be able to be restarted by init or whatnot without
having to wait for some other activity. This is a real example we
ran into in the past -- telephony process crashes and the device
doesn't get back on the network until the user presses a key, an
alarm fires, etc.

I suspect this is more sparse than Arve is hoping for, and maybe
I've missed some obvious concern he has.

Brian