Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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