]> git.baikalelectronics.ru Git - kernel.git/commit
drm/i915: Add a workaround for HSW scanline counter weirdness
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Tue, 11 Mar 2014 10:58:45 +0000 (12:58 +0200)
committerJani Nikula <jani.nikula@intel.com>
Wed, 12 Mar 2014 15:13:13 +0000 (17:13 +0200)
commita269e8604a6753b72129a0aa889b6238e20bbeed
tree7a26cd6eead3abcf9e0b17bf2bddf8992ed64ae4
parentde8bc29c39aef3ad32f799534339d77b27d69e8a
drm/i915: Add a workaround for HSW scanline counter weirdness

On HSW the scanline counter seems to behave differently depending on
the output type. eDP on port A does what you would expect an the normal
+1 fixup is sufficient to cover it. But on HDMI outputs we seem to need
a +2 fixup. Just assume we always need the +2 fixup and accept the
slight inaccuracy on eDP.

This fixes a regression introduced in:
 commit 1a91ea92ce40301a9774e7a987fee8801ccd8727
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Mon Oct 28 21:22:52 2013 +0200

    drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()

That commit removed the heuristic that tried to fix up the timestamps
for vblank interrupts that fire a bit too early. Since then the vblank
timestamp code would treat some vblank interrupts as spurious since the
scanline counter would indicate that vblank_start wasn't reached yet.
That in turn lead to incorrect vblank event sequence numbers being
reported to userspace, which lead to unsteady framerate in applications
such as XBMC which uses them for timing purposes.

v2: Remember to call ilk_pipe_in_vblank_locked() on HSW too (Mika)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75725
Tested-by: bugzilla1@gmx.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
drivers/gpu/drm/i915/i915_irq.c