From: "Chauhan, Shekhar" <shekhar.chauhan@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Gustavo Sousa <gustavo.sousa@intel.com>,
<intel-xe@lists.freedesktop.org>,
Lucas De Marchi <lucas.de.marchi@gmail.com>,
Matt Roper <matthew.d.roper@intel.com>
Subject: Re: [PATCH] drm/xe/xe2lpg: Extend Wa_14020338487
Date: Thu, 18 Apr 2024 10:39:44 +0530 [thread overview]
Message-ID: <8cd5dd51-cc2d-4b42-833b-3bbb8c146ba0@intel.com> (raw)
In-Reply-To: <gmzgyv6tjktchnp77xtux4qoa63v4rckevz2y65dirkxa7tjmi@yb475d2qbaxp>
[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]
On 4/18/2024 10:30, Lucas De Marchi wrote:
> On Thu, Apr 18, 2024 at 10:20:35AM GMT, Chauhan, Shekhar wrote:
>>
>> On 4/18/2024 04:05, Lucas De Marchi wrote:
>>> On Wed, Apr 17, 2024 at 06:45:47PM GMT, 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().
>>>
>>> yes, implementing it was always something I considered, but then there
>>> was also the fact that when we have WAs that are on IPs that are not
>>> close to each other we may have subtle differences like registers with
>>> different offset or mcr vs non-mcr.
>>
>> I see that some registers vary between MCR and non-MCR types.
>> However, could you please explain how this difference affects
>> implementation? As I understand it, when setting XE_RTP_ACTIONS, we
>> simply choose the desired action (SET, CLR etc). So, I'm curious
>> about the specific impact of MCR vs non-MCR in this context.
>
> you need to pick the right register that has the mcr reg option set.
> Exammple:
>
> { XE_RTP_NAME("22016670082"),
> XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1270, 1274)),
> XE_RTP_ACTIONS(SET(SQCNT1, ENFORCE_RAR))
> },
>
> vs
>
> { XE_RTP_NAME("22016670082"),
> XE_RTP_RULES(MEDIA_VERSION(1300)),
> XE_RTP_ACTIONS(SET(XELPMP_SQCNT1, ENFORCE_RAR))
> },
>
> #define SQCNT1 XE_REG_MCR(0x8718)
> #define XELPMP_SQCNT1 XE_REG(0x8718)
>
>
Understood. Thanks.
/shekhar
/
>
> Lucas De Marchi
--
-shekhar
[-- Attachment #2: Type: text/html, Size: 4985 bytes --]
next prev parent reply other threads:[~2024-04-18 5:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 21:25 [PATCH] drm/xe/xe2lpg: Extend Wa_14020338487 Gustavo Sousa
2024-04-17 21:40 ` Matt Roper
2024-04-17 21:45 ` Gustavo Sousa
2024-04-17 22:27 ` Matt Roper
2024-04-18 5:06 ` Chauhan, Shekhar
2024-04-18 14:55 ` Gustavo Sousa
2024-04-17 22:35 ` Lucas De Marchi
2024-04-18 4:50 ` Chauhan, Shekhar
2024-04-18 5:00 ` Lucas De Marchi
2024-04-18 5:09 ` Chauhan, Shekhar [this message]
2024-04-18 14:31 ` Gustavo Sousa
2024-04-18 1:57 ` ✓ CI.Patch_applied: success for " Patchwork
2024-04-18 1:57 ` ✓ CI.checkpatch: " Patchwork
2024-04-18 1:58 ` ✓ CI.KUnit: " Patchwork
2024-04-18 2:18 ` ✓ CI.Build: " Patchwork
2024-04-18 2:21 ` ✓ CI.Hooks: " Patchwork
2024-04-18 2:22 ` ✓ CI.checksparse: " Patchwork
2024-04-18 3:16 ` ✓ CI.BAT: " Patchwork
2024-04-18 20:12 ` Matt Roper
2024-04-19 18:41 ` ✗ CI.FULL: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8cd5dd51-cc2d-4b42-833b-3bbb8c146ba0@intel.com \
--to=shekhar.chauhan@intel.com \
--cc=gustavo.sousa@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.de.marchi@gmail.com \
--cc=lucas.demarchi@intel.com \
--cc=matthew.d.roper@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox