[PATCH] i915/gt/selftest_lrc: Remove timestamp test

[Tvrtko Ursulin]

On 06/03/2025 10:37, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2025-03-04 16:43:45)
>>
>> On 04/03/2025 13:09, Mikolaj Wasiak wrote:
>>> This test exposes bug in tigerlake hardware which prevents it from
>>> succeeding. Since the tested feature is only available on bugged hardware
>>> and we won't support any new hardware, this test is obsolete and
>>> should be removed.
>>
>> I randomly clicked on one TGL, one DG2, one MTL and one RKL in the CI
>> and only saw test passes. Then I looked at the patch below to see if
>> there is a skip condition but don't see one. So I end up confused since
>> commit message is making it sound like this only exists on Tigerlake and
>> it's failing all the time. Is it perhaps a sporadic failure? On all
>> platforms or just TGL? What am I missing?
> 
> The HW issue affects all gen12 platforms currently supported by i915. I
> don't have any data for derivatives, so I cannot confirm if this bug was
> fixed. The lrc_timestamp test was written to demonstrate this HW bug, to
> isolate it from (and explain) the pphwsp runtime discrepancies, covered
> by another selftest. The question is whether we want to keep a selftest
> that is expected to sporadically fail, that exists purely to hunt for
> those failures.
> 
> In the past, we have kept such selftests, but hidden them behind
> !IS_ENABLED(CONFIG_DRM_I915_SELFTEST_BROKEN).
> 
> So,
> - keep the selftest and expect sporadic failures in BAT, or

Up to Intel - it's not the first sporadically failing test and in the 
past at least those were handled.

> - remove the selftest and completely forget about the HW issue, or
> - hide the selftest and stop it running on known bad platforms?

Either of these two are also fine I think, as long as, if the removal is 
chosen, it is made sure that either we already have the comment briefly 
explaining the above somewhere in code, at a suitable location, or that 
a brief comment is added with the removal. And commit message improved 
to be less misleading about the failure frequency.

Regards,

Tvrtko