From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 3/4] drm/i915: enable VT switchless resume v3
Date: Tue, 20 May 2014 14:27:22 -0700 [thread overview]
Message-ID: <20140520142722.27b1890c@jbarnes-desktop> (raw)
In-Reply-To: <20140520141807.65e2391d@jbarnes-desktop>
On Tue, 20 May 2014 14:18:07 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Tue, 20 May 2014 14:10:16 -0700
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
> > On Tue, 20 May 2014 22:15:45 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > > Ah, poll_enable is false until after _thaw finishes, so
> > > > our hotplug_resume call of hpd_irq_event does nothing. So aside from
> > > > the encoder hot_plug callbacks (which really just check dp link status,
> > > > which ought to be a no-op) our resume_hotplug function doesn't do
> > > > anything right now. May as well kill it and just send an unconditional
> > > > uevent?
> > >
> > > That's expensive since the reprobe will likely result in a few dropped
> > > frames (if the edid reading takes a long time). Better to do that in
> > > the kernel and avoid sending the uevent if nothing changed. Which iirc
> > > hpd_irq_event does for us.
> >
> > Well delaying the resume by a long time isn't much better, but I guess
> > we need to fix this somehow.
> >
> > Knut, does this patch also address your issue? It should reset the
> > connector status fields correctly so the X driver doesn't have to work
> > around things...
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > index b948c71..e725235 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -623,8 +623,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool restore_gtt_mappings)
> > * */
> > intel_hpd_init(dev);
> > dev_priv->enable_hotplug_processing = true;
> > - /* Config may have changed between suspend and resume */
> > - intel_resume_hotplug(dev);
> > }
> >
> > intel_opregion_init(dev);
> > @@ -694,6 +692,11 @@ int i915_resume(struct drm_device *dev)
> > return ret;
> >
> > drm_kms_helper_poll_enable(dev);
> > + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > + /* Config may have changed between suspend and resume */
> > + intel_resume_hotplug(dev);
> > + }
> > +
> > return 0;
> > }
> >
>
> Bah nevermind, this won't do anything. I was thinking that poll_enable
> controlled the poll_enabled field, but it doesn't, it just schedules or
> cancels the work for it.
>
> So we're still left wondering why the connector status fields are
> incorrect on resume in this case...
And on top of that I can't reproduce your issue here on my BYT which
shares many of these code paths. It could be something i915 specific
where we're not doing teardown correctly...
Knut, can you run testdisplay -i from intel-gpu-tools after you kill
the X server following the resume? It shows connected for me both on
eDP and HDMI as expected.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-05-20 21:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 16:25 [PATCH 1/4] drm/i915: add sprite restore function v3 Jesse Barnes
2013-03-26 16:25 ` [PATCH 2/4] drm/i915: restore cursor and sprite state when forcing a config restore Jesse Barnes
2013-03-26 16:40 ` Rodrigo Vivi
2013-03-26 16:52 ` Daniel Vetter
2013-03-26 17:07 ` [PATCH 1/2] drm/i915: enable VT switchless resume v3 Jesse Barnes
2013-03-26 17:07 ` [PATCH 2/2] drm/i915: emit a hotplug event on resume Jesse Barnes
2013-03-26 20:25 ` drm/i915: restore cursor and sprite state when forcing a config restore v2 Jesse Barnes
2013-03-26 20:46 ` Daniel Vetter
2013-03-26 20:57 ` Jesse Barnes
2013-03-26 16:25 ` [PATCH 3/4] drm/i915: enable VT switchless resume v3 Jesse Barnes
2013-03-26 16:42 ` Rodrigo Vivi
2013-04-03 9:15 ` Daniel Vetter
2013-04-03 10:54 ` Chris Wilson
2013-04-03 15:13 ` Jesse Barnes
2014-04-21 16:37 ` Knut Petersen
2014-05-16 22:20 ` Jesse Barnes
2014-05-16 22:28 ` Daniel Vetter
2014-05-16 22:38 ` Chris Wilson
2014-05-16 22:42 ` Chris Wilson
2014-05-20 19:53 ` Jesse Barnes
2014-05-20 19:58 ` Jesse Barnes
2014-05-20 20:15 ` Daniel Vetter
2014-05-20 21:10 ` Jesse Barnes
2014-05-20 21:18 ` Jesse Barnes
2014-05-20 21:27 ` Jesse Barnes [this message]
2013-03-26 16:25 ` [PATCH 4/4] drm/i915: emit a hotplug event on resume Jesse Barnes
2013-03-26 16:43 ` Rodrigo Vivi
2013-03-26 16:38 ` [PATCH 1/4] drm/i915: add sprite restore function v3 Rodrigo Vivi
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=20140520142722.27b1890c@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=daniel.vetter@ffwll.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox