kernel/linux.git/drivers/gpu/drm/xe/xe_tuning.c, branch linux-7.1.y

drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN4

2026-05-18T13:22:47+00:00

The register COMMON_SLICE_CHICKEN4 is a MCR register on both Xe2 and Xe3. Let's make sure to define a MCR version of it and use it for the relevant IP versions. Use XEHP_ as prefix for the register name, since it is MCR as of Xe_HP. v2: - Also change for one entry in lrc_tunnings, which was caught by manual testing and add corresponging Fixes tag in commit message. (Gustavo) Fixes: 8d6f16f1f082 ("drm/xe: Extend Wa_22021007897 to Xe3 platforms") Fixes: e5c13e2c505b ("drm/xe/xe2hpg: Add Wa_22021007897") Fixes: 8ccf5f6b2295 ("drm/xe/tuning: Apply windower hardware filtering setting on Xe3 and Xe3p") Bspec: 66534, 71185, 74417 Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260514-rtp-mcr-check-v3-3-30dd47855fee@intel.com Signed-off-by: Gustavo Sousa (cherry picked from commit 75f65f1a4c06da1d87f28570a9d4cdad28f13360) Signed-off-by: Rodrigo Vivi

drm/xe/tuning: Use proper register offset for GAMSTLB_CTRL

2026-04-29T15:28:10+00:00

From Xe2 onward (i.e., all platforms officially supported by the Xe driver), the GAMSTLB_CTRL register is located at offset 0x477C and represented by the macro "GAMSTLB_CTRL" in code. However the register formerly resided at offset 0xCF4C on Xe1-era platforms, and we also have macro XEHP_GAMSTLB_CTRL that represents this old offset in the unofficial/developer-only Xe1 code. When tuning for the register was added for Xe3p_LPG, the old Xe1-era macro was accidentally used instead of the proper macro for Xe2 and beyond, causing the tuning to not be applied properly. Use the proper definition so that the correct offset is written to. Bspec: 59298 Fixes: 377c89bfaa5d ("drm/xe/xe3p_lpg: Set STLB bank hash mode to 4KB") Reviewed-by: Gustavo Sousa Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-2-e206a62ee38f@intel.com Signed-off-by: Matt Roper (cherry picked from commit 0b1676eafdd1ba5a5436bdca0d2a25ce56699783) Signed-off-by: Rodrigo Vivi

drm/xe/tuning: Apply windower hardware filtering setting on Xe3 and Xe3p

2026-02-27T16:54:21+00:00

A recent bspec tuning guide update asks us to program COMMON_SLICE_CHICKEN4[5] on Xe3 and Xe3p platforms. Add this setting to our LRC tuning RTP table so that the setting will become part of each context's LRC. Bspec: 72161, 55902 Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260224235055.3038710-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe/reg_sr: Don't process gt/hwe lists in VF

2026-02-19T15:31:05+00:00

There are a few different reg_sr lists managed by the driver for workarounds/tuning: - gt->reg_sr - hwe->reg_sr - hwe->reg_lrc The first two are not relevant to SRIOV VFs; a VF KMD does not have access to the registers that appear on this list and it is the PF KMD's responsibility to apply such programming on behalf of the entire system. However the third list contains per-client values that the VF KMD needs to ensure are incorporated whenever a new LRC is created. Handling of reg_sr lists comes in two steps: processing an RTP table to build a reg_sr from the relevant entries, and then applying the contents of the reg_sr. Skipping the RTP processing (resulting in an empty reg_sr) or skipping the application of a reg_sr are both valid ways to avoid having a VF accidentally try to write registers it doesn't have access to. In commit c19e705ec981 ("drm/xe/vf: Stop applying save-restore MMIOs if VF") and commit 92a5bd302458 ("drm/xe/vf: Unblock xe_rtp_process_to_sr for VFs") we adjusted the drivers behavior to always process the RTP table into a reg_sr and just skipped the application step. This works fine functionally, but can lead to confusion during debugging since facilities like the debugfs 'register-save-restore' will still report a bunch of registers that the VF KMD isn't actually trying to handle. It will also mislead other upcoming debug changes. Let's go back to skipping the RTP => reg_sr processing step, but only for GT / hwe tables this time. This will allow LRC reg_sr handling to continue to work, but will ensure that gt->reg_sr and hwe->reg_sr remain empty and that debugfs reporting more accurately reflects the KMD's behavior. v2: - Also skip the hwe processing in hw_engine_setup_default_state() and xe_reg_whitelist_process_engine(). v3: - Handle skipping via an additional parameter passed to xe_rtp_process_to_sr() rather than adding conditions at each callsite. (Ashutosh) Cc: Michal Wajdeczko Cc: Ashutosh Dixit Cc: Harish Chegondi Reviewed-by: Ashutosh Dixit Link: https://patch.msgid.link/20260218-sr_verify-v4-1-35d6deeb3421@intel.com Signed-off-by: Matt Roper

drm/xe/xe3p_lpg: Set STLB bank hash mode to 4KB

2026-02-10T13:09:17+00:00

Since the dominant size of the pages referred in an i-gpu, such as Xe3p_LPG, will be 4KB, the HW default of mix of 64K and 2M for STLB bank hash mode does not make sense. Allow the SW to change it to 4KB Mode, for Xe3p_LPG. v2: - Add Bspec reference. (Matt) Bspec: 78248 Signed-off-by: Aradhya Bhatia Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-11-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa

drm/xe/xe3p_lpg: Drop unnecessary tuning settings

2026-02-10T13:09:11+00:00

From Xe3p onward, the desired settings are now the hardware's default values and the driver does not need to program them explicitly. Since 35.xx seems to be the starting point for "Xe3p" version numbers; we'll adjust the bounds of the old programming to stop at 34.99. Even though there's no platform with version 35.00 at the moment, this is simplest in case one does show up in the future. Bspec: 72161, 59928, 59930 Signed-off-by: Matt Roper Reviewed-by: Matt Atwood Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-8-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa

drm/xe/xe3p_lpg: Disable reporting of context switch status to GHWSP

2026-02-10T13:09:08+00:00

By default the hardware reports context switch status into the global hardware status page. The Xe driver doesn't use this information for anything, and as of Xe3p, leaving this setting enabled will prevent other hardware optimizations from being enabled. Disable this reporting as suggested by the tuning guide. Bspec: 72161 Signed-off-by: Matt Roper Reviewed-by: Matt Atwood Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-7-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa

drm: include drm_print.h where needed

2025-10-31T08:34:52+00:00

There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Signed-off-by: Jani Nikula Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com

drm/xe/xe3p_xpc: Skip compression tuning on platforms without flatccs

2025-10-19T02:45:13+00:00

The compression overfetch tuning settings only apply to platforms that support FlatCCS. In Xe3p_XPC (and any future IPs that also lack compression) some of the registers being adjusted by this tuning will not exist or may have been repurposed for something else, so we should take care not to try to program them. Note that our xe_rtp_match_has_flatccs() function will also return false on platforms that do have FlatCCS in the hardware design, but have compression manually disabled in the BIOS. On such platforms the registers still exist (and it would be fine to continue programming them), but they would have no effect, so skipping that tuning is also safe. Signed-off-by: Matt Roper Reviewed-by: Shekhar Chauhan Link: https://lore.kernel.org/r/20251016-xe3p-v3-22-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi

drm/xe/debugfs: Update xe_tuning_dump signature

2025-09-30T08:21:26+00:00

Our debugfs helper xe_gt_debugfs_show_with_rpm() expects print() functions to return int. New signature allows us to drop wrapper. While around, print additional separation lines using puts() to avoid output with leading \n which might confuse some printers. Signed-off-by: Michal Wajdeczko Cc: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250923211613.193347-4-michal.wajdeczko@intel.com