[RFC][PATCH 1/1] ARM: Add initial hibernation support

[Kevin Hilman]

On Fri, 2010-07-16 at 12:10 +0300, Hiroshi DOYU wrote:
> From: ext Russell King - ARM Linux <linux at arm.linux.org.uk>
> Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
> Date: Fri, 16 Jul 2010 09:52:44 +0200
> 
> > On Thu, Jul 15, 2010 at 12:08:07PM +0300, Hiroshi DOYU wrote:
> >> From: ext Russell King - ARM Linux <linux at arm.linux.org.uk>
> >> Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
> >> Date: Thu, 15 Jul 2010 10:41:18 +0200
> >> 
> >> > On Thu, Jul 15, 2010 at 08:34:50AM +0300, Hiroshi DOYU wrote:
> >> >> Russell, would it be possible to put this into your next merge queue?
> >> > 
> >> > I think it needs quite a bit of rework - I certainly don't like all
> >> > those CP15 register accesses there - that's asking for lots of ifdefs
> >> > to spring up as more CPUs are supported.
> >> >
> >> > Eg, what about ensuring that state such as iWMMXt on PXA CPUs is
> >> > properly restored?
> >> 
> >> Right. This arch specific part can be something like
> >> "suspend-v[3-7].S" to accomodate those differences
> > 
> > It's not quite that simple - things like iWMMXt aren't part of the ARM
> > arch specs.
> >
> >> > We already have code which knows what needs to be saved across a
> >> > power-off transition - its what we use for our normal suspend/resume
> >> > functionality, so we should look at re-using that code for hibernate
> >> > as well.  We really don't want to be maintaining two sets of code
> >> > doing the same thing.
> >> 
> >> Could you explain which code you're refering for the existing one?
> > 
> > The code which handles saving state for the existing suspend/resume
> > support.  This code already saves the necessary state from CP15 and
> > any other state which needs to be saved prior to putting the system
> > into low power mode.
> > 
> > Every machine class which supports suspend today has their own chunk
> > of code which does this, normally called something like sleep.S
> 
> Ok, it seems to be the way to try to make use of the existing one for
> suspend-to-ram with some modifications.

[sorry to be late to the party here]

At least on OMAP, we already have everything needed to save/restore
context for off-mode transitions handled in the suspend (and idle)
paths.  So, at least in terms of context save/restore, there should be
minimal changes needed there.

Kevin