[Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

[Ville Syrjälä]

On Mon, Aug 08, 2016 at 12:47:09PM +0100, Dave Gordon wrote:
> On 06/08/16 09:29, Chris Wilson wrote:
> > On Sat, Aug 06, 2016 at 10:09:16AM +0200, Lukas Wunner wrote:
> >> On Wed, Aug 03, 2016 at 04:36:18PM +0300, ville.syrjala at linux.intel.com wrote:
> >>> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >>>
> >>> Dell UP2414Q doesn't like it when we're driving it in MST mode, and then
> >>> reboot the machine. After reboot, the monitor is somehow confused and
> >>> refuses to do the payload allocation:
> >>>  [drm:drm_dp_mst_allocate_vcpi] initing vcpi for 282 8
> >>>  [drm:drm_dp_dpcd_write_payload] status not set after read payload table status 0
> >>> and thus we're left with a black screen until the monitor power is
> >>> toggled.
> >>>
> >>> It seems that if we shut down things gracefully prior to rebooting, the
> >>> monitor doesn't get confused like this. So let's try to shut down all
> >>> the displays gracefully on reboot. The downside is that we will
> >>> introduce the reboot notifier to all the modesetl locks. So if there's
> >>> a locking bug around, we might not be able to reboot the machine
> >>> gracefully. sysrq reboot will still work though, as it will not
> >>> call the notifiers.
> >>
> >> struct pci_driver has a ->shutdown hook which is currently not defined
> >> in i915_pci_driver. How about using that instead of reboot_notifier
> >> to avoid potential locking issues?
> >
> > Interestingly that is also called prior to kexec. Doing a
> > i915_gem_suspend at that point I think would stop some of the GPU faults
> > we get across kexec.
> > -Chris
> 
> Agreed; we've had issues with things such as the GuC being left running 
> across kexec, which causes firmware load to fail cos it's write-once!
> Doing a clean suspend before kexec would certainly help here.

I also realized that even my display suspend is somewhat insufficient
as I didn't consider hpds, ->detect() etc. potentially turning on vdd
again. I thought I might have to start reworking the hpd disable to not
depend on intel_runtime_pm_disable_interrupts(), but if we're going to
want a full blown suspend anyway I might not bother.

-- 
Ville Syrjälä
Intel OTC