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 <[email protected]> --- 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 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
