[igt-dev] [PATCH i-g-t] intel-ci: Drop b/c pipes from kms_busy fast feedback

Chris Wilson chris at chris-wilson.co.uk
Tue Feb 11 17:01:54 UTC 2020


Quoting Ville Syrjälä (2020-02-11 16:50:15)
> On Tue, Feb 11, 2020 at 04:15:08PM +0000, Chris Wilson wrote:
> > The principle test for kms_busy is checking the synchronisation between
> > on-going rendering to a framebuffer and its flip, that is independent of
> > the pipe. As such for our fast feedback on driver health, we can look at
> > the first pipe and assume any errors on the rest will be picked up later
> > in the shards/idle runs.
> > 
> > Each pass of kms_busy is about 25s.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >  tests/intel-ci/fast-feedback.testlist | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist
> > index 467e11267..c0a2cce52 100644
> > --- a/tests/intel-ci/fast-feedback.testlist
> > +++ b/tests/intel-ci/fast-feedback.testlist
> > @@ -89,8 +89,6 @@ igt at kms_addfb_basic@unused-modifier
> >  igt at kms_addfb_basic@unused-offsets
> >  igt at kms_addfb_basic@unused-pitches
> >  igt at kms_busy@basic-flip-pipe-a
> > -igt at kms_busy@basic-flip-pipe-b
> > -igt at kms_busy@basic-flip-pipe-c
> 
> We will lose a bit of coverage on fi-bsw-n3050 since it has HDMI
> plugged into port D which can only be driven by pipe C. The other
> similar restrictions we have only affect gen2/3 lvds and vlv/chv
> dsi, so meh on those.
> 
> I guess slightly better solutions migh be:
> a) change the test to not be per-pipe but instead have it
>    stop as soon as it has found any working pipe+output
> b) support some form of logical OR with short cicuit in the testlist
>    (ie. igt at kms_busy@basic-flip-pipe-a || igt at kms_busy@basic-flip-pipe-b || ...)
> 
> But not sure how worried we should be about the loss of coverage on
> that single bsw. I guess we will hit it via the idle runs anyway,
> assuming anyone looks at those. And I can't recall kms_busy being a
> problem in the past for us, so it's probably fine.

The other aspect is why do we need 20s to determine if a flip/modeset is
too late? I haven't worked out why this test is as slow as it is.
-Chris


More information about the igt-dev mailing list