[Intel-gfx] S4 resume breakage with i915 driver

[Imre Deak]

On ma, 2016-08-29 at 18:46 +0200, Lukas Wunner wrote:
> On Mon, Aug 29, 2016 at 04:25:25PM +0100, Chris Wilson wrote:
> > On Mon, Aug 29, 2016 at 05:54:45PM +0300, Imre Deak wrote:
> > > On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> > > > Hmm, this always confuses me.  Is the freeze callback called to the
> > > > loader kernel?
> > > 
> > > It's called both in loader and target kernel, before creating or
> > > restoring the image.
> > 
> > So the right answer for hiberation is?
> 
> According to Documentation/power/devices.txt:
> 
> "After the image has been loaded, the devices managed by the boot kernel
> need to be prepared for passing control back to the image kernel.  This
> is very similar to the initial steps involved in creating a system image,
> and it is accomplished in the same way, using prepare, freeze, and
> freeze_noirq phases.  However the devices affected by these phases are
> only those having drivers in the boot kernel; other devices will still be
> in whatever state the boot loader left them."
> 
> "Most often the pre-hibernation memory contents are restored successfully
> and control is passed to the image kernel, which then becomes responsible
> for bringing the system back to the working state.
> To achieve this, the image kernel must restore the devices' pre-hibernation
> functionality.  The operation is much like waking up from the memory sleep
> state, although it involves different phases:
>         restore_noirq, restore_early, restore, complete"
> 
> 
> If a missing i915.ko in the boot kernel's initrd causes problems, perhaps
> this can be solved by amending intel_graphics_quirks() to reset the GPU?

The problem at hand seems to happen with the driver present in the
loader kernel, so it needs to be fixed in the above PM callbacks. If
the missing driver is really a problem - no proof for this, I only
mentioned it as a possible scenario - then we'd need a separate fix.

--Imre