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

[Jani Nikula]

On Tue, 06 Mar 2018, "Lofstedt, Marta" <marta.lofstedt at intel.com> wrote:
>> -----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.

That's what bugs me here. When should fbc be re-enabled after failure?
Who should be responsible for ensure it gets re-enabled in igt?

BR,
Jani.



>
> 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.
>
>> 
>> Otherwise, it seems very reasonable that in this test we assume that FBC
>> works before we begin. We should have other tests that check that FBC
>> works under various different configurations, here we are checking that the
>> invalidate/flush do their jobs.
>> -Chris
>

-- 
Jani Nikula, Intel Open Source Technology Center