lkml.org 
[lkml]   [2010]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] suspend blockers & Android integration


    --- On Fri, 6/11/10, James Bottomley <James.Bottomley@suse.de> wrote:

    > > Do we at least have a clean way that a driver can
    > > reject a system suspend?  I've lost track of
    > many
    > > issues, but maybe this could be phrased as a QOS
    > > constraint:  the current config of driver X
    > needs
    > > clock Y active to enter the  target system
    > suspend
    > > state, driver's suspend() method reports as
    > much.  Then the entry to
    > > that system state gets blocked
    > > if the clock isn't enabled.
    >
    > So in QoS modifications to android patches, the answer is "yes" ...
    > except that the current android patch set didn't actually
    > have this type
    > of wakelock in it.

    Except, we're not talking "wakelock" ... :)

    So ... no, these cases still have no solution.
    (I think that's at least five years now.)


    > The one thing that does look difficult is that these power
    > constraints
    > are device (and sometimes SoC) specific.

    Exactly why they make good examples for
    turning up framework limitations... like
    having overlooked constraints coming from
    various SoC peripherals.

    > Expressing them in a generic way
    > for the cpu govenors to make sense of might be hard.

    Requiring "CPU governors" to be involved in such
    stuff feels a bit off-course to me. At least, if
    the involvement is very deep. The constraints are
    from the integrated peripherals, not (usually)
    from the CPU

    There are plent of places to hang SoC or
    device specific data, once there's awareness
    that without such data, (which PCs hide behind
    ACPI bytecode) the PM framework is missing out
    on support for some desirable low power modes.


    >
    > > (That QOS constraint should be removed when that
    > > driver no longer needs to issue wakeups; that's
    > > not quite the same as "removed by driver.resume().
    >
    > The USB one needs user input, doesn't it,

    I don't quite see that. The drivers get called
    in enough places, and they'll know if the system
    is going to be in a suspend state where they need
    to be partially
    aactive (with various QOS constraints, or they
    can't work.

    > since user hotplug might (or
    > might not) be one of the wakeup sources.

    If it wakes via hotplug, then the driver must
    already Do The Right Thing; what input would
    be needed (Beyond changing the cable config)?

    >
    > James
    >
    >
    > --

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

    \
     
     \ /
      Last update: 2010-06-12 04:47    [W:3.732 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site