summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-04-28drm/amdgpu/vcn: set no_user_fence for VCN v3.0 enc/dec ringsYinjie Yao
VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: cf14826cdfb5 ("drm/amdgpu: add VCN3.0 support for Sienna_Cichlid") Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yinjie Yao <yinjie.yao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amdgpu/vcn: set no_user_fence for VCN v2.5 enc/dec ringsYinjie Yao
VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 28c17d72072b ("drm/amdgpu: add VCN2.5 basic supports") Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yinjie Yao <yinjie.yao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: properly handle family setting for early GC 11.5.4Alex Deucher
Early variants need an override. Fixes: 57d00816c6a9 ("drm/amdgpu: set family for GC 11.5.4") Cc: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Cc: Roman Li <Roman.Li@amd.com> Cc: Mario Limonciello <superm1@kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Tested-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amdgpu/vcn: set no_user_fence for VCN v2.0 enc/dec ringsYinjie Yao
VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 1b61de45dfaf ("drm/amdgpu: add initial VCN2.0 support (v2)") Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yinjie Yao <yinjie.yao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amdgpu: Move amdgpu_device_check_iommu_direct_map() earlierPhilip Yang
So device init ram_is_direct_mapped is available when gmc_funcs are selected during IP early init. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/pm: Update emit clock logicLijo Lazar
If only one level is enabled in clock table, there is no need to follow the fine grained clock logic which expects a minimum of two levels (min/max). Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Promote DC to 3.2.380Taimur Hassan
This version brings along following update: -Fix root clock disabled when DSC power gate disabled for DCN314 -Enable/Disable some power gating -Remove Mall, SubVP and MCLK from DCN42 -Unify fast update classification paths -Fix narrowing boundaries in dml -Update MCIF_ADDR macro to address IGT DWB regression -Fix dual cursor shows on extend desktop -Fix hubp tmz field define mismatch Acked-by: Alex Hung <Alex.Hung@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: [FW Promotion] Release 0.1.57.0Taimur Hassan
[Why & How] Modify some IPS related commands. Acked-by: Alex Hung <Alex.Hung@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: fix root clock disabled when DSC power gate disabled for DCN314Jing Zhou
[Why] When set debug.disable_dsc_power_gate = true, the original code uses an early return to skip the power gate sequence and root clock enable and disable. For this case, install new driver without uninstall old driver. The sequence like below: 1. On the power-off path, the old driver will power gate dsc and disable_dsc() (root clock disable) due to debug.disable_dsc_power_gate = false. 2. On the power-on path, the new driver will force power on dsc but skip enable_dsc() (root clock enable) due to debug.disable_dsc_power_gate = true. Finally, when mode needs DSC but the root clock is disabled, underflow happened. [How] - Moving enable_dsc() before the disable_dsc_power_gate check so the root clock is always enabled on the power-on path. - Replacing the early return with a goto that skips only the power gate register writes, allowing disable_dsc() to still execute on the power-off path. Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Jing Zhou <Jing.Zhou@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Disable hpo power gateLeo Chen
[Why & How] Disable HPO power gate temporarily to work around some DP 2 LL compliance failures on DCN42. Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Leo Chen <leo.chen@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Remove Mall, SubVP and MCLK from DCN42Ivan Lipski
[Why&How] Remove MALL, SubVP and MCLK features from DCN42 resource file since it is an APU and does not support them. Assisted-by: Claude:opus-4.6 Reviewed-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Unify fast update classification pathsRafal Ostrowski
[Why] The dc_fast_update intermediate struct created code duplication and complexity with multiple classification paths (populate_fast_updates, fast_nonaddr_updates_exist, full_update_required). This refactoring simplifies the update classification system by consolidating to a single path while maintaining compatibility and adding comprehensive test coverage for fast sequence functionality. [How] Remove entire dc_fast_update struct and associated helper functions: - populate_fast_updates - fast_nonaddr_updates_exist - full_update_required and - Refactor check_update_surfaces_for_stream as the single classification path with explicit handling for func_shaper, lut3d_func, cursor_csc_color_matrix_change and scaler_sharpener_update. - Add reserved bitfields to surface_update_flags and stream_update_flags unions for completeness guards. - Extract dc_check_address_only_update and dc_check_update_surfaces_for_stream as public. - Add comprehensive test coverage with parameterized tests for all FAST flags, update classification tests for MED/FULL paths, and completeness guard tests. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Rafal Ostrowski <rafal.ostrowski@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Fix narrowing boundaries in dmlGaghik Khachatrian
[Why] DML code paths include implicit integer narrowing at protocol and storage boundaries. Making these boundaries explicit improves clarity and reduces warning noise while preserving behavior. [How] Apply explicit C-style casts at intentional narrowing boundaries across DML calculation, mode support, RQ/DLG, wrapper, and DSC helper paths. Keep intermediate arithmetic in natural-width types where practical, with minor type-consistency cleanups where needed. Add explicit boundary casts for intentional narrowing and keep intermediate math in wider types where practical, with small type-consistency cleanups to maintain behavior and readability. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amdkfd: Validate CRIU-restored IDs before idr_allocSrinivasan Shanmugam
The KFD CRIU restore flow restores previously saved object IDs from userspace. For event restore: kfd_criu_restore_event() -> create_signal_event() / create_other_event() -> allocate_event_notification_slot() -> idr_alloc(..., *restore_id, *restore_id + 1, ...) For BO restore: criu_restore_memory_of_gpu() -> idr_alloc(..., bo_priv->idr_handle, ...) In both cases, the restored ID comes from userspace-provided CRIU data. idr_alloc() expects the ID range values to fit within signed int limits. If a restored ID is larger than INT_MAX, it can trigger a WARN in the IDR layer. A kernel WARN is undesirable because it prints a warning trace and may cause a panic or reboot on systems with panic_on_warn enabled. Smatch reported these paths as allowing unchecked userspace values to reach idr_alloc(). Add INT_MAX validation before using restored IDs in: - kfd_criu_restore_event() - criu_restore_memory_of_gpu() If the restored ID is invalid, return -EINVAL. This prevents invalid restore data from reaching the IDR layer and avoids WARN-triggering paths, while keeping valid restore behavior unchanged. Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events") Reported-by: Dan Carpenter <error27@gmail.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: David Yat Sin <david.yatsin@amd.com> Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amdgpu: rework userq fence signal processingChristian König
Move more code into a common userq function. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amdgpu: move read_indexed_register to amdgpu_reg_accessGabriel Almeida
The read_indexed_register helper is duplicated across multiple files with identical logic. Move it to amdgpu_reg_access.c as amdgpu_read_indexed_register and update all users accordingly. No functional changes intended. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gabriel Almeida <gabrielsousa230@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amdgpu: move program_aspm to amdgpu_nbioGabriel Almeida
The program_aspm helper is duplicated across multiple files with identical logic. Move it to amdgpu_nbio.c as amdgpu_nbio_program_aspm and update all users accordingly. Signed-off-by: Gabriel Almeida <gabrielsousa230@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Enable HUBP/OPTC/DPP power gatingLeo Chen
[Why & How] Enable driver power gating on DCN42 for HUBP OPTC and DPP HW blocks. Reviewed-by: Ovidiu Bunea <ovidiu.bunea@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Leo Chen <leo.chen@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Fix implicit conversion warningGaghik Khachatrian
[Why & How] Fix implicit narrowing conversion warnings. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Update MCIF_ADDR macro to address IGT DWB regressionGaghik Khachatrian
[Why] A previous warning-fix commit updated type casts in the DCN3 mmhubbub code but missed updating the MCIF_ADDR macro to the correct, fully parenthesized and casted version. This caused a regression during DWB tests, where address values could be misinterpreted, potentially leading to incorrect hardware programming. [How] Updated the MCIF_ADDR macro in dcn30_mmhubbub.c to use the proper parenthesization and type casting, ensuring correct address handling. Removed redundant casts from REG_UPDATE calls for improved clarity and consistency with current coding standards. Fixes: f4cdbb5d5405 ("drm/amd/display: Fix implicit narrowing conversion warnings") Reviewed-by: Clayton King <clayton.king@amd.com> Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: fix dual cursor shows on extend desktopCharlene Liu
[why & how] when dpp pipe power gating disabled in driver, disable_pipe did not disable cursor so next time as long as this pipe powers up, it will be visible. port dcn314 logic: disable cursor when it should be pipe pg. Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: fix hubp tmz field define mismatchCharlene Liu
[why & how] to make hubp surface_flip_registers field define mismatch with dc_plane_address Reviewed-by: Dillon Varone <dillon.varone@amd.com> Reviewed-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/amd/display: Enable driver power gatingLeo Chen
[Why & How] Enable driver power gating. Temporarily disable DIO power gating. Reviewed-by: Ovidiu Bunea <ovidiu.bunea@amd.com> Signed-off-by: Leo Chen <leo.chen@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-28drm/i915/dp: Skip AS SDP for DP branch devicesAnkit Nautiyal
Currently, VRR is not implmented for DP branch devices. So skip sending AS SDP for them. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260424090942.3060291-4-ankit.k.nautiyal@intel.com
2026-04-28drm/i915/dp: Add a helper to decide if AS SDP can be usedAnkit Nautiyal
Add a helper that determines whether AS SDP can be used for the current DP configuration. For now this is true only when the sink supports AS SDP and VRR is enabled, but more conditions may be added later. v2: - Rename to intel_dp_needs_as_sdp(). (Ville) - Add a #FIXME documenting non-atomic of DP SDP updates. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260424090942.3060291-3-ankit.k.nautiyal@intel.com
2026-04-28drm/i915/vrr: Avoid vrr for PCON with HDMI2.1 sinkAnkit Nautiyal
Currently we do not support VRR with HDMI so skip vrr compute config step for all DP branch devices. v2: Restrict VRR on all DP branch devices instead for checking only for HDMI. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260424090942.3060291-2-ankit.k.nautiyal@intel.com
2026-04-28drm/nouveau: WQ_PERCPU added to alloc_workqueue usersMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This change adds a new WQ_PERCPU flag to explicitly request alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20251031102020.95349-3-marco.crivellari@suse.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-04-28drm/nouveau: replace use of system_unbound_wq with system_dfl_wqMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. system_unbound_wq should be the default workqueue so as not to enforce locality constraints for random work whenever it's not required. Adding system_dfl_wq to encourage its use when unbound work should be used. The old system_unbound_wq will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251031102020.95349-2-marco.crivellari@suse.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-04-28drm/udl: Increase GET_URB_TIMEOUTShixiong Ou
[WHY] A situation has occurred where udl_handle_damage() executed successfully and the kernel log appears normal, but the display fails to show any output. This is because the call to udl_get_urb() in udl_crtc_helper_atomic_enable() failed without generating any error message. [HOW] 1. Increase timeout of getting urb. 2. Add error messages when calling udl_get_urb() failed in udl_crtc_helper_atomic_enable(). Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: <stable@vger.kernel.org> # v3.4+ Link: https://patch.msgid.link/20260424124427.657-1-oushixiong1025@163.com
2026-04-27drm/xe/gt: Drop redundant forcewakeRaag Jadav
xe_gt_suspend_prepare() doesn't perform any MMIO operation that requires forcewake in it's code path. Drop it. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>$ Link: https://patch.msgid.link/20260427092928.1181893-4-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-04-27drm/xe/guc_pc: Reorder forcewake in xe_guc_pc_fini_hw()Raag Jadav
xe_guc_pc_stop() doesn't perform any MMIO operation that requires forcewake in it's code path. Move it before pc_set_cur_freq() which writes to RPNSWREQ and actually requires it. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260427092928.1181893-3-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-04-27drm/xe/guc_pc: Make xe_guc_pc_stop() voidRaag Jadav
xe_guc_pc_stop() doesn't return any meaningful value. Refactor it into void function. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260427092928.1181893-2-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-04-27drm/xe: Mark BCS engines as belonging to the GT forcewake domainMatt Roper
On all platforms supported by the Xe driver, BCS engines are part of the GT forcewake domain, not the RENDER domain. Fix the engine list definition to match the spec. This mistake didn't really cause any real problems because the forcewake domain here was only used in a couple assertions that aren't really necessary and included in the information dumped during error capture. Bspec: 66696, 66534, 67609, 71185, 74417, 75242, 78286 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-10-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Drop xe_hw_engine_mmio_write32()Matt Roper
xe_hw_engine_mmio_write32() is only used in a single place and is easily replaced by a regular xe_mmio_write32() call. Register read/write interfaces are already complicated enough with MCR vs non-MCR handling, so we should avoid adding extra wrappers that just make it more confusing what to use. xe_hw_engine_mmio_write32() did have a forcewake assertion that we're dropping here, but that assertion wasn't entirely correct anyway. It was checking hwe->domain which is currently set to XE_FW_RENDER for the BCS engine, even though BCS engines reside in the GT domain. v2: - Drop prototype in header file as well. (Shuicheng) Cc: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-9-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Drop unnecessary STOP_RING clearingMatt Roper
The STOP_RING bit in MI_MODE is already clear by default out of hardware reset and will only be '1' if the driver intentionally sets it after that. The logic of clearing this bit appears to originate from very early (pre-GuC, pre-execlist) code in i915 where we needed to stop the ring before performing a host-initiated engine reset; after the reset the STOP_RING bit needed to be cleared to allow execution to resume. None of that is relevant to Xe (or even modern i915) since STOP_RING isn't necessary for execlist-based engine resets (and even if it were, Xe doesn't initiate any engine resets; the GuC handles that now). Bspec: 60356, 60184 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-8-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Move GFX_MODE programming to RTPMatt Roper
The write GFX_MODE to disable engine "legacy mode" and to enable MSI-X support was unnecessarily open-coded in xe_hw_engine_enable_ring(); it's preferable to do such programming in the engine_entries[] RTP table since gets reflected/verified in debugfs, and will also automatically ensure that the register is properly saved/restored around engine resets. This also helps consolidate common logic that was duplicated between the main driver initialization path and the dead-code execlist initialization path. This also allows us to drop GFX_MODE from the list of extra registers to be added to the GuC ADS' save-restore list since all registers on the RTP table are added automatically. v2: - Actually use the xe_rtp_match_has_msix match function added. (Shuicheng) Cc: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-7-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Const-ify parameters to xe_device_has_* functionsMatt Roper
None of these functions modify the Xe device parameter, and marking it as const will avoid warnings when the callsite wants to pass a const pointer. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-6-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Fix name and definition of GFX_MODE registerMatt Roper
The register located at $base+0x29c is referred to as GFX_MODE in the bspec. Although many other registers have RING_* prefixes for historical reasons, this register does not, so using a name that does not match the bspec just makes it harder to recognize/find. Also, GFX_MODE is a masked register (updating bits [15:0] requires that the corresponding bit(s) in [31:16] are also set), so add the XE_REG_OPTION_MASKED flag to the register definition; this will become important when we start programming this register via RTP tables in a future patch. Finally swap the order of the register's two bit definitions to match our regular coding style of descending order for register bits/fields. Bspec: 45928 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-5-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Move HWSTAM programming to RTPMatt Roper
The write to RING_HWSTAM to disable hardware status page writes on interrupt was unnecessarily open-coded in xe_hw_engine_enable_ring(); it's preferable to do such programming in the engine_entries[] RTP table since gets reflected/verified in debugfs, and will also automatically ensure that the register is properly saved/restored around engine resets. In this case the HWSTAM register wasn't explicitly added to the GuC ADS' save-restore list, so there was the potential for the value to be lost on engine resets. This doesn't seem to have happened in practice, so likely the GuC firmware is automatically saving/restoring this register on our behalf, but we shouldn't rely on this implicit behavior going forward. One other slight change with this patch is that HWSTAM will now be programmed on the vestigial execlist (non-GuC) initialization path. Since the register's default value is 0x0 and the documentation indicates that it's only legal to leave a single bit unmasked at a time, this likely would have been an illegal situation if the execlist code were actually usable. Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-4-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Stop programming BLIT_CCTL on Xe2 and later platformsMatt Roper
Xe1 platforms used the BLIT_CCTL register to specify the MOCS value that would be used for BCS engine instructions that did not have a way of specifying a MOCS index directly. From Xe2 onward, all BCS instructions now have explicit instruction fields for specifying a MOCS index and the BLIT_CCTL register is now a dummy register with no valid fields. Although continuing to write to it today has no effect, the register could repurposed in future platforms, so restrict the BLIT_CCTL RTP entry to only apply to Xe1 platforms. Bspec: 60280 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-3-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe/rtp: Add "always true" match functionMatt Roper
All RTP table entries are required to have at least one rule. In cases where an entry should apply unconditionally across all platforms we've been using a graphics version range of 12.00 - forever since this covers all platforms supported by the driver. However if the primary GT is disabled via configfs (not actually possible today, but probably possible in the future) or if we have a future platform that lacks a primary GT and only supports media/display, this rule would cause important programming to fail to apply on the media GT. Add a simple match function that just always returns true unconditionally. This solves the worries above while also being more immediately human-readable. Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-2-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Move CCS enablement to engine setup RTPMatt Roper
Most register programming for engine setup happens via RTP tables in hw_engine_setup_default_state(). Move the programming of RCU_MODE[0] which enables the platform's CCS engine(s) there. This both makes the code more consistent (other RCU_MODE register programming is already happening in this RTP table) and improves debuggability (since RTP contents and checks of their correct programming are exposed via debugfs). It also helps consolidate the regular driver initialization paths with the vestigial and currently unused execlist (i.e., non-GuC) initialization. With the original programming, the RCU_MODE register (which is a single global register, not a per-engine register) was getting re-programmed with the same value during the initialization of each CCS engine. When moved to the RTP table, we use the xe_rtp_match_first_render_or_compute match function so that it will just be programmed once, while doing the initialization for the first RCS/CCS engine, which avoids the redundant and unnecessary repetition. We can also safely drop the explicit addition of RCU_MODE from the GuC ADS save-restore list now since all registers programmed via RTP tables are automatically added to the GuC's list. v2: - Only enable CCS engines on Xe_HP and later. Even though Xe_LP platforms technically have a CCS engine, it's never been enabled on i915 or Xe due to other issues on these old platforms. Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260424-engine-setup-v2-1-59cc620a25f1@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/xe: Steer MCR for NODE/L3BANK according to L3 fusing on Xe2/Xe3Matt Roper
Although the bspec currently indicates that steered reads/writes to L3 register ranges are never terminated for physically present instances (regardless of fusing) on Xe2, it turns out this is information is incorrect. The hardware architects have also confirmed that the current documentation is wrong (or that possibly the wording was intended to be interpreted in a different way), but have not yet provided an official spec update. All of our driver's writes to registers in these ranges are done as multicast, so steering is not actually important to proper driver operation; the only impact of this documentation mistake is that on some fused-down SKUs where the first L3 bank is absent we're not able to properly read back the values that were written to those registers to confirm that the writes were applied correctly (e.g., when using the register-save-restore-check debugfs interface). Since we don't have an official spec update yet, let's assume that Xe2/Xe3 use the same fuse => steering logic as Xe3p. I.e., remove L3BANK and NODE register ranges from the "INSTANCE0" steering group and add handle them with dedicated handling according to the L3 fuses. From testing on various fused-down platforms this does appear to give proper steering and fix the failures reported by IGT's igt@xe_debugfs@check-gt-reg-sr test. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7706 Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260421-xe2_l3bank_steering-v1-1-613158a27383@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-27drm/tyr: Add DOORBELL_BLOCK registersDeborah Brouwer
DOORBELL_BLOCK_n[0-63] is an array of GPU control register pages. Each block is memory-mappable and contains a single DOORBELL register used to trigger actions in the GPU. Add definitions for the DOORBELL_BLOCK registers using the register! macro so they can be used by future Tyr interfaces. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-6-8abfff8a0204@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Remove custom register structDeborah Brouwer
Now that Tyr uses the register! macro, it no longer needs to define a custom register struct or read/write functions, so delete them. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-5-8abfff8a0204@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Use register! macro for MMU_CONTROLDeborah Brouwer
Define the MMU_CONTROL register block with the kernel's register! macro and replace the existing hand-written MMU register definitions with typed register and field accessors. This adds typed definitions for the MMU IRQ registers and the per-address space MMU_AS_CONTROL registers, including TRANSTAB, MEMATTR, LOCKADDR, COMMAND, FAULTSTATUS, STATUS, and TRANSCFG. It also introduces typed enums for MMU commands, fault types, access types, address space modes, memory attributes, and related MMU configuration fields. For logical 64-bit MMU registers that are exposed as split 32-bit MMIO registers, define both the typed 64-bit view and explicit low/high 32-bit registers so the register layout remains documented without relying on native 64-bit MMIO accesses. This reduces open-coded bit manipulation, keeps MMU register layout knowledge in one place, and makes the definitions easier to read and maintain. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-4-8abfff8a0204@collabora.com [aliceryhl: reformat long comment] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Use register! macro for JOB_CONTROLDeborah Brouwer
Define the JOB_CONTROL register block with the kernel's register! macro and replace the existing hand-written JOB IRQ register definitions with typed register and field accessors. This adds typed definitions for the raw status, clear, mask, and status registers, including the per-CSG interrupt bits and the global interface interrupt bit. This reduces open-coded bit manipulation, keeps the JOB_CONTROL register layout in one place, and makes the definitions easier to read and maintain. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-3-8abfff8a0204@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Print GPU_ID without filteringDeborah Brouwer
Currently, Tyr prints just the upper 16 bits of the GPU_ID in the hex id field, namely ARCH_MAJOR, ARCH_MINOR, ARCH_REV, and PRODUCT_MAJOR. The VERSION_* fields are already printed separately as "major", "minor", and "status". Print the full 32-bit GPU_ID register instead of shifting it, so the hex id reflects the complete register contents. Before this change: mali-g610 id 0xa867 major 0x0 minor 0x0 status 0x5 After this change: mali-g610 GPU_ID 0xa8670005 major 0x0 minor 0x0 status 0x5 Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-2-8abfff8a0204@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27drm/tyr: Use register! macro for GPU_CONTROLDaniel Almeida
Define the GPU_CONTROL register block with the kernel's register! macro and switch the current GPU control paths over to the new typed register definitions. This replaces manual register constants, bit masks, shifts, and the hand-written GpuId parsing code with typed register and field accessors. It also adds helpers for combining split 64-bit registers and uses the new definitions in reset, L2 power-on, and GPU info readout/logging paths. This reduces open-coded bit manipulation making the code easier to read and maintain. Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Co-developed-by: Deborah Brouwer <deborah.brouwer@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-1-8abfff8a0204@collabora.com [aliceryhl: reformat long comment] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-04-27gpu: nova-core: simplify and_then with condition to filterEliot Courtney
This code is more simply expressed using Option::filter instead of the and_then with conditional. This fixes the following warning with latest nightly Rust clippy build: warning: manual implementation of `Option::filter` --> drivers/gpu/nova-core/firmware.rs:391:14 | 391 | .and_then(|hdr| { | ______________^ 392 | | if hdr.bin_magic == BIN_MAGIC { 393 | | Some(hdr) 394 | | } else { ... | 397 | | }) | |______________^ help: try: `filter(|hdr| hdr.bin_magic == BIN_MAGIC)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_filter = note: `-D clippy::manual-filter` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_filter)]` Cc: stable@vger.kernel.org Fixes: d6cb7319e64e ("gpu: nova-core: firmware: add support for common firmware header") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260423-fix-filter-v1-1-b3b197c65daf@nvidia.com [aliceryhl: add Fixes: tag and quote the warning it fixes] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-03 05:11:29 +0000