[Intel-gfx] S4 resume breakage with i915 driver
Imre Deak
imre.deak at intel.com
Fri Aug 26 11:42:47 UTC 2016
On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> > > On Fri, 26 Aug 2016 11:18:00 +0200,
> > > Takashi Iwai wrote:
> > > > I had to modify the intel_gpu_reset() call because the test was
> > > > done
> > > > on the older kernel, so it's like:
> > > >
> > > > + intel_gpu_reset(dev_to_i915(dev)->dev);
> > > >
> > > > And, it seems working on HSW! \o/
> > > >
> > > > A simple trick, better than the magical register write revert.
> > > > I'll check other machines, too, to see whether it has any
> > > > negative
> > > > impact.
> > >
> > > The test results look good on all machines.
> >
> > The theory then is that the GPU's are active across the load of the
> > hibernation image and so before the GTT is updated the memory
> > currently
> > in use by the GPU is reused by the system.
> >
> > The key question then is the memory of boot kernel still in place
> > during
> > the hibernate restore phase?
>
> Before restoring the image all devices are quiesced by calling their
> freeze callback, so the GPU should be idle already
> in i915_pm_restore_early() already.
But this happens in the loader kernel, so if that doesn't have the
driver built-in then the freeze callback won't be called either. So any
possible BIOS related GPU activity/setup should be quiesced from the
restore callback then.
> > If we need to add a ->shutdown callback (if
> > that is even called before hibernate restore) then we can only fix
> > future kernels and are still susceptible to corruption when booing
> > from
> > old kernels.
> >
> > Any one familiar with the details of the hibernation restore? (And
> > how
> > much relates to kexec?)
> > -Chris
More information about the Intel-gfx
mailing list