Re: What PM should be and do (Was Re: Solving suspend-levelconfusion)

[Benjamin Herrenschmidt]

> 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).

Well, they have to be suspended some way to keep a consistent state in
the suspend image, at least until the pages are snapshoted... Unless
the driver knows how to deal with an inconsistent state (I'm toying
with that for fbdev at least right now)

> - 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
-- 
Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/