Re: [PATCH -mm] PM: Change ordering of suspend and resume code

[Stefan Seyfried <seife@suse.de>]

Hi,

On Sun, Dec 17, 2006 at 06:58:15PM +0100, Rafael J. Wysocki wrote:
> Hi,
> 
> As indicated in a recent thread on Linux-PM, it's necessary to call
> pm_ops->finish() before devce_resume(), but enable_nonboot_cpus() has to be
> called before pm_ops->finish()
> (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
> For consistency, it seems reasonable to call disable_nonboot_cpus() after
> device_suspend().
> 
> This way the suspend code will remain symmetrical with respect to the resume
> code and it may allow us to speed up things in the future by suspending and
> resuming devices and/or saving the suspend image in many threads.

Good. A thread to do progress bars :-)
 
> The first patch changes the ordering of the suspend-to-RAM code and is
> untested, because my boxes continue refusing to resume from RAM for other
> reasons.  If anyone can, please do me a favour and test it.
> 
> The second patch changes the ordering of the built-in suspend-to-disk code,
> and the last two patches modify the swsusp userland interface code
> accordingly.  As far as the last patch is concerned, I've decided to change
> the existing ioctls, so that the patched kernel works with the "old" userland.
> I don't think this change breaks anything of importance, but if it does, we
> can just add (yet) another ioctl to set the platform mode, although in that
> case the userland would have to be changed as well.
> 
> All of the patches are against 2.6.20-rc1 and should not be used with any
> earlier kernel.

I'll test them, but probably not this year :-(
I'll only get to it during the first week of January.
-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html