summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
diff options
context:
space:
mode:
authorMario Kleiner <mario.kleiner.de@gmail.com>2014-09-13 18:25:54 +0200
committerDaniel Vetter <daniel.vetter@ffwll.ch>2014-09-24 12:09:22 +0200
commitda8f43962bd323813f7215b00b5da48ad766b9b2 (patch)
tree88971e62a2687641d9036acf8dfc5f8633723687 /drivers/gpu
parentd743ecf360637d489a3ba81a268f574359149601 (diff)
downloadop-kernel-dev-da8f43962bd323813f7215b00b5da48ad766b9b2.zip
op-kernel-dev-da8f43962bd323813f7215b00b5da48ad766b9b2.tar.gz
drm: Don't update vblank timestamp when the counter didn't change
If we already have a timestamp for the current vblank counter, don't update it with a new timestmap. Small errors can creep in between two timestamp queries for the same vblank count, which could be confusing to userspace when it queries the timestamp for the same vblank sequence number twice. This problem gets exposed when the vblank disable timer is not used (or is set to expire quickly) and thus we can get multiple vblank disable<->enable transition during the same frame which would all attempt to update the timestamp with the latest estimate. Testcase: igt/kms_flip/flip-vs-expired-vblank Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> v2:Mario: Trivial rebase on top of current drm-next (13-Sep-2014) Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu')
-rw-r--r--drivers/gpu/drm/drm_irq.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 80ff94a..e73cbda 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -126,6 +126,9 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc)
DRM_DEBUG("updating vblank count on crtc %d, missed %d\n",
crtc, diff);
+ if (diff == 0)
+ return;
+
/* Reinitialize corresponding vblank timestamp if high-precision query
* available. Skip this step if query unsupported or failed. Will
* reinitialize delayed at next vblank interrupt in that case.
OpenPOWER on IntegriCloud