lkml.org 
[lkml]   [2009]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch update] Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code)
    On Fri, 12 Jun 2009, Rafael J. Wysocki wrote:

    > On Friday 12 June 2009, Alan Stern wrote:
    > > On Fri, 12 Jun 2009, Rafael J. Wysocki wrote:
    > >
    > > > So, are you suggesting that the core should only check the "all children
    > > > suspended" condition if special flag is set in dev_pm_info?
    > >
    > > Or rather, check it only if the special flag _isn't_ set.
    >
    > Where the default is unset, I guess?

    Yep.

    > But then, what about the resuming of the parents before the device is resumed?
    > Should the parents be resumed regardless of the flag state?

    Yes. In general you should assume a device's parent (and the device
    itself!) needs to be resumed whenever the kernel wants to do something
    with the device. The special flag arises because sometimes it's safe
    to suspend the parent without suspending the device _if_ the kernel
    isn't using the device.

    Imagine an idle disk at the end of a link. We might want to
    autosuspend the link without spinning down the disk. When we have to
    communicate with the disk again, we autoresume the link. (Including
    the case where the communication is a "spin-down" command.)

    > And if so, what's
    > the condition for breaking the recurrence? Surely it's not sufficient to check
    > if the parent is active, because its parent need not be active if it has this
    > special flag set.

    That's a good question. Let's assume that situations like this will be
    handled by the drivers.

    For example, suppose A is the parent of B is the parent of C, and A is
    suspended but B isn't and C is. What happens when somebody wants to
    use C?

    An autoresume request is generated for C. Since C's parent is already
    resumed, the runtime_resume method in C's driver is called. The driver
    has to do some I/O in order to resume C, so it passes an I/O request up
    to B's driver. The request then gets passed up to A's driver. This
    driver knows that A is suspended, so it starts an autoresume of A and
    waits for the autoresume to complete before carrying out the request.

    Then the I/O can go through, so C gets resumed and everything works
    out.

    I don't know how often this sort of pattern will arise. It certainly
    could be used in usb-storage; there would be no difficulty starting an
    autoresume when an I/O request arrives from the SCSI layer below. In
    fact, that is exactly how some early runtime-PM patches for usb-storage
    worked.

    Alan Stern



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