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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev