From: Frank Hofmann <frank.hofmann@tomtom.com>
To: linux-arm-kernel@lists.infradead.org,
linux-pm@lists.linux-foundation.org, tuxonice-devel@tuxonice.net
Subject: [RFC] ARM hibernation, cpu-type-specific code
Date: Tue, 24 May 2011 14:27:05 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.00.1105241335170.10891@localhost6.localdomain6> (raw)
In-Reply-To: <20110520113758.GA3141@arm.com>
Hi,
Regarding ARM hibernation / suspend-to-disk, now that the glue part of the
code has "settled" it's probably time to think about the gory low-level
things, what's been delegated to the __save/__restore_processor_state()
hooks.
Russell King did the cpu_suspend / cpu_resume cleanup in Feb/2011,
http://lists.arm.linux.org.uk/lurker/message/20110211.161754.78371a42.en.html
which cleansed the mach-.../ sleep code in favour of moving these things
into processor type support hooks in arch/arm/mm/proc-*.S instead.
The key thing here was the addition of cpu_do_suspend/cpu_do_resume hooks
which save/restore state to/from a caller-supplied buffer, and then return
to their callers. I.e. pure auxilliary, "no side effects" (other than, for
resume, of course, what's desired).
The power-down / enter-low-power parts were separated from that.
>From my point of view, all platforms that use these should be able to do
the cpu-specific parts of hibernation via a simple addition, say, to
arch/arm/kernel/sleep.S (that's already using <asm/glue-proc.h> so
cpu_do_... exists), of something like:
#if defined(CONFIG_HAS_ARM_GENERIC_CPU_SUSPEND_SUPPORT) && defined(CONFIG_HIBERNATION)
ENTRY(__save_processor_state)
b cpu_do_suspend
ENDPROC(__save_processor_state)
ENTRY(__restore_processor_state)
stmfd sp!,{r4-r11,lr}
bl cpu_do_resume
ldmfd sp!,{r4-r11,pc}
ENDPROC(__restore_processor_state)
#endif
and "select HAS_ARM_GENERIC_CPU_SUSPEND_SUPPORT if CONFIG_PM" for the CPU
architectures that compile suitable mm/proc-*.S in.
That would do because the cpu_do_suspend/resume hooks perform the same CP
reg save/restore operations as the "illustration patches" I've posted for
OMAP3 and samsung 64xx (in fact, the latter is one of the platforms
changed via Russell's patch series).
>From my point of view, this assumes the following:
- cpu_do_suspend() takes one argument, a virtual address of the buffer to
save the state into. It is a "well-behaved" EABI-compliant func that
preserves nonvolatile regs.
It returns to LR.
- cpu_do_resume() assumes it can clobber registers; it takes one argument,
the address (not necessarily virtual) of the buffer to restore state
from.
The function does not depend on the MMU being OFF (could be called with
the MMU on, it'll "just clobber the state").
It also returns to LR.
Do these assumptions hold ?
If so, then would it be ok to create a patch for 2.6.39 onwards (baselined
against ARM devel-stable), along the lines just mentioned ?
How would one best test something as sweeping as that ?
The above suggestion still leaves a hole out for machine-specific
implementations - unselect the GENERIC config and implement the hook
yourself. Seems desireable ?
Regarding pre-2.6.38 kernels, are there any plans to backport the
cpu_suspend changes to any -stable series ?
Thanks in advance for comments / suggestions / corrections,
FrankH.
next prev parent reply other threads:[~2011-05-24 13:27 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3DCE2F529B282E4B8F53D4D8AA406A07014FFE@008-AM1MPN1-022.mgdnok.nokia.com>
2011-05-19 17:31 ` [RFC PATCH] ARM hibernation / suspend-to-disk support code Frank Hofmann
2011-05-20 11:37 ` Dave Martin
2011-05-20 11:37 ` Dave Martin
2011-05-20 12:39 ` Frank Hofmann
2011-05-20 12:39 ` Frank Hofmann
2011-05-20 15:03 ` Dave Martin
2011-05-20 15:03 ` Dave Martin
2011-05-20 16:24 ` Frank Hofmann
2011-05-23 9:42 ` Dave Martin
2011-05-23 9:42 ` Dave Martin
2011-05-20 16:24 ` Frank Hofmann
2011-05-20 17:53 ` Nicolas Pitre
2011-05-20 17:53 ` Nicolas Pitre
2011-05-20 18:07 ` Russell King - ARM Linux
2011-05-20 18:07 ` Russell King - ARM Linux
2011-05-22 6:39 ` Frank Hofmann
2011-05-20 22:27 ` [linux-pm] " Rafael J. Wysocki
2011-05-22 7:01 ` Frank Hofmann
2011-05-22 9:54 ` Rafael J. Wysocki
2011-05-22 9:54 ` Rafael J. Wysocki
2011-05-22 7:01 ` Frank Hofmann
2011-05-23 9:52 ` Dave Martin
2011-05-23 9:52 ` [linux-pm] " Dave Martin
2011-05-23 13:37 ` Frank Hofmann
2011-05-23 14:32 ` Russell King - ARM Linux
2011-05-23 14:32 ` [linux-pm] " Russell King - ARM Linux
2011-05-23 15:57 ` [RFC PATCH v2] " Frank Hofmann
2011-05-23 15:57 ` Frank Hofmann
2011-05-23 13:37 ` [RFC PATCH] " Frank Hofmann
2011-05-20 22:27 ` Rafael J. Wysocki
2011-05-20 18:05 ` Russell King - ARM Linux
2011-05-20 18:05 ` Russell King - ARM Linux
2011-05-23 10:01 ` Dave Martin
2011-05-23 10:12 ` Russell King - ARM Linux
2011-05-23 10:12 ` Russell King - ARM Linux
2011-05-23 11:16 ` Dave Martin
2011-05-23 16:11 ` Russell King - ARM Linux
2011-05-23 16:38 ` Dave Martin
2011-05-24 12:33 ` Frank Hofmann
2011-05-24 12:33 ` Frank Hofmann
2011-05-23 16:38 ` Dave Martin
2011-05-23 16:11 ` Russell King - ARM Linux
2011-05-23 11:16 ` Dave Martin
2011-05-23 10:01 ` Dave Martin
2011-05-24 13:27 ` Frank Hofmann [this message]
2011-05-19 17:31 ` Frank Hofmann
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=alpine.DEB.2.00.1105241335170.10891@localhost6.localdomain6 \
--to=frank.hofmann@tomtom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=tuxonice-devel@tuxonice.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.