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.syrj...@linux.intel.com > >> wrote: > >>> From: Ville Syrjälä <ville.syrj...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
