public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Adam Belay <abelay@novell.com>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: Suspend "core": what to do now ?
Date: Tue, 28 Jun 2005 14:06:16 +1000	[thread overview]
Message-ID: <1119931577.5133.189.camel@gaston> (raw)
In-Reply-To: <1119916159.5133.145.camel@gaston>

[-- 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 --]



  reply	other threads:[~2005-06-28  4:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-27  5:49 Suspend "core": what to do now ? Benjamin Herrenschmidt
2005-06-27 21:23 ` Pavel Machek
2005-06-27 22:39   ` Rafael J. Wysocki
2005-06-27 22:55 ` Adam Belay
2005-06-27 23:49   ` Benjamin Herrenschmidt
2005-06-28  4:06     ` Benjamin Herrenschmidt [this message]
2005-06-28  4:58       ` Pavel Machek
2005-06-28  5:02         ` Benjamin Herrenschmidt
2005-06-28 12:44           ` Pavel Machek
2005-06-28  6:37       ` Nigel Cunningham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1119931577.5133.189.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=abelay@novell.com \
    --cc=linux-pm@lists.osdl.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox