On Fri, 2010-07-16 at 12:10 +0300, Hiroshi DOYU wrote: > From: ext Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxx> > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
