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. -- 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
