[lkml]   [2009]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] PM updates for 2.6.33
    On Sun, 2009-12-06 at 23:23 +0800, Alan Stern wrote:
    > On Sat, 5 Dec 2009, Linus Torvalds wrote:
    > > Think of a situation that we already handle pretty poorly: USB mass
    > > storage devices over a suspend/resume.
    > >
    > > > The device tree represents a good deal of the dependences
    > > > between devices and the other dependences may be represented as PM links
    > > > enforcing specific ordering of the PM callbacks.
    > >
    > > The device tree means nothing at all, because it may need to be entirely
    > > rebuilt at resume time.
    > Nonsense.
    > > Optimally, what we _should_ be doing (and aren't) for suspend/resume of
    > > USB is to just tear down the whole topology and rebuild it and re-connect
    > > the things like mass storage devices. IOW, there would be no device tree
    > > to describe the topology, because we're finding it anew. And it's one of
    > > the things we _would_ want to do asynchronously with other things.
    > That's ridiculous. Having gone to all the trouble of building a device
    > tree, one which is presumably still almost entirely correct, why go to
    > all the trouble of tearing it down only to rebuild it again? (Note:
    > I'm talking about resume-from-RAM here, not resume-from-hibernation.)
    > Instead what we do is verify that the devices we remember from before
    > the suspend are still there, and then asynchronously handle new devices
    > which have been plugged in during the meantime. Doing this involves
    > relatively little extra or new code; most of the routines are shared
    > with the runtime PM and device reset paths.
    > As for asynchronicity... At init time, USB device discovery truly is
    > asynchronous. It can happen long after you log in (especially if you
    > don't plug in the device until after you log in!). But at resume time
    > we are more highly constrained. User processes cannot be unfrozen
    > until all the devices have been resumed; otherwise they would encounter
    > errors when trying to do I/O to a suspended device. (With the runtime
    > PM framework this is much less of a problem, but plenty of drivers
    > don't support runtime PM yet.)
    > > We don't want to build up some irrelevant PM links and callbacks. We don't
    > > want to have some completely made-up new infrastructure for something that
    > > we _already_ want to handle totally differently for init time.
    > >
    > > IOW, I argue very strongly against making up something PM-specific, when
    > > there really doesn't seem to be much of an advantage. We're much better
    > > off trying to share the init code than making up something new.
    > If I understand correctly, what you're suggesting is impractical. You
    > would have each driver responsible for resuming the devices it
    > registers. If it registered some children synchronously (during the
    > parent's probe) then it would resume them synchronously (during the
    > parent's resume); if it registered them asynchronously then it would
    > resume them asynchronously. In essence, every single device_add() or
    > device_register() call would have to be paired with a resume call.
    > To make such significant changes in every driver would be prohibitively
    > difficult. What we need is a compromise which gives drivers control
    > over the resume process without making them responsible for actually
    > carrying it out.
    > So consider this suggestion: Let's define PM groups. Each device
    > belongs to a group, and each group (except group 0, the initial group)
    > has an owner device. By default a device is added to its parent's
    > group during registration, but the driver can request that it be
    > assigned to a different group, which must be owned by that parent.
    > During resume, each PM group would correspond to an async task. The
    > devices in each group would be resumed sequentially, in order of
    > registration, but asynchronously with respect to other groups. The
    > async thread to resume a group would be launched after the group's
    > owner device was resumed.
    yes, we've talked about something similar to this before. :)

    Hi, Linus,
    can you please look at this patch set and see if the idea is right?

    If yes, I'll pick them up again and rework a patch set, including some
    good thoughts from Rafael.


    > So for example, the sibling functions on a PCI card could all be
    > assigned to the same group, but different cards could belong to
    > different groups. Likewise for ATA and PCMCIA controllers. Extra
    > cross-group constraints could be added if needed, but there should be
    > relatively few of them.
    > This way drivers can decide which of their devices will be resumed in
    > sequence or concurrently, but they won't have to do any of the
    > necessary work.

    > Alan Stern
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
    > the body of a message to
    > More majordomo info at

     \ /
      Last update: 2009-12-07 05:01    [W:0.046 / U:1.356 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site