[igt-dev] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Skip tests if FBC was disabled

[Chris Wilson]

Quoting Lofstedt, Marta (2018-03-06 10:39:04)
> 
> 
> > -----Original Message-----
> > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > Sent: Tuesday, March 6, 2018 11:32 AM
> > To: Lofstedt, Marta <marta.lofstedt at intel.com>; igt-
> > dev at lists.freedesktop.org
> > Subject: Re: [igt-dev] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Skip tests if
> > FBC was disabled
> > 
> > Quoting Marta Lofstedt (2018-03-06 09:24:57)
> > > If FBC has been disabled in the system due to previous malfuction, we
> > > would save time on CI if we bail out early.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105359
> > > Signed-off-by: Marta Lofstedt <marta.lofstedt at intel.com>
> > 
> > Hmm, FBC starts inactive on a system, so we would need to ensure that we
> > enabled FBC and did a proper modeset first and wait for FBC to be enabled
> > first.
> 
> On the SKL NUCi5 system I have been running this on, the FBC disabled sysfs, isn't re-set after a modeset. Maybe this is a driver error that should not be hidden by me suggesting to skip the tests. 

It may just be that we see the same error. Some errors like underruns
permanently disable FBC (afaik).
 
> On the other hand, the kms_frontbuffer_tracking test should give different results if FBC is disabled compared to timeout in the fbc_wait_until_enabled() which up until some time ago was the most common way to fail this test. 

I agree. It's just the test has to assume it is starting from scratch,
so needs to put the system into a known state before it can deduce what
is supported. So I think if we set the test mode inside setup_modeset(),
we can then test whether FBC is supported on that mode.
-Chris