[PATCH v2] powerpc: Add hibernation support for FSL BookE processors

[Scott Wood]

Anton Vorontsov wrote:
> On Thu, Apr 15, 2010 at 03:05:08PM -0500, Scott Wood wrote:
>> Kumar Gala wrote:
>>> On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote:
>>>> Kumar,
>>>>
>>>> According to patchwork, this is now delegated to you. Do you
>>>> have any objections to merge this?
>>> Would like Scott's Ack.
>> I think we need to save IACn, DACn, DBCRn,
> 
> Does the kernel actually need these registers? I mean, they're
> saved per thread anyway.
> 
>> PID0,
> 
> Kernel clears it early at boot, why would we save it?

What context are we in when we suspend, and what context is expected 
after resume?  If we're guaranteed not to be on a thread that cares 
about any of this, then OK.

>> and USPRG0.
> 
> Currently this isn't used at all.

Was thinking that it's up to userspace whether to use it or not -- 
though it ought to be saved on thread switch instead.

>> Might want to also save TLB1 contents, and maybe things like HIDn,
>> cache registers, etc. -- I don't think they're changeable post-boot
>> currently, but it'd be good to avoid surprises if that were to
>> change.
> 
> Hm. I don't really like the idea of doing things 'just in case',
> it just adds a code which functionality isn't tested, and which
> we will might never actually need.

The intent was to reduce dependencies between the suspend code and what 
the rest of the kernel does -- it's likely that someone adding some 
runtime manipulation of one of these things (e.g. hugetlbfs modifying 
TLB1) would not think to check suspend/hibernation code.  It would still 
be somewhat tested, in that you would see problems if you restored the 
wrong values (just not if you failed to restore at all).

We'll need to save/restore those things anyway for deep sleep -- but I'm 
not sure whether it'll be feasible to share code with hibernate (I 
recall trying on 83xx and giving up).  In any case, it can probably wait 
until 85xx deep sleep gets pushed out.

-Scott