All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.