Messages in this thread | ![/](/images/icornerl.gif) | | Subject | What PM should be and do (Was Re: Solving suspend-level confusion) | From | Nigel Cunningham <> | Date | Wed, 04 Aug 2004 14:47:52 +1000 |
| |
Howdy.
On Wed, 2004-08-04 at 13:30, David Brownell wrote: > Me either. But renumbering the PM_SUSPEND_* values would let folk > start discussing what PM should be (and do) without that particular > pressure.
I'll happily give a go at kicking off a new thread along these lines (roughly!).
>From my point of view, I really want the core PM code to provide:
- support for telling what class of device a driver is handling (I'm particularly interested in keeping the keyboard, screen and storage devices alive while suspending). - support for state management of part of the tree (I want to put the other devices to sleep at the start of suspending) - 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)
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.
As far as PM_SUSPEND_* values go, then, I guess I'd like to see:
PM_SUSPEND_LIVE PM_SUSPEND_PAUSED (live but not doing or accepting work, state saved in persistent memory) PM_SUSPEND_DOWN (paused, maybe powered down)
I'd thus be keeping the keyboard etc between LIVE and PAUSED until the image is completely written, and putting other devices in DOWN virtually straight away.
Nigel
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |