This is a note to let you know that I've just added the patch titled
drm/i915: Flush the pending flips on the CRTC before modification
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
0020-drm-i915-Flush-the-pending-flips-on-the-CRTC-before-.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From 26db88c526637f289781830db777b0fd07b01bff Mon Sep 17 00:00:00 2001
From: Chris Wilson <[email protected]>
Date: Thu, 27 Sep 2012 21:25:58 +0100
Subject: drm/i915: Flush the pending flips on the CRTC before modification
From: Chris Wilson <[email protected]>
commit 5bb61643f6a70d48de9cfe91ad0fee0d618b6816 upstream.
This was meant to be the purpose of the
intel_crtc_wait_for_pending_flips() function which is called whilst
preparing the CRTC for a modeset or before disabling. However, as Ville
Syrjala pointed out, we set the pending flip notification on the old
framebuffer that is no longer attached to the CRTC by the time we come
to flush the pending operations. Instead, we can simply wait on the
pending unpin work to be finished on this CRTC, knowning that the
hardware has therefore finished modifying the registers, before proceeding
with our direct access.
Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply
schedule the flip immediately when the pipe is disabled, leading
to other funny issues.
Signed-off-by: Chris Wilson <[email protected]>
[danvet: Added i-g-t note and cc: stable]
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Julien Cristau <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/intel_display.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2895,13 +2895,34 @@ static void intel_clear_scanline_wait(st
I915_WRITE_CTL(ring, tmp);
}
+static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long flags;
+ bool pending;
+
+ if (atomic_read(&dev_priv->mm.wedged))
+ return false;
+
+ spin_lock_irqsave(&dev->event_lock, flags);
+ pending = to_intel_crtc(crtc)->unpin_work != NULL;
+ spin_unlock_irqrestore(&dev->event_lock, flags);
+
+ return pending;
+}
+
static void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
if (crtc->fb == NULL)
return;
+ wait_event(dev_priv->pending_flip_queue,
+ !intel_crtc_has_pending_flip(crtc));
+
mutex_lock(&dev->struct_mutex);
intel_finish_fb(crtc->fb);
mutex_unlock(&dev->struct_mutex);
@@ -7258,9 +7279,8 @@ static void do_intel_finish_page_flip(st
atomic_clear_mask(1 << intel_crtc->plane,
&obj->pending_flip.counter);
- if (atomic_read(&obj->pending_flip) == 0)
- wake_up(&dev_priv->pending_flip_queue);
+ wake_up(&dev_priv->pending_flip_queue);
schedule_work(&work->work);
trace_i915_flip_complete(intel_crtc->plane, work->pending_flip_obj);
Patches currently in stable-queue which might be from [email protected]
are
queue-3.4/0011-drm-i915-add-some-barriers-when-changing-DIPs.patch
queue-3.4/0008-drm-i915-Wait-for-all-pending-operations-to-the-fb-b.patch
queue-3.4/0016-drm-i915-Reduce-a-pin-leak-BUG-into-a-WARN.patch
queue-3.4/0018-drm-i915-Fix-GT_MODE-default-value.patch
queue-3.4/0003-drm-i915-fix-up-ivb-plane-3-pageflips.patch
queue-3.4/0002-drm-i915-Unpin-the-flip-target-if-we-fail-to-queue-t.patch
queue-3.4/0017-drm-i915-prevent-possible-pin-leak-on-error-path.patch
queue-3.4/0009-drm-i915-don-t-pwrite-tiled-objects-through-the-gtt.patch
queue-3.4/0012-drm-i915-SDVO-hotplug-have-different-interrupt-statu.patch
queue-3.4/0020-drm-i915-Flush-the-pending-flips-on-the-CRTC-before-.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
