From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: swsusp issues
Date: Sat, 04 Jun 2005 08:50:28 +1000 [thread overview]
Message-ID: <1117839029.31082.180.camel@gaston> (raw)
In-Reply-To: <20050603111541.GC3867@elf.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]
> PM_DISK_REBOOT is very usefull for testing (and I believe generic; you
> could do that on ppc too). PM_DISK_SHUTDOWN is usefull for using
> normal powerdown paths in case something is wrong with disk-specific
> powerdown. We should move away from it, but please try not to kill it.
Well, I have a problem with these because they don't call the arch
prepare/finish callbacks.
Anyway, I discussed with Patrick yesterday and we came to the conclusion
that the best is in fact to just kill the current mecanism which was
done upside down. Kill pm_ops completely and instead of having a slim
"core" that uses callbacks all over, have the arch contain the main
state enter function and have the stuff in kernel/power/* be "library"
functions to be called by the arch code.
The idea here is then to have the arch provide main.c with an array of
"name",function pairs (name beeing the name in /sys/power/state and
function is what to call when the user echo's that name
to /sys/power/state). The rest would be entirely under arch control, and
that would remove most of the current cruft.
To simplify the job for swsusp and avoid the ugly in_suspend thing, we
should do a slight change of the low level code so that swsusp_suspend()
returns: 0 -> resume, 1 -> snapshotted, <0 -> error
We could provide an "example" default implementation that does only
swsusp that an arch can "drop in" if you want, but archs have to
implement the various "inline" callbacks anyway (save_processor_state &
friends).
Ben.
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2005-06-03 22:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-03 2:01 swsusp issues Benjamin Herrenschmidt
2005-06-03 11:15 ` Pavel Machek
2005-06-03 22:50 ` Benjamin Herrenschmidt [this message]
2005-06-03 23:21 ` Pavel Machek
2005-06-03 23:29 ` Benjamin Herrenschmidt
2005-06-04 6:13 ` Pavel Machek
2005-06-04 6:23 ` Benjamin Herrenschmidt
2005-06-03 23:25 ` Nigel Cunningham
2005-06-03 23:32 ` Benjamin Herrenschmidt
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=1117839029.31082.180.camel@gaston \
--to=benh@kernel.crashing.org \
--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