Re: [PATCH 2/2] drm/xe/kunit: Update RTP test to check VF rules

[Michal Wajdeczko <michal.wajdeczko@intel.com>]

On 17.06.2024 16:48, Lucas De Marchi wrote:
> On Fri, Jun 14, 2024 at 11:48:21PM GMT, Michal Wajdeczko wrote:
>> Add basic test cases that will verify VF_READY and VF_ONLY rules.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> ---
>> drivers/gpu/drm/xe/tests/xe_rtp_test.c | 118 ++++++++++++++++++++++++-
>> 1 file changed, 117 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/xe/tests/xe_rtp_test.c
>> b/drivers/gpu/drm/xe/tests/xe_rtp_test.c
>> index 06759d754783..0d8731e13217 100644
>> --- a/drivers/gpu/drm/xe/tests/xe_rtp_test.c
>> +++ b/drivers/gpu/drm/xe/tests/xe_rtp_test.c
>> @@ -232,6 +232,109 @@ static const struct rtp_test_case cases[] = {
>>             {}
>>         },
>>     },
>> +    {
>> +        .name = "vf-ready",
>> +        .expected_reg = REGULAR_REG1,
>> +        .expected_set_bits = REG_BIT(0),
>> +        .expected_clr_bits = REG_BIT(0),
>> +        .expected_count = 1,
>> +        /* VF-ready does not impact native/PF */
> 
> this contradicts the above expected*bits

hmm, but why ?

by design the VF_READY is a markup that should have no impact for any
rules that are executed on the native/PF so in this test case bits shall
be as specified by the action, which is REG_BIT(0)

did I missed something ?

> 
>> +        .entries = (const struct xe_rtp_entry_sr[]) {
>> +            { XE_RTP_NAME("basic-1"),
>> +              XE_RTP_RULES(FUNC(match_yes), VF_READY),
> 
> I was wondering if "VF_READY" wouldn't be more a case for entry->flags
> rather than entry->rules. 

I just followed IS_INTEGRATED/IS_DISCRETE as I could easily understand
what they do

> Do you have a concrete case for that?

not yet

as per 1/2 commit message, I don't know any RTP action that should be
applied on the VF right now, but since we are starting our VF adventure
and RTP is used at different stages, I would expect that in the future
some tweaks could be required to performed also by the VF itself,

thus decided to prepare framework for that, where all currently defined
actions are not applicable for VFs, but any of them could be easily
enabled, if mandated by the spec