From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
We use the vblank timestamps to generate the vblank frame counter value
on gen2. That means we need the pipe scanout position to be accurate
when we call drm_crtc_vblank_on(), otherwise the frame counter
guesstimate may jump when the pipe actually start.
What I observed on my 85x is that the DSL initially reads 0, and when
the pipe actually starts DSL jumps to vblank_start. On gen2 DSL==0 means
actually vtotal-1 (see update_scanline_offset()), so if we initially
get vtotal-1, and then very quickly vblank_start (or thereabouts), the
scanout position will appear to jump backwards by approximately one
vblank length. Which means the frame counter guesstimate will also
jump backwards. That's no good, so let's make sure the pipe has
started before we call drm_crtc_vblank_on().
Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 7dd7200d3ba9..78845d1cfd2e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2152,6 +2152,17 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
I915_WRITE(reg, val | PIPECONF_ENABLE);
POSTING_READ(reg);
+
+ /*
+ * Until the pipe starts DSL will read as 0, which would cause
+ * an apparent vblank timestamp jump, which messes up also the
+ * frame count when it's derived from the timestamps. So let's
+ * wait for the pipe to start properly before we call
+ * drm_crtc_vblank_on()
+ */
+ if (dev->max_vblank_count == 0 &&
+ wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 50))
+ DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe));
}
/**
--
2.4.10
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
