lkml.org 
[lkml]   [2009]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFD] Automatic suspend
    On Tue, 17 Feb 2009, Rafael J. Wysocki wrote:

    > Phase 1: I agree that system-auto-suspend-on, system-auto-suspend-off would be
    > useful, but I don't like the wakelocks interface. Do you think there is an
    > alternative way/mechanism of doing this?

    I rather like the suggestions Matthew Garrett has been making. They
    show how to improve the wakelock interface without losing any function.

    Really, the idea behind wakelocks comes down to the question of how to
    determine when the system is sufficiently idle to go into auto-suspend.
    There may be occasions when no task is runnable but userspace knows
    that the system should not go to sleep because some work will be done
    in the near future. (Arve's example of a non-empty input buffer is
    such a case.) How should userspace let the kernel know whether it's
    okay to suspend at these times? That is the problem userspace
    wakelocks are meant to solve.

    Kernel wakelocks are a separate matter. They are more like a form of
    optimization, preventing the kernel from starting an auto-suspend when
    some driver knows beforehand that it will return -EBUSY.

    > Phase 3: Probably explicit control left to open/close.

    While that's generally a good idea, it's important to recognize that
    some devices should be runtime-suspended even while they are open.
    Basically, any device that is "always open" falls in this category.
    Some examples are the screen, the keyboard, the mouse, and disk drives.
    And of course, some of these things already have runtime power
    management.

    Alan Stern



    \
     
     \ /
      Last update: 2009-02-18 12:23    [W:3.548 / U:0.636 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site