]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
drm/xe: Name and document Wa_14019789679
authorMatt Roper <matthew.d.roper@intel.com>
Mon, 12 Aug 2024 18:10:43 +0000 (11:10 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 10 Oct 2024 10:03:28 +0000 (12:03 +0200)
commita15c853c182e7e7baf84d2f9580aec4b33f0b403
treeb9a3147cfbb81e701f611492c7d7cb87e048c3d9
parente4e26cbe34d7c1c1db5fb7b3101573c29866439f
drm/xe: Name and document Wa_14019789679

[ Upstream commit 1d734a3e5d6bb266f52eaf2b1400c5d3f1875a54 ]

Early in the development of Xe we identified an issue with SVG state
handling on DG2 and MTL (and later on Xe2 as well).  In
commit 72ac304769dd ("drm/xe: Emit SVG state on RCS during driver load
on DG2 and MTL") and commit fb24b858a20d ("drm/xe/xe2: Update SVG state
handling") we implemented our own workaround to prevent SVG state from
leaking from context A to context B in cases where context B never
issues a specific state setting.

The hardware teams have now created official workaround Wa_14019789679
to cover this issue.  The workaround description only requires emitting
3DSTATE_MESH_CONTROL, since they believe that's the only SVG instruction
that would potentially remain unset by a context B, but still cause
notable issues if unwanted values were inherited from context A.
However since we already have a more extensive implementation that emits
the entire SVG state and prevents _any_ SVG state from unintentionally
leaking, we'll stick with our existing implementation just to be safe.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240812181042.2013508-2-matthew.d.roper@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/gpu/drm/xe/xe_lrc.c
drivers/gpu/drm/xe/xe_wa_oob.rules