[PATCH] drm/xe/xe2lpg: Extend Wa_14020338487

[Gustavo Sousa]

Quoting Matt Roper (2024-04-17 19:27:47-03:00)
>On Wed, Apr 17, 2024 at 06:45:47PM -0300, Gustavo Sousa wrote:
>> Quoting Gustavo Sousa (2024-04-17 18:25:01-03:00)
>> >Wa_14020338487 also applies to Xe2_LPG. Replicate the existing entry to
>> >one specific for Xe2_LPG.
>> 
>> I would also like to take this as an opportunity to discuss the way we
>> are currently arranging the RTP entries for the workaround. Using this
>> one as example, created a copy of the entry and edited the argument of
>> GRAPHICS_VERSION() to match Xe2_LPG. There are multiple cases already
>> following the same pattern, mainly because we are grouping entries by
>> IP release.
>> 
>> Do we want to continue following that pattern and keep the code
>> duplication? Or should we think of a way to avoid code duplication here?
>> 
>> A very simple approach that I think of is having a single entry for each
>> lineage. But I guess that's not really feasible today because I guess we
>> do not have a way of expressing logical disjunction in XE_RTP_RULES().
>
>Yeah, there are basically two options here:
> - Keep them separate for now and combine some of them down the road
>   once we're sure no additional SKUs or refresh platforms are going to
>   show up with versions 20.02 and 20.03
> - Combine them as "general Xe2" workarounds now with a version range of
>   20.01 - 20.04, and then split them back appart in the future if/when
>   some new SKU/platform that doesn't need the workaround shows up to
>   take the currently unused version numbers.
>
>I think we've been going with the first approach because during early
>enablement of the platform it makes it slightly easier to quickly
>compare the driver's workaround list against the workaround database's
>list for a specific platform.  But we can also get a runtime list (i.e.,
>what's _actually_ applied) from debugfs, so maybe that's not very
>important.
>
>As long as we do it consistently and put in a comment warning about
>future changes, I don't see a problem with grouping some of these shared
>workarounds into a new "All Xe2" category with the understanding that
>some of them may need to be separated back out into individual entries
>if/when 20.02 or 20.03 platforms show up in the future.

Thanks for the input, Matt.

Since we are already following the first approach, I think we can keep
doing it for the time being. Unifying the those general to Xe2 once
releases are stabilized sounds reasonable.

Following up on Lucas' idea of splitting rules from actions, we might be
able to change direction in the future...

--
Gustavo Sousa

>
>
>Matt
>
>> 
>> --
>> Gustavo Sousa
>> 
>> >
>> >Signed-off-by: Gustavo Sousa <gustavo.sousa at intel.com>
>> >---
>> > drivers/gpu/drm/xe/xe_wa.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> >
>> >diff --git a/drivers/gpu/drm/xe/xe_wa.c b/drivers/gpu/drm/xe/xe_wa.c
>> >index 632bd9066f8d..dcf7ed51757c 100644
>> >--- a/drivers/gpu/drm/xe/xe_wa.c
>> >+++ b/drivers/gpu/drm/xe/xe_wa.c
>> >@@ -445,6 +445,10 @@ static const struct xe_rtp_entry_sr engine_was[] = {
>> >                        FUNC(xe_rtp_match_first_render_or_compute)),
>> >           XE_RTP_ACTIONS(SET(HALF_SLICE_CHICKEN5, DISABLE_SAMPLE_G_PERFORMANCE))
>> >         },
>> >+        { XE_RTP_NAME("14020338487"),
>> >+          XE_RTP_RULES(GRAPHICS_VERSION(2004), FUNC(xe_rtp_match_first_render_or_compute)),
>> >+          XE_RTP_ACTIONS(SET(ROW_CHICKEN3, XE2_EUPEND_CHK_FLUSH_DIS))
>> >+        },
>> >         { XE_RTP_NAME("16021540221"),
>> >           XE_RTP_RULES(GRAPHICS_VERSION(2004), GRAPHICS_STEP(A0, B0),
>> >                        FUNC(xe_rtp_match_first_render_or_compute)),
>> >-- 
>> >2.44.0
>> >
>
>-- 
>Matt Roper
>Graphics Software Engineer
>Linux GPU Platform Enablement
>Intel Corporation