lkml.org 
[lkml]   [2014]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 1/3] PM / sleep: Flag to speed up suspend-resume of runtime-suspended devices
    On Thu, 8 May 2014, Rafael J. Wysocki wrote:

    > Well, no.
    >
    > The reason why that doesn't work is because ->prepare() callbacks are
    > executed in the reverse order, so the perent's ones will be run before
    > the ->prepare() of the children. Thus if ->prepare() sets the flag
    > with the expectation that ->suspend() (and the subsequent callbacks)
    > won't be executed, that expectation may not be met actually.

    That's true also if the flag gets set in ->suspend(), isn't it? A
    driver may set direct_resume in its ->suspend() callback, expecting
    that the subsequent callbacks won't be executed. But if a descendant
    hasn't also set its flag then the callbacks _will_ be executed.

    > So I'm going to do what I said above. I prefer it anyway. :-)

    In your most recent patch (and in the earlier ones too), after you call
    dev's ->suspend() routine, if dev->power.direct_resume isn't set then
    you clear dev->parent->direct_resume. But what good will that do if
    dev->parent's ->suspend() routine turns the flag back on when it gets
    called later?

    I can think of two ways to make this work.

    Expect subsystems and drivers to set the flag during
    ->suspend(). Turn on the flag in every device during
    device_prepare(). Then in __device_suspend(), remember the
    flag's value and turn it off before invoking the callback. If
    the flag is on again when the callback returns, set the flag
    back to the remembered value. If the flag ends up being off
    then turn off the parent's flag.

    Expect subsystems and drivers to set the flag during
    ->prepare(). Whenever a callback returns with the flag not
    set, clear the flag in all of the device's ancestors.

    Both are somewhat awkward, and both involve turning the flag off after
    the callback has turned it on.

    Also, how do you expect direct_resume to work with the PCI subsystem?
    Will the PCI core set the flag appropriately on behalf of the driver?
    If the core does set the flag, will it invoke the driver's ->suspend()
    callback or skip the callback? If it invokes the driver's callback but
    leaves the device in runtime suspend, what happens if the driver
    expects the device always to be at full power when its ->suspend()
    routine runs? If the core skips the driver's ->suspend() callback,
    what happens if one of the device's children did not set direct_resume
    and so the later PM callbacks do get invoked?

    Several of these questions are a lot easier to answer if the flag gets
    set during ->prepare() rather than ->suspend().

    Alan Stern



    \
     
     \ /
      Last update: 2014-05-09 04:41    [W:3.821 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site