[igt-dev] [PATCH v3] tests/kms_vblank: Turn on hardware before testing invalid vblank.

[Mark Yacoub]

Thanks!
I was trying to find a neater way to grab the output that I wanna turn
on. Let me know if this is good or there is a better solution.
I pushed the change:
https://patchwork.freedesktop.org/patch/440342/?series=90382&rev=6

On Mon, Jun 21, 2021 at 6:53 AM Petri Latvala <petri.latvala at intel.com> wrote:
>
> On Thu, Jun 17, 2021 at 03:20:32PM +0000, Mark Yacoub wrote:
> > From: Mark Yacoub <markyacoub at google.com>
> >
> > [Why]
> > Before any hardware is on, the vblank is off and its ref counter is in
> > an initialized state as each driver handles toggling it differently.
> > Ioctl DRM_IOCTL_WAIT_VBLANK could return 0 such as on i915, or an invalid
> > integer that doesn't mean much, such as on Zork running Kernel 5.4 due
> > to the kernel workaround that increments the vblank ref count to prevent
> > a get from enabling the interrupt.
> >
> > [How]
> > For invalid_subtest(), active the CRTCs to turn the hardware on so
> > DRM_IOCTL_WAIT_VBLANK returns something meaningful.
> >
> > Changes since v2:
> > 1. Updated Signed-off-by.
> >
> > Changes since v1:
> > 1. Update Commit message
> > 2. Rename variable p to pipe_number
> >
> > Signed-off-by: Mark Yacoub <markyacoub at chromium.org>
> > ---
> >  tests/kms_vblank.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c
> > index 93b01eba..988794c0 100644
> > --- a/tests/kms_vblank.c
> > +++ b/tests/kms_vblank.c
> > @@ -475,8 +475,14 @@ static void invalid_subtest(data_t *data, int fd)
> >  {
> >       union drm_wait_vblank vbl;
> >       unsigned long valid_flags;
> > +     igt_display_t* display = &data->display;
> > +     enum pipe pipe_number = 0;
> > +     igt_output_t* output;
> >
> > -     igt_display_require_output_on_pipe(&data->display, 0);
> > +     igt_display_require_output_on_pipe(display, pipe_number);
> > +     data->pipe = pipe_number;
> > +     for_each_valid_output_on_pipe(display, pipe_number, output)
> > +             prepare_crtc(data, fd, output);
>
> Do you really need to fire up and reset all the outputs that pipe can
> drive? As opposed to just one.
>
>
> --
> Petri Latvala