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