Suspend "core": what to do now ?

Suspend "core": what to do now ?

[Benjamin Herrenschmidt]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Hi !

So I'm still sitting on that rewrite of the pmac suspend code including
suspend to disk consolidation etc... that I would really like to get
upstream. However, I'm still having a problem:

 - I'm still adding all those callbacks to pm_ops, Patrick wants to get
the stuff out of the core, which I agree, but I don't feel like "fixing"
x86 neither :) Pavel wants to keep the existing stuff.

 - If I keep my callbacks addition, we need to consolidate
kernel/power/disk.c with kernel/power/main.c. I need all callbacks in
both cases. The current inconsistency makes little sense.

 - I want that in 2.6.13 final, so please, let's decide something :)

Ben.



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Suspend "core": what to do now ?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

Hi!

> So I'm still sitting on that rewrite of the pmac suspend code including
> suspend to disk consolidation etc... that I would really like to get
> upstream. However, I'm still having a problem:
> 
>  - I'm still adding all those callbacks to pm_ops, Patrick wants to get
> the stuff out of the core, which I agree, but I don't feel like "fixing"
> x86 neither :) Pavel wants to keep the existing stuff.

I'm currently on the "vacation" (lingvistic conference); away from
x86-64 machines. I'm likely to accept any solution that is not uglyer
than current situation, but you'll either have to convert x86{,-64}
yourself, or wait... probably until Ottawa. I'll be out next week, and
then probably overloaded with pushing my patches and getting Canadian
visa.

>  - If I keep my callbacks addition, we need to consolidate
> kernel/power/disk.c with kernel/power/main.c. I need all callbacks in
> both cases. The current inconsistency makes little sense.

Yep, disk.c/main.c separation makes little sense.

>  - I want that in 2.6.13 final, so please, let's decide something :)

Start getting x86-64 machine, then ;-)))))). Or force ppc into current
infrastructure somehow.
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: Suspend "core": what to do now ?

[Rafael J. Wysocki]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

Hi,

On Monday, 27 of June 2005 23:23, Pavel Machek wrote:
> Hi!
> 
> > So I'm still sitting on that rewrite of the pmac suspend code including
> > suspend to disk consolidation etc... that I would really like to get
> > upstream. However, I'm still having a problem:
> > 
> >  - I'm still adding all those callbacks to pm_ops, Patrick wants to get
> > the stuff out of the core, which I agree, but I don't feel like "fixing"
> > x86 neither :) Pavel wants to keep the existing stuff.
> 
> I'm currently on the "vacation" (lingvistic conference); away from
> x86-64 machines. I'm likely to accept any solution that is not uglyer
> than current situation, but you'll either have to convert x86{,-64}
> yourself, or wait... probably until Ottawa. I'll be out next week, and
> then probably overloaded with pushing my patches and getting Canadian
> visa.
> 
> >  - If I keep my callbacks addition, we need to consolidate
> > kernel/power/disk.c with kernel/power/main.c. I need all callbacks in
> > both cases. The current inconsistency makes little sense.
> 
> Yep, disk.c/main.c separation makes little sense.
> 
> >  - I want that in 2.6.13 final, so please, let's decide something :)
> 
> Start getting x86-64 machine, then ;-)))))). Or force ppc into current
> infrastructure somehow.

I think I'll be able to help in a couple of days.  Then I can take care of the
x86-64 stuff, possibly with some assistance of someone more
knowledgeable. ;-)

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Suspend "core": what to do now ?

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Mon, 2005-06-27 at 15:49 +1000, Benjamin Herrenschmidt wrote:
> Hi !
> 
> So I'm still sitting on that rewrite of the pmac suspend code including
> suspend to disk consolidation etc... that I would really like to get
> upstream. However, I'm still having a problem:
> 
>  - I'm still adding all those callbacks to pm_ops, Patrick wants to get
> the stuff out of the core, which I agree, but I don't feel like "fixing"
> x86 neither :) Pavel wants to keep the existing stuff.

I'd like to move it out of the core and use the pm functions as a
library.

> 
>  - If I keep my callbacks addition, we need to consolidate
> kernel/power/disk.c with kernel/power/main.c. I need all callbacks in
> both cases. The current inconsistency makes little sense.
> 
>  - I want that in 2.6.13 final, so please, let's decide something :)
> 
> Ben.

I'm familiar with the ACPI code.  If you'd like, I could work on the x86
pm_ops.

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?

Thanks,
Adam



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Suspend "core": what to do now ?

[Benjamin Herrenschmidt]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]


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

Ben.



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Suspend "core": what to do now ?

[Benjamin Herrenschmidt]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

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.



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Suspend "core": what to do now ?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

Hi!

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

Feel free to kill PM_DISK_FIRMWARE. PM_DISK_PLATFORM looks like the
"right way" to do swsusp on acpi-enabled systems, so it should stay...

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Suspend "core": what to do now ?

[Benjamin Herrenschmidt]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On Tue, 2005-06-28 at 06:58 +0200, Pavel Machek wrote:
> Hi!
> 
> > 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.
> 
> Feel free to kill PM_DISK_FIRMWARE. PM_DISK_PLATFORM looks like the
> "right way" to do swsusp on acpi-enabled systems, so it should stay...

No, not in this form. It will be under arch control too. Makes no sense
to aim to remove the pm_ops callbacks and just add new ones for
PM_DISK_FIRMWARE :) Instead, ACPI systems will expose an S4 state that
does the right thing and calls swsusp_* library routines to do the job.

What I'll do is that I'll keep the "shutdown" case and will rename the
file generic_disk.c. It will be a "drop in" implementation that
architectures can use if they have no callbacks need at all. PPC won't
use it though. And I suspect x86 neither.

Ben.



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Suspend "core": what to do now ?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

Hi!

> > > 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.
> > 
> > Feel free to kill PM_DISK_FIRMWARE. PM_DISK_PLATFORM looks like the
> > "right way" to do swsusp on acpi-enabled systems, so it should stay...
> 
> No, not in this form. It will be under arch control too. Makes no

No problem. What I was trying to say is "feel free to remove
functionality of PM_DISK_FIRMWARE". Functionality of PM_DISK_PLATFORM
needs to stay.

> What I'll do is that I'll keep the "shutdown" case and will rename the
> file generic_disk.c. It will be a "drop in" implementation that
> architectures can use if they have no callbacks need at all. PPC won't
> use it though. And I suspect x86 neither.

Sounds good to me.
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Suspend "core": what to do now ?

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

Hi.

On Tue, 2005-06-28 at 14:06, Benjamin Herrenschmidt wrote:
> 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.

I have the problem that I have so little arch dependant code that it
seems silly to make the switch, but I also like the idea (as mentioned
on irc) of being able to switch between modes. (S3 for a while, then S4,
eg). To achieve something like that, it makes sense to have something
more generic, I think, that can handle these transitions. Then again,
maybe I'm just thinking of an extension to runtime PM :>

Whatever you do, I will have to work with it. I don't really see what
you're aiming at though, so I could do with a bit more brain dump if
you're willing.

Regards,

Nigel


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]