Re: [PATCH 1/8] PM: Opportunistic suspend support.

Arve Hjønnevåg
2010-05-26T09:54:40Z

On Wed, May 26, 2010 at 2:33 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-05-26 at 11:23 +0200, Florian Mickler wrote:
>
>> There is polling, because the suspend manager in userspace doesn't have
>> the whole picture. i.e. it doesn't know if a suspend will be
>> successfull.
>> So for aggressive suspending as a powersave-feature you need to poll
>> (i.e. retry upon failure). because you don't want to stay unsuspended.
>
> Clearly if it fails, there something to be done, right? So whoever does
> the thing will communicate with the suspend manager that it's going to
> do and has finished doing its thing, at which point it will try again.
>

If you are talking about user-space code here, then that does not
work. Not all kernel events that need to block suspend make it to
user-space.

> That's event driven, not polled.
>
> Also, if you want you can keep the kernel-side auto-suspend side, and
> have the suspend manager clear on !0 and re-establish the auto-suspend
> state on 0.
>
> But you really don't need this device thingy.
>

I'm not sure what you are proposing that we use instead. Both
user-space and kernel code needs to block suspend. If we don't have
suspend blockers in the kernel then user-space needs to poll when a
driver blocks suspend by returning an error from its suspend hook.

--
Arve Hjønnevåg