[lkml]   [2005]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] [PATCH] Custom power states for non-ACPI systems

    On Fri, 2005-03-04 at 13:17, David Brownell wrote:
    > On Wednesday 02 March 2005 12:56 am, Pavel Machek wrote:
    > >
    > > If OMAP has "big sleep" and "deep sleep", why not simply map them to
    > > "standby" and "suspend-to-ram"?
    > Or even "cpu idle". Entering power saving modes shouldn't be such
    > a Big Deal. Some of the variable scheduling timeout work has been
    > done specifically with the goal of letting the system use those low
    > power modes more generally, without needing user(space) input to
    > suggest that now would be a good time to conserve more milliWatts.
    > Of course, on systems that don't swap (or swsusp) there may be
    > dozens of different low-power "standby" states. I'm not sure it
    > helps to try labeling them all through /sys/power/files.

    It seems to make a lot of sense to me for us to make a split between
    capability/implementation and policy, and move the policy stuff to
    userspace. Here's the proposal I'm slowly fleshing out:

    Two way communication between a userspace policy manager and kernel
    drivers is implemented via DBus.

    In this scheme, 'kernel drivers' doesn't just refer to the drivers for
    hardware. It refers to anything remotely power management related,
    including code to implement suspend-to-RAM, to disk or the like, ACPI
    drivers or code to implement system power states.

    The policy manager can enumerate devices and inter-relationships,
    capabilities, settings and status information, set and query policies
    and implementation results. The drivers can notify events. This
    communication doesn't use complicated structures or type definitions.
    Rather, all the nous regarding interpretation of the messages that are
    sent is in the policy manager and the drivers. One driver might say it's
    capable of states called "D0, D1 and D3", another (system) states called
    "Deep Sleep" and "Big Sleep". Nothing but the driver itself and
    userspace manager need to how to interpret & use these states.

    Inter-relationships between drivers are _not_ included in this
    information. The policy manager sets policy, the drivers deal with the
    specifics of implementing it.

    The userspace manager can in turn [en|dis]able capabilites and send a
    list of run-time states that the driver can move between according to
    its own logic (eg lack of active children) without notifying the
    userspace manager. This would fit in with your power modes above, even
    to the level of "cpu idle".

    The DBus support would also provide a means by which the userspace
    manager could be notified of events it might be interested in. Again, a
    generic format could be used, with the format depending upon the driver.
    These events might include 'no keypresses in the specified period' or
    'I'm a new driver just loaded'.

    Support for system states works in a similar manner. Capabilities and
    configuration parameters for system states (suspend to ram, deep sleep
    etc) could be registered in a similar manner to the device drivers
    above, but the choice regarding entering them comes from the userspace
    manager. The code implementing the state interacts with drivers using
    the existing driver model which, by definition (it only deals with
    system states), overrides the runtime policy settings previously

    DBus events could also come from userspace, such as window manager
    requesting hibernation or a userspace UPS driver notifying AC loss.

    Drivers could also interact with each other to communicate status
    changes (eg USB drivers notify parent HUB of their removal). This is, of
    course, the more complicated bit. Since this is the implementation (and
    not policy), however, userspace doesn't need to be involved. This
    separation should simplify things. My USB hub driver knows what its
    children are via the driver model. It doesn't need to receive a message
    from userspace to tell it to sleep because it has nothing to do.

    With an implementation along these lines, I think we'll have a good
    basis for getting runtime power management and system states into a
    usable state.


    Nigel Cunningham
    Software Engineer, Canberra, Australia
    Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574

    Maintainer of Suspend2 Kernel Patches

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:10    [W:0.025 / U:11.768 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site