kernel/drivers/gpu/drm/xe/regs, branch master

drm/xe/wa: Steer RMW of MCR registers while building default LRC

2026-02-23T18:54:48Z

When generating the default LRC, if a register is not masked, we apply any save-restore programming necessary via a read-modify-write sequence that will ensure we only update the relevant bits/fields without clobbering the rest of the register. However some of the registers that need to be updated might be MCR registers which require steering to a non-terminated instance to ensure we can read back a valid, non-zero value. The steering of reads originating from a command streamer is controlled by register CS_MMIO_GROUP_INSTANCE_SELECT. Emit additional MI_LRI commands to update the steering before any RMW of an MCR register to ensure the reads are performed properly. Note that needing to perform a RMW of an MCR register while building the default LRC is pretty rare. Most of the MCR registers that are part of an engine's LRCs are also masked registers, so no MCR is necessary. Fixes: f2f90989ccff ("drm/xe: Avoid reading RMW registers in emit_wa_job") Cc: Michal Wajdeczko Reviewed-by: Balasubramani Vivekanandan Link: https://patch.msgid.link/20260206223058.387014-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper (cherry picked from commit 6c2e331c915ba9e774aa847921262805feb00863) Signed-off-by: Rodrigo Vivi

drm/xe/mert: Improve handling of MERT CAT errors

2026-01-14T15:02:50Z

All MERT catastrophic errors but VF's LMTT fault are serious, so we shouldn't limit our handling only to print debug messages. Change CATERR message to error level and then declare the device as wedged to match expectation from the design document. For the LMTT faults, add a note about adding tracking of this unexpected VF activity. While at it, rename register fields defnitions to match the BSpec. Also drop trailing include guard name from the regs.h file. BSpec: 74625 Signed-off-by: Michal Wajdeczko Cc: Lukasz Laguna Reviewed-by: Lukasz Laguna Link: https://patch.msgid.link/20260112183716.28700-1-michal.wajdeczko@intel.com

drm/xe/hwmon: Expose individual VRAM channel temperature

2026-01-12T22:00:29Z

Expose individual VRAM temperature attributes. Update Xe hwmon documentation for this entry. v2: - Avoid using default switch case for VRAM individual temperatures. - Append labels with VRAM channel number. - Update kernel version in Xe hwmon documentation. v3: - Add missing brackets in Xe hwmon documentation from VRAM channel sysfs. - Reorder BMG_VRAM_TEMPERATURE_N macro in xe_pcode_regs.h. - Add api to check if VRAM is available on the channel. v4: - Improve VRAM label handling to eliminate temp variable by introducing a dedicated array vram_label in xe_hwmon_thermal_info. - Remove a magic number. - Change the label from vram_X to vram_ch_X. v5: - Address review comments from Raag. - Change vram to VRAM in commit title and subject. - Refactor BMG_VRAM_TEMPERATURE_N macro. - Refactor is_vram_ch_available(). - Rephrase a comment. - Check individual VRAM temperature limits in addition to VRAM availability in xe_hwmon_temp_is_visible. (Raag) - Move VRAM label change out of this patch. v6: - Use in_range() for VRAM_N index check instead of if check. (Raag) - Minor aesthetic changes. Signed-off-by: Karthik Poosa Reviewed-by: Raag Jadav Link: https://patch.msgid.link/20260112203521.1014388-5-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi

drm/xe: Allow compressible surfaces to be 1-way coherent

2026-01-09T22:55:58Z

Previously, compressible surfaces were required to be non-coherent (allocated as WC) because compression and coherency were mutually exclusive. Starting with Xe3, hardware supports combining compression with 1-way coherency, allowing compressible surfaces to be allocated as WB memory. This provides applications with more efficient memory allocation by avoiding WC allocation overhead that can cause system stuttering and memory management challenges. The implementation adds support for compressed+coherent PAT entry for the xe3_lpg devices and updates the driver logic to handle the new compression capabilities. v2: (Matthew Auld) - Improved error handling with XE_IOCTL_DBG() - Enhanced documentation and comments - Fixed xe_bo_needs_ccs_pages() outdated compression assumptions v3: - Improve WB compression support detection by checking PAT table instead of version check v4: - Add XE_CACHE_WB_COMPRESSION, which simplifies the logic. v5: - Use U16_MAX for the invalid PAT index. (Matthew Auld) Bspec: 71582, 59361, 59399 Cc: Matthew Auld Cc: Matt Roper Signed-off-by: Xin Wang Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260109093007.546784-1-x.wang@intel.com Signed-off-by: Matt Roper

drm/xe/soc_remapper: Add system controller config for SoC remapper

2025-12-23T19:43:51Z

Define system controller config bits and helpers for SoC remapper. Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Badal Nilawar Link: https://patch.msgid.link/20251223183943.3175941-8-umesh.nerlige.ramappa@intel.com

drm/xe/soc_remapper: Use SoC remapper helper from VSEC code

2025-12-23T19:43:49Z

Since different drivers can use SoC remapper, modify VSEC code to access SoC remapper via a helper that would synchronize such accesses. Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Badal Nilawar Link: https://patch.msgid.link/20251223183943.3175941-7-umesh.nerlige.ramappa@intel.com

drm/xe/oa/uapi: Expose MERT OA unit

2025-12-17T01:08:24Z

A MERT OA unit is available in the SoC on some platforms. Add support for this OA unit and expose it to userspace. The MERT OA unit does not have any HW engines attached, but is otherwise similar to an OAM unit. Signed-off-by: Lucas De Marchi Reviewed-by: Umesh Nerlige Ramappa Signed-off-by: Ashutosh Dixit Link: https://patch.msgid.link/20251205212613.826224-2-ashutosh.dixit@intel.com

drm/xe: Track pre-production workaround support

2025-12-13T05:17:10Z

When we're initially enabling driver support for a new platform/IP, we usually implement all workarounds documented in the WA database in the driver. Many of those workarounds are restricted to early steppings that only showed up in pre-production hardware (i.e., internal test chips that are not available to the general public). Since the workarounds for early, pre-production steppings tend to be some of the ugliest and most complicated workarounds, we generally want to eliminate them and simplify the code once the platform has launched and our internal usage of those pre-production parts have been phased out. Let's add a flag to the device info that tracks which platforms still have support for pre-production workarounds for so that we can print a warning and taint if someone tries to load the driver on a pre-production part for a platform without pre-production workarounds. This will help our internal users understand the likely problems they'll encounter if they try to load the driver on an old pre-production device. The Xe behavior here is similar to what we've done for many years on i915 (see intel_detect_preproduction_hw()), except that instead of manually coding up ranges of device steppings that we believe to be pre-production hardware, Xe will use the hardware's own production vs pre-production fusing status, which we can read from the FUSE2 register. This fuse didn't exist on older Intel hardware, but should be present on all platforms supported by the Xe driver. Going forward, let's set the expectation that we'll start looking into removing pre-production workarounds for a platform around the time that platforms of the next major IP stepping are having their force_probe requirement lifted. This timing is just a rough guideline; there may be cases where some instances of pre-production parts are still being actively used in CI farms, internal device pools, etc. and we'll need to wait a bit longer for those to be swapped out. v2: - Fix inverted forcewake check v3: - Invert flag and add it to the platforms on which we still have pre-prod workarounds. (Jani, Lucas) v4: - Avoid checking pre-production on VF since they don't have access to the FUSE2 register. Bspec: 78271, 52544 Reviewed-by: Lucas De Marchi Link: https://patch.msgid.link/20251212181411.294854-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe: Create page reclaim list on unbind

2025-12-13T00:59:09Z

Page reclaim list (PRL) is preparation work for the page reclaim feature. The PRL is firstly owned by pt_update_ops and all other page reclaim operations will point back to this PRL. PRL generates its entries during the unbind page walker, updating the PRL. This PRL is restricted to a 4K page, so 512 page entries at most. v2: - Removed unused function. (Shuicheng) - Compacted warning checking, update commit message, spelling, etc. (Shuicheng, Matthew B) - Fix kernel docs - Moved PRL max entries overflow handling out from generate_reclaim_entry to caller (Shuicheng) - Add xe_page_reclaim_list_init for clarity. (Matthew B) - Modify xe_guc_page_reclaim_entry to use macros for greater flexbility. (Matthew B) - Add fallback for PTE outside of page reclaim supported 4K, 64K, 2M pages (Matthew B) - Invalidate PRL for early abort page walk. - Removed page reclaim related variables from tlb fence (Matthew Brost) - Remove error handling in *alloc_entries failure. (Matthew B) v3: - Fix NULL pointer dereference check. - Modify reclaim_entry to QW and bitfields accordingly. (Matthew B) - Add vm_dbg prints for PRL generation and invalidation. (Matthew B) v4: - s/GENMASK/GENMASK_ULL && s/BIT/BIT_ULL (CI) v5: - Addition of xe_page_reclaim_list_is_new() to avoid continuous allocation of PRL if consecutive VMAs cause a PRL invalidation. - Add xe_page_reclaim_list_valid() helpers for clarity. (Matthew B) - Move xe_page_reclaim_list_entries_put in xe_page_reclaim_list_invalidate. Signed-off-by: Brian Nguyen Reviewed-by: Matthew Brost Cc: Shuicheng Lin Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20251212213225.3564537-17-brian3.nguyen@intel.com

drm/xe/rtp: Whitelist OAM MMIO trigger registers

2025-12-04T21:37:41Z

Whitelist OAM registers to enable userspace to execute MMIO triggers on OAM units. Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20251202025115.373546-6-ashutosh.dixit@intel.com