Attachment 101610 Details for Bug 79354 – [PATCH] drm/i915: Wait for vblank after enabling the primary plane on BDW

[patch] [PATCH] drm/i915: Wait for vblank after enabling the primary plane on BDW

0001-drm-i915-Wait-for-vblank-after-enabling-the-primary-.patch (text/plain), 3.34 KB, created by Ville Syrjala on 2014-06-23 20:33:03 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Ville Syrjala

Created: 2014-06-23 20:33:03 UTC

Size: 3.34 KB

patch

obsolete

>From c2a618dd05fc462dc828014b223de4afa50355b2 Mon Sep 17 00:00:00 2001
>From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
>Date: Mon, 23 Jun 2014 21:19:41 +0300
>Subject: [PATCH] drm/i915: Wait for vblank after enabling the primary plane on
> BDW
>MIME-Version: 1.0
>Content-Type: text/plain; charset=UTF-8
>Content-Transfer-Encoding: 8bit
>
>BDW signals the flip done interrupt immediately after the DSPSURF write
>when the plane is disabled. This is true even if we've already armed
>DSPCNTR to enable the plane at the next vblank. This causes major
>problems for our page flip code which relies on the flip done interrupts
>happening at vblank time.
>
>So what happens is that we enable the plane, and immediately allow
>userspace to submit a page flip. If the plane is still in the process
>of being enabled when the page flip is issued, the flip done gets
>signalled immediately. Our DSPSURFLIVE check catches this to prevent
>premature flip completion, but it also means that we don't get a flip
>done interrupt when the plane actually gets enabled, and so the page
>flip is never completed.
>
>Work around this by re-introducing blocking vblank waits whenever
>we enable the primary plane.
>
>To avoid these blocking vblank waits we should start using the vblank
>interrupt instead of the flip done interrupt to complete page flips.
>But that's material for another pathc.
>
>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79354
>Cc: stable@vger.kernel.org
>Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>---
> drivers/gpu/drm/i915/intel_display.c | 9 +++++++++
> drivers/gpu/drm/i915/intel_sprite.c  | 8 ++++++++
> 2 files changed, 17 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>index fa77557..5d4795f 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -2134,6 +2134,7 @@ void intel_flush_primary_plane(struct drm_i915_private *dev_priv,
> static void intel_enable_primary_hw_plane(struct drm_i915_private *dev_priv,
> 					  enum plane plane, enum pipe pipe)
> {
>+	struct drm_device *dev = dev_priv->dev;
> 	struct intel_crtc *intel_crtc =
> 		to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> 	int reg;
>@@ -2153,6 +2154,14 @@ static void intel_enable_primary_hw_plane(struct drm_i915_private *dev_priv,
> 
> 	I915_WRITE(reg, val | DISPLAY_PLANE_ENABLE);
> 	intel_flush_primary_plane(dev_priv, plane);
>+
>+	/*
>+	 * BDW signals flip done immediately if the plane
>+	 * is disabled, even if the plane enable is already
>+	 * armed to occur at the next vblank :(
>+	 */
>+	if (IS_BROADWELL(dev))
>+		intel_wait_for_vblank(dev, intel_crtc->pipe);
> }
> 
> /**
>diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
>index 0e3fd5c..985317e 100644
>--- a/drivers/gpu/drm/i915/intel_sprite.c
>+++ b/drivers/gpu/drm/i915/intel_sprite.c
>@@ -691,6 +691,14 @@ intel_post_enable_primary(struct drm_crtc *crtc)
> 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> 
> 	/*
>+	 * BDW signals flip done immediately if the plane
>+	 * is disabled, even if the plane enable is already
>+	 * armed to occur at the next vblank :(
>+	 */
>+	if (IS_BROADWELL(dev))
>+		intel_wait_for_vblank(dev, intel_crtc->pipe);
>+
>+	/*
> 	 * FIXME IPS should be fine as long as one plane is
> 	 * enabled, but in practice it seems to have problems
> 	 * when going from primary only to sprite only and vice
>-- 
>1.8.5.5
>

Actions: View | Splinter Review

Attachments on bug 79354: 100009 | 100438 | 101610 | 101638

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.