I thought about this one again and opposed to my previous comment now think it's fine, also for drivers without hw vblank counter queries.
-mario On Wed, Aug 6, 2014 at 1:49 PM, <ville.syrjala at linux.intel.com> wrote: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > 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 at linux.intel.com> > --- > drivers/gpu/drm/drm_irq.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index af33df1..0523f5b 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -106,6 +106,9 @@ static void drm_update_vblank_count(struct drm_device > *dev, int crtc) > DRM_DEBUG("enabling vblank interrupts 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. > -- > 1.8.5.5 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/9cdf6567/attachment.html>