From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Dave Gordon <david.s.gordon@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Shut down displays gracefully on reboot
Date: Mon, 8 Aug 2016 15:45:04 +0300 [thread overview]
Message-ID: <20160808124504.GE4329@intel.com> (raw)
In-Reply-To: <e092602a-3f97-fd76-da59-d66d930a0c75@intel.com>
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@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.
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
prev parent reply other threads:[~2016-08-08 12:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 13:36 [PATCH] drm/i915: Shut down displays gracefully on reboot ville.syrjala
2016-08-03 13:59 ` ✗ Ro.CI.BAT: failure for " Patchwork
2016-08-05 22:45 ` [PATCH] " Clint Taylor
2016-08-08 12:52 ` Ville Syrjälä
2016-08-08 13:13 ` David Weinehall
2016-08-06 8:09 ` Lukas Wunner
2016-08-06 8:29 ` Chris Wilson
2016-08-08 11:47 ` Dave Gordon
2016-08-08 12:45 ` Ville Syrjälä [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160808124504.GE4329@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=david.s.gordon@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.