From: Daniel Vetter <daniel@ffwll.ch>
To: ville.syrjala@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: Re-enable vblank irqs for already active pipes
Date: Tue, 20 May 2014 19:31:33 +0200 [thread overview]
Message-ID: <20140520173037.GA24095@phenom.ffwll.local> (raw)
In-Reply-To: <1400595605-22938-4-git-send-email-ville.syrjala@linux.intel.com>
On Tue, May 20, 2014 at 05:20:05PM +0300, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> If a pipe is already active when we init/resume there might not be a
> full modeset afterwards so drm_vblank_on() may not get called. In such
> a case if someone is holding a vblank reference across a suspend/resume
> cycle drm_vblank_get() called after resuming won't re-enable the vblank
> interrupts.
>
> So in order to make sure vblank interrupts get re-enabled post-resume,
> call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already
> active.
>
> v2: Also drm_vblank_off() if the pipe got disabled magically
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
This seems to duct-tape over the funny failure I'm seeing on my snb where
kms_flip/vblank-vs-modeset|dpms-suspend work nicely, but
kms_flip/vblank-vs-suspend has some totally hilarious random vblank frame
counter after the modeset.
Testecase: igt/kms_flip/vblank-vs-suspend
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now the problem I have: We already call this in the crtc_enable hook. Why
does calling this here again add the necessary magic?
/me has no clue
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 9420f4f..2e9f0b0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11708,6 +11708,12 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
> reg = PIPECONF(crtc->config.cpu_transcoder);
> I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
>
> + /* restore vblank interrupts to correct state */
> + if (crtc->active)
> + drm_vblank_on(dev, crtc->pipe);
> + else
> + drm_vblank_off(dev, crtc->pipe);
> +
> /* We need to sanitize the plane -> pipe mapping first because this will
> * disable the crtc (and hence change the state) if it is wrong. Note
> * that gen4+ has a fixed plane -> pipe mapping. */
> --
> 1.8.5.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-05-20 17:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-20 14:20 [PATCH 0/3] drm/i915: A few more vblank interrupt fixes ville.syrjala
2014-05-20 14:20 ` [PATCH 1/3] drm: Always reject drm_vblank_get() after drm_vblank_off() ville.syrjala
2014-05-20 14:20 ` [PATCH 2/3] drm/i915: Warn if drm_vblank_get() still works " ville.syrjala
2014-05-20 14:20 ` [PATCH 3/3] drm/i915: Re-enable vblank irqs for already active pipes ville.syrjala
2014-05-20 17:31 ` Daniel Vetter [this message]
2014-05-21 9:50 ` [Intel-gfx] " Daniel Vetter
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=20140520173037.GA24095@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/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