lkml.org 
[lkml]   [2011]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
    On Fri, 14 Oct 2011 12:00:59 -0400 (EDT) Alan Stern
    <stern@rowland.harvard.edu> wrote:

    > On Fri, 14 Oct 2011, NeilBrown wrote:
    >
    > > Hi Rafael,
    > >
    > > What do you mean by "too complicated to use in practice"? What is you
    > > measure for complexity?
    > > Using suspend in a race-free way is certainly less complex than - for
    > > example - configuring bluetooth.
    > > And in what way is it "inadequate for other reasons"? What reasons?
    > >
    > >
    > > The only sane way to handle suspend is for any (suitably privileged) process
    > > to be able to request that suspend doesn't happen, and then for one process
    > > to initiate suspend when no-one is blocking it.
    >
    > One of the things Rafael didn't mention is that sometimes a kernel
    > driver needs to prevent the system from suspending. This happens when
    > recharging over a USB connection.
    >
    > There's no simple way for such a driver to communicate with a power
    > daemon. The driver has to use something like the wakeup mechanism --
    > but currently that mechanism is optional.
    >
    > Alan Stern

    Certainly I don't expect a kernel driver to communicate directly with a
    user-space daemon. It communicates indirectly through the wakeup_source
    mechanism.
    If user-space wants to block suspend, it talks to the suspend daemon (power
    manager) some how (dbus, lock files, sockets, signals, whatever).
    If the kernel wants to block suspend, it activates a wakeup_source (aka
    caffeine source) which the suspend daemon notices via /sys/power/wakeup_count.

    But you say this wakeup mechanism is optional .... I don't see that.

    It is implemented in drivers/base/power/wakeup.c which is included in the
    kernel if CONFIG_PM_SLEEP which is defined as

    config PM_SLEEP
    def_bool y
    depends on SUSPEND || HIBERNATE_CALLBACKS

    which seems to mean "enable this unless we don't have suspend and we don't
    have hibernate".

    So it seems that the only time we don't have the wakeup mechanism, we also
    have no risk of ever going to sleep.

    What exactly where you saying was "optional"?? I don't understand.

    NeilBrown
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2011-10-14 23:09    [W:0.022 / U:32.024 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site