Re: [RFD] Automatic suspend

[Kyle Moffett]

On Fri, Feb 20, 2009 at 10:56 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> * Introduce /sys/power/sleep that will work like /sys/power/state, but:
>  - First, it will call ->acknowledge() for each driver (via bus types) to
>    check if any of them wants to postpone the suspend (this will prevent tasks
>    from being frozen unnecessarily if it is known in advance that the suspend
>    should not happen at the moment).
>  - Next, it will check the "I_do_not_want_automatic_suspend_to_occur" flag
>    of each process and the suspend will be aborted if it is true for any of
>    them (quite frankly, I think that should be integrated with the freezer,
>    in particular the tasks that have TIF_FREEZE set shouldn't be able to set
>    this flag and it should be checked in the freezer loop for every task with
>    TIF_FREEZE unset).
>  - Next, it will proceed with suspending just like /sys/power/state does (the
>    drivers that missed the opportunity to abort the suspend by returning
>    'false' from ->acknowledge() can still abort the suspend by failing their
>    ->suspend() routines).
>
> Then, the decision making logic will be able to use /sys/power/sleep whenever
> it wishes to and the kernel will be able to refuse to suspend if it's not
> desirable at the moment.

Then, for a userspace process handling input events:

1)  Unset "no-suspend flag"
2)  Poll event device
3)  When the poll returns true, set the "no-suspend flag"
4)  Read the event device and process the event(s)
5)  Go back to step 1

The event driver would responsible for atomically preventing suspend
from the moment a button is pressed until it is actually delivered to
a userspace process.  Since at that time the userspace process will be
preventing suspend, there will be no window in which we could go to
sleep with pending events.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/