From: David Brownell <david-b@pacbell.net>
To: ncunningham@linuxmail.org
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Oliver Neukum <oliver@neukum.org>, Pavel Machek <pavel@suse.cz>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Patrick Mochel <mochel@digitalimplant.org>
Subject: Re: What PM should be and do (Was Re: Solving suspend-level confusion)
Date: Sat, 7 Aug 2004 17:54:19 -0700 [thread overview]
Message-ID: <200408071754.19448.david-b@pacbell.net> (raw)
In-Reply-To: <1091594872.3191.71.camel@laptop.cunninghams>
> - support for state management of part of the tree (I want to put the
> other devices to sleep at the start of suspending)
Hmm, sounds like maybe you're thinking about something that
I might prefer to think of as a set. Maybe organized by role
("display", "disk array 2", etc) or maybe by something that
monitors device usage (and which might help you by keeping
most things suspended most of the time).
> - support for grouping together a bunch of devices into an arbitrary
> subtree (quiesce that keyboard, screen and storage device - and their
> parents - while I do my lowlevel stuff... okay, now resume them so I can
> save the rest of the image)
OK, that's definitely a set not a tree. And given USB, putting a keyboard
into that a set creates a problem until remote wakeup works through PCI!
Example of a simple tree: a USB flash "disk" as the only device
attached to a laptop. That's actually several devices, something
along these lines:
- PCI device, maybe bound to ohci_hcd
- USB root hub implemented by that driver
- USB devices, at least for device and one interface
- SCSI host implemented by usb-storage
- SCSI disk implemented by various SCSI layers
- block device implemented by SCSI
- maybe a couple partitions
Suspending that device should cause almost all of those to suspend.
If there were another USB device on that root hub, it might not be
possible to suspend the root hub.
> Perhaps the way to achieve the partial tree stuff is to make the code
> for handling device lists more generic, so that there would be groups of
> devices and each group has an dpm_active, dpm_off and dpm_off_irq list
> of its own. Devices could go into a 'main group' by default, and be
> shifted to a different group for operations like the above. Suspending
> and resuming then moves the devices within the lists for the group.
> Parents would only need to be moved in a case like mine, where the main
> group was going to sleep.
Hmm, I'd rather have the lists be dynamically constructed. For example,
"this device and all its children" should be suspended bottom-up,
and resumed top-down Would those groups be there for users to
work with?
And I'm not sure I understand what you mean about changing parents.
After all, a given board will only be wired in one way, and no change
in software can remove constraints like "A must suspend before B"
or "if one of these N devices needs the 48 MHz clock, that PLL must
still be running and so the system can't sleep".
- Dave
next prev parent reply other threads:[~2004-08-08 1:34 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-30 16:44 Solving suspend-level confusion Pavel Machek
2004-07-30 22:39 ` Benjamin Herrenschmidt
2004-07-30 23:06 ` Pavel Machek
2004-07-31 4:02 ` David Brownell
2004-07-31 4:36 ` Pavel Machek
2004-07-31 5:49 ` Benjamin Herrenschmidt
2004-07-31 14:23 ` David Brownell
2004-07-31 17:01 ` Oliver Neukum
2004-07-31 17:51 ` David Brownell
2004-08-01 0:41 ` David Brownell
2004-08-01 1:34 ` Benjamin Herrenschmidt
2004-08-02 16:38 ` David Brownell
2004-08-03 0:38 ` Benjamin Herrenschmidt
2004-08-04 2:28 ` David Brownell
2004-08-04 2:26 ` Nigel Cunningham
2004-08-04 2:53 ` Benjamin Herrenschmidt
2004-08-04 2:52 ` Nigel Cunningham
2004-08-04 4:14 ` Benjamin Herrenschmidt
2004-08-04 4:25 ` Nigel Cunningham
2004-08-04 4:52 ` Benjamin Herrenschmidt
2004-08-04 4:54 ` Nigel Cunningham
2004-08-04 5:03 ` Benjamin Herrenschmidt
2004-08-04 5:05 ` Nigel Cunningham
2004-08-05 10:05 ` Nigel Cunningham
2004-08-05 22:31 ` Nigel Cunningham
2004-08-06 0:39 ` Benjamin Herrenschmidt
2004-08-06 21:30 ` Pavel Machek
2004-08-06 21:29 ` Pavel Machek
2004-08-06 22:27 ` Benjamin Herrenschmidt
2004-08-06 22:37 ` Pavel Machek
2004-08-06 21:26 ` Pavel Machek
2004-08-05 1:29 ` David Brownell
2004-08-05 10:19 ` Nigel Cunningham
2004-08-06 0:32 ` David Brownell
[not found] ` <1091772799.2532.50.camel@laptop.cunninghams>
2004-08-07 22:24 ` David Brownell
2004-08-04 2:56 ` Benjamin Herrenschmidt
2004-08-04 3:30 ` David Brownell
2004-08-04 4:19 ` Benjamin Herrenschmidt
2004-08-04 4:47 ` What PM should be and do (Was Re: Solving suspend-level confusion) Nigel Cunningham
2004-08-04 4:53 ` Benjamin Herrenschmidt
2004-08-04 4:59 ` Nigel Cunningham
2004-08-08 16:54 ` Pavel Machek
2004-08-08 21:55 ` Nigel Cunningham
2004-08-09 8:42 ` Pavel Machek
2004-08-05 18:19 ` Greg KH
2004-08-05 22:14 ` Nigel Cunningham
2004-08-07 0:08 ` Éric Brunet
2004-08-08 19:48 ` Pavel Machek
2004-08-11 21:23 ` Greg KH
2004-08-08 0:54 ` David Brownell [this message]
2004-08-06 21:21 ` Solving suspend-level confusion Pavel Machek
2004-07-31 21:09 ` Benjamin Herrenschmidt
2004-08-02 16:40 ` David Brownell
2004-08-03 0:50 ` Benjamin Herrenschmidt
2004-08-07 23:30 ` David Brownell
2004-08-06 21:10 ` Pavel Machek
2004-08-07 23:23 ` David Brownell
2004-08-08 17:16 ` Pavel Machek
2004-08-06 20:04 ` Pavel Machek
2004-08-07 22:14 ` David Brownell
2004-08-07 23:53 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200408071754.19448.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=ncunningham@linuxmail.org \
--cc=oliver@neukum.org \
--cc=pavel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox