[linux-pm] Suspend "core": what to do now ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2005-06-28 at 09:49 +1000, Benjamin Herrenschmidt wrote:
> > Let's discuss how we would change the existing PM code...
> > 
> > I was thinking each arch could provide a table of system power states
> > with an ->enter() function for each.  We would then show the names of
> > these states in "/sys/power/state", and the user could select one.  Did
> > you have something else in mind?
> 
> Yes, that's what Patrick suggested too and I agree. 

Ok, It's easy enough as far as suspend to RAM is concerned.
suspend-to-disk is another matter.

I'm not sure what to do with the current crap in there, like the 4
different "methods" etc... that pretty much all assume that the code in
kernel/power/disk.c is "in charge" of the whole process (and it's all
pretty bogus too, like it doesn't deal with sysdev's).

I'm inclined to just trash all of that... but Nigel will have the same
problem here, if I start moving the core of swsusp to arch code, he'll
have to move the core of swsusp2 accordingly.

Also, remains the question then what to do of the resume function. Keep
it there or move it in arch code too... We may want to move it to arch
code too or we'll end up adding hooks to it...

I'm inclined to move everything to arch code, _and_ provide a kind of
"default" implementation of suspend-to-disk that you can enable with a
CONFIG option that provides an enter() callback that you can drop in
your arch it to use "as is" if you don't need any specific callback.

However, PM_DISK_PLATFORM and PM_DISK_FIRMWARE sort-of abuse the pm_ops
that I have killed to call into arch code... it's all crap as it exposes
to all archs some behaviours that may not be supported by those archs.

I'm inclined to just ignore it all and simply kill disk.c and let archs
re-implement what they want, but I'm sure some people will scream if I
do that...

Ben.



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux