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@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450110229-30450-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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));
}
/**