Re: Solving suspend-level confusion

[Nigel Cunningham <ncunningham@linuxmail.org>]

Hi.

On Thu, 2004-08-05 at 11:29, David Brownell wrote:
> On Tuesday 03 August 2004 19:26, Nigel Cunningham wrote:
> 
> > > There's now some partial-tree code in CONFIG_USB_SUSPEND (for
> > > developers only), but jumping from USB into the next level driver
> > > (SCSI, video, etc) raises questions.
> > 
> > I've also done partial-tree support for suspend2 by making a new list
> > (along side the active, off and off_irq lists) and simply moving devices
> > I want to keep on (plus their parents) to this list prior to calling
> > device_suspend. Works well for keeping alive the ide devices being used
> > write the image.
> 
> What I'd need out of the PM framework would be "suspend this subtree",
> and its cousin "resume this subtree".  Where the subtree starts with a
> given device ... and, if it's got a driver, any abstract devices created
> by that driver.  (And their children, etc.)

I've just finished implementing a 'suspend this subtree' patch, which
I'll happily post for comments/testing. I'll try to do that shortly.

> I'm not sure what to think about the desire of "suspend2" to prevent
> a subtree from suspending.  In fact, I'm not at all sure how to even
> interpret a "can't suspend" failure code... device in trouble, likely.

I didn't implement it as devices saying 'can't suspend'. Instead, I
added a layer of abstraction. Imagine the current dpm_active, dpm_off
and dpm_off_irq lists as representing the states of a subtree of the
devices. We pop them into a struct partial_device_tree (device_subtree
better?) and provide facilities for creating and destroying new struct
partial_device_trees, moving a-device-and-its-parents between trees and
merging trees back. We also adjust the current suspend, resume, power-up
and power-down routines so they're tree-aware and set up a
'default_device_tree' that the devices sit in for normal operation.
That's what my patch does. I kept the existing api untouched so that:

device_resume();

is actually a wrapper for

device_resume_tree(&default_device_tree);

Proof of the pudding coming :>

Nigel