[Intel-gfx] [PATCH 1/2] drm/i915: workaround bad DSL readout in start of pipe update

[Jesse Barnes]

On HSW at least (still testing other platforms, but should be harmless
elsewhere), the DSL reg reads back as 0 when read around vblank start
time.  This ends up confusing the atomic start/end checking code, since
it causes the update to appear as if it crossed a frame count boundary.
Workaround that by avoiding updates in the first couple of scanlines.
In testing, even a delay of a single microsecond is enough to give us a
good DSL value again, so the millisecond we'll wait when we hit this
case occasionally ought to be plenty.

References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
---
 drivers/gpu/drm/i915/intel_sprite.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index ca7e264..0c2c62f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -113,8 +113,16 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
 		 */
 		prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE);
 
+		/*
+		 * On HSW, the DSL reg (0x70000) appears to return 0 if we
+		 * read it right around the start of vblank.  So skip past it
+		 * so we don't accidentally end up spanning a vblank frame
+		 * increment, causing the update_end() code to squak at us.
+		 * (We use 2 in the comparison to account for the
+		 * scanline_offset used to correct the DSL readout.)
+		 */
 		scanline = intel_get_crtc_scanline(crtc);
-		if (scanline < min || scanline > max)
+		if (scanline > 2 && (scanline < min || scanline > max))
 			break;
 
 		if (timeout <= 0) {
-- 
1.9.1