Re: [PATCH] drm/i915: Shut down displays gracefully on reboot

[Dave Gordon <david.s.gordon@intel.com>]

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@linux.intel.com wrote:
>>> From: Ville Syrjälä <ville.syrjala@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.

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx