[igt-dev] [PATCH i-g-t 2/3] tests/kms_setmode: Request the initial vbl count with RELATIVE instead of ABSOLUTE

[Chris Wilson]

Quoting Ville Syrjälä (2018-11-06 18:40:03)
> On Tue, Nov 06, 2018 at 04:38:48PM +0000, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-11-06 16:19:42)
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > Asking for the initial vblank count by specifying and absolute vblank count of 0
> > > doesn't make much sense. Switch to a relative query instead.
> > > 
> > > It doesn't look like we care about lining up on the first vblank boundary so
> > > we can just drop the NEXTONMISS flag. Only the relative timestamps of the
> > > events will matter.
> > 
> > I had to do a double take as quite often we care about submitting the
> > workload before the next vblank, but no you are quite correct in this
> > case so long as the next request is submitted within the next frame it
> > should be fine and not miss a response.
> > 
> > To catch the error during setup, we could do something like
> > 
> >       for (n = 0; n < CALIBRATE_TS_STEPS; n++) {
> >               drmVBlank check;
> > 
> >               ++wait.request.sequence;
> >               do_or_die(drmWaitVBlank(drm_fd, &wait));
> > 
> >               /* Double check that haven't already missed the vblank */
> >               memset(&check, 0, sizeof(check));
> >               check.request.type = kmstest_get_vblank_flag(crtc_idx);
> >               check.request.type |= DRM_VBLANK_RELATIVE;
> >               do_or_die(drmWaitVBlank(drm_fd, &check));
> > 
> >               igt_assert(!vblank_after(check.reply.sequence, wait.request.sequence));
> >       }
> 
> Isn't the 'igt_assert_eq(ev.sequence, last_seq + 1);' sufficient
> to catch that?

Sure, but does that tell us if our construction was bad or the kernel
reported the wrong event? My idea behind the assert was to ensure we
didn't feed garbage in.
-Chris