Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation

From: Scott Wood <[email-masked]>
Date: Tue, 19 Mar 2013 17:16:31 -0500

On 03/19/2013 04:22:07 PM, Johannes Berg wrote:
> On Tue, 2013-03-19 at 16:10 -0500, Scott Wood wrote:
>=20
> > > I was going to say I have no idea, but looking at it again ... =20
> this is
> > > in the *resume* code, not the suspend code as I'd assumed, and on
> > > resume
> > > I guess I felt it was safer to not assume it didn't change, since =20
> it
> > > could be a slightly different kernel that loaded and restored the
> > > hibernation image?
> >
> > Wouldn't that be doomed for other reasons?
>=20
> Most likely, yeah.
>=20
> > I wonder about kernel modules, though flushing 32 MiB wouldn't be
> > adequate there.
>=20
> Good question, but would they be running? You have to have everything
> built in that you need to load the image? Or maybe not, with the
> userspace image restoration that became possible at some point...

Is that all that's being restored in this step, or would we be loading =20
all modules that were loaded before suspend (as they're normally not =20
swappable)?  I'm not too familiar with what gets saved where.

> > It's not a displacement flush (i.e. you don't do a separate load =20
> pass
> > first) -- it just flushes lines if they happen to be present, and
> > leaves alone anything outside that range.  Given that you just =20
> finished
> > copying a bunch of data, most likely what's in the cache is the last
> > bit of data you copied.
>=20
> Oops, good point.
>=20
> Maybe there's a way to completely flush the (i)cache? :-)

There is, but it's platform-dependent, and not pleasant on our chips =20
(need a displacement flush for L1, and sometimes errata are involved =20
for L2).

-Scott=