[PATCH v8 6/7] drm/xe/xelp: Implement Wa_16010904313

[Lucas De Marchi]

On Wed, Jul 09, 2025 at 11:07:07AM +0100, Tvrtko Ursulin wrote:
>
>On 09/07/2025 00:21, Lucas De Marchi wrote:
>>On Thu, Jul 03, 2025 at 09:20:58AM +0100, Tvrtko Ursulin wrote:
>>>Add XeLP workaround 16010904313.
>>>
>>>The description calls for it to be emitted as the indirect context buffer
>>>workaround for render and compute, and from the workaround batch buffer
>>>for the other engines. Therefore we plug into the previously added
>>>respective top level emission functions.
>>>
>>>The actual command streamer programming sequence differs from what is
>>>described in the PRM, in that it assumes the listed LRCA offset was
>>>supposed to actually refer to the location of the CTX_TIMESTAMP register
>>>instead of LRCA + 0x180c (which is in GPR space). Latter appears to make
>>>more sense under the assumption that multiple writes are helping with
>>>restoring the CTX_TIMESTAMP register content from the saved 
>>>context state.
>>
>>I'm requesting a clarification about that to hw/validation. Because this
>>doesn't match neither the i915 implementation nor the PRM.
>
>Yep it differs, as discussed before.
>
>Could you also ask about the programming note for INDIRECT_CTX and 
>INDIRECT_CTX_OFFSET from the public Tigerlake PRM (Alderlake is not 
>available), which says:
>
>"BlitterCS/VideoCS/VideoCS2/VideoEnhancementCS/PositionCS: This 
>register functionality is not supported and must not be programmed for 
>these command streamers."

if you look at CTX_BB_PER_CTX_PTR documentation it has a similar note
regarding BlitterCS, VideoCS, VideoEnhancementCS, ComputeCS. I will
double check which, if any, of those notes are accurate.

>
>I915 does use it, hence I copied it from there, but only now noticed 
>this. Maybe that is the reason Wa_16010904313 descriptions calls for 
>the wa_bb to be used on !rcs.

maybe it depends on the gt version... will check.

thanks
Lucas De Marchi

>
>Regards,
>
>Tvrtko
>