summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-08-06drm/radeon: restore hardware polling in fence_is_signaled to fix performance ↵Wang Jiang
regression Commit 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock") removed the hardware polling from radeon_fence_is_signaled() to fix a self-deadlock caused by wake_up_all(&rdev->fence_queue) being called with the fence queue lock held. However, removing the polling entirely causes significant performance regression (e.g. glxgears FPS drop) because the fence signaled check becomes purely passive — it only reads the cached last_seq without probing the GPU, so completed GPU work is not detected in time, causing unnecessary CPU stalls in sync-heavy workloads. Fix this by calling radeon_fence_activity() directly instead of radeon_fence_process(). radeon_fence_activity() reads the hardware fence counter and updates last_seq via atomic ops without calling wake_up_all(), thus avoiding the deadlock while restoring timely fence detection. Fixes: 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock") Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Wang Jiang <jiangwang@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f59ad4cca219c7fdf934f712c5860ec5f5900fd7) Cc: stable@vger.kernel.org
2026-08-06drm/amd: Disable DP audio spread spectrum for Cyan SkillfishTravis K. Bangs
The VBIOS for Cyan Skillfish devices (DCN201) indicates there is DisplayPort ref clock spread spectrum downspread, so the audio clock is corrected for it. However, the clock source in this hardware does not seem to actually be running with a clock downspread, so DisplayPort audio desyncs with video after several minutes. Ignore dprefclk SS downspread on CYAN_SKILLFISH2 asic. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5429 Signed-off-by: Travis K. Bangs <tbangs89@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f3a2d86587432fdd9a6d401507b60a01153453c5) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu/gmc12.1: fix MMHUB0 check in pasid tlb flushAlex Deucher
Check for mmhub0 rather than mmhub1. Looks like a copy paste typo. Fixes: d0c989a0aad3 ("drm/amd/amdgpu : Use the MES INV_TLBS API for tlb invalidation on gfx12_1") Cc: Shaoyun Liu <shaoyun.liu@amd.com> Reviewed-by: Shaoyun Liu <shaoyun.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0e8faef0aaa4d08f3f4f67ee7bb74e1babc8efc4) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: Allocate coredump ring buffers per ringLijo Lazar
Allocate each ring buffer separately. A single allocation summing all ring sizes can exceed the page allocator's MAX_ORDER limit and fail; per-ring buffers stay small enough to satisfy. The existing allocation style doesn't capture any ring data if the huge allocation fails. Splitting into multiple allocations helps to capture as much data as possible for the core dump. A failed ring is left with a NULL buffer and skipped when formatting. Fixes: eea85914d15b ("drm/amdgpu: save ring content before resetting the device") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Assisted-by: Claude Code Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3e8e92b7892a6377bef86106bfff1b98cf586aee) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: Use virtual alloc during coredumpLijo Lazar
The number of rings with outstanding fences can be large, requiring a bigger allocation. Such allocations don't need to be physically contiguous, so use kvzalloc/kvcalloc which fall back to vmalloc when contiguous memory isn't available. This also matches the existing kvfree used to free these allocations. Also guard the allocation with ring_count to avoid passing 0 size to allocation routines. Fixes: eea85914d15b ("drm/amdgpu: save ring content before resetting the device") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 74d48bd6b7e12eba65de0507475b059966685ad1) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: reject oversized IBs with per-ring packet limitsCandice Li
On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission. Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types. Signed-off-by: Candice Li <candice.li@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu/userq: serialize queue map against GPU resetJesse Zhang
Creating a user queue can race with a GPU reset. While recovery holds reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue create fails: amdgpu: MES(0) failed to respond to msg=ADD_QUEUE [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110) amdgpu: [drm] *ERROR* ... Failed to map Queue amdgpu: [drm] *ERROR* ... Failed to create usermode queue Take reset_domain->sem for read around the map so it runs only once MES is back up. This mirrors amdgpu_userq_cleanup() and honors the userq_mutex -> reset_domain->sem order; the reset path never takes userq_mutex, so there is no deadlock. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a8e151fe629c63b0eb08aa57de0d434614db3e1b) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: Fix lockdep false positive in amdgpu_lockdep_initVitaly Prosyak
Move fs_reclaim_acquire() to before all lock acquisitions to eliminate false positive circular locking dependency warning. This is a 7.2-cycle regression fix suitable for stable backport. v3: Address Mikhail Gavrilov technical review: - Clarify that fs_reclaim_acquire/release pair only REGISTERS the fs_reclaim lock class, does NOT create a static edge when called with no locks held - Explain that the actual fs_reclaim -> notifier_lock edge is established at runtime during memory reclaim -> MMU notifier path - Add Cc: Arunpravin PaneerSelvam v2: Address Mikhail Gavrilov review feedback: - Fix author name: Michael -> Mikhail Gavrilov in all trailers - Add Fixes: tag to link regression to original commit - Add Tested-by: Mikhail Gavrilov (tested on RX 7900 XTX) Fixes: 1d0f5838b126 ("drm/amdgpu: Add lockdep annotations for lock ordering validation") Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Analyzed-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Test-case-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Suggested-by: Christian König <christian.koenig@amd.com> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Arunpravin PaneerSelvam <Arunpravin.PaneerSelvam@amd.com> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Acked-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 70a1e9849e6ed12bb9f1c0faa24b0f1f9de601eb) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu/gmc12.1: implement tlb inv semaphoreAlex Deucher
Needed to properly lock the interface before using it. Cc: Sonny Jiang <sonny.jiang@amd.com> Reviewed-by: Sonny Jiang <sonny.jiang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8e37aa0bd56ba75801a6a21bed45f96372cd9fdc) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12Qiang Yu
TA_CNTL2.TRUNCATE_COORD_MODE selects whether texture coordinate truncation is D3D9/GL/Vulkan conformant. gfx11 reads it and reports it to userspace via AMDGPU_IDS_FLAGS_CONFORMANT_TRUNC_COORD, but gfx12 never read it, so the flag was always reported as 0 and userspace fell back to the non-conformant path. Read it in gfx_v12_0_constants_init() like gfx11 does. Fixes: 52cb80c12e8a ("drm/amdgpu: Add gfx v12_0 ip block support (v6)") Signed-off-by: Qiang Yu <Qiang.Yu@amd.com> Reviewed-by: Marek Olšák <maraeo@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4261cbc7b03f1f56e95aeaf1492b8690fa5a253e) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: fix JPEG v5.3.0 queue reset failure in DPG modeJesse Zhang
Like jpeg_v5_0_0, in DPG mode the ring reset path only clears the JPEG_PG_MODE bit and never resets a hung JRBC, so the post-reset ring test times out and the driver falls back to a full MODE1 reset. Temporarily force the static power-gating path during the reset so the stop/start sequence power-cycles the JPEG block (JMI soft reset + power off/on), matching the jpeg_v4_0 reset. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e93659cab11c48255dcac58af60203c99815586b) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: fix JPEG v4.0.5 queue reset failure in DPG modeJesse Zhang
Like jpeg_v5_0_0, in DPG mode the ring reset path only clears the JPEG_PG_MODE bit and never resets a hung JRBC, so the post-reset ring test times out and the driver falls back to a full MODE1 reset. Temporarily force the static power-gating path during the reset so the stop/start sequence power-cycles the JPEG block (JMI soft reset + power off/on), matching the jpeg_v4_0 reset. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 75a308eef4503a9d2bf297bef5a9317d2209e696) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: fix JPEG v5.0.0 queue reset failure in DPG modeJesse Zhang
In DPG mode jpeg_v5_0_0_ring_reset() takes the DPG stop path, which only clears the JPEG_PG_MODE bit and never resets the JRBC. A hung ring is not recovered: the post-reset ring test times out and the driver falls back to a full MODE1 reset. Temporarily force the static power-gating path during the reset so the stop/start sequence power-cycles the JPEG block (JMI soft reset + power off/on), matching the jpeg_v4_0 reset which has no DPG path. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 79b3612827d1adcd2008cd585961fa35a6ff20f2) Cc: stable@vger.kernel.org
2026-08-06drm/amdgpu: Fix typo in commentKenji Takahashi
Fix a spelling mistake in a comment. Signed-off-by: Kenji Takahashi <dken4546@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Fix crash in hwss_set_output_transfer_func()Timur Kristóf
The pipe_ctx->plane_res.hubp pointer is NULL on all DCE hardware, which causes a kernel NULL pointer dereference on all Vega and older GPUs. Let's add a simple NULL check. Fixes: 6bfca938471b ("drm/amd/display: Refactor DPP_SET_OUTPUT_TRANSFER_FUNC to drop pipe_ctx") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Cc: Tomasz Siemek <tomasz.siemek@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Set native cursor mode for disabled CRTCs againTimur Kristóf
It was regressed by a refactor. Let's fix it again. Always set native cursor mode when the CRTC is disabled, to make sure it doesn't cause atomic commits to fail when they are trying to disable the CRTC. Fixes: 87a6dab12fc0 ("drm/amd/display: add cursor module") Cc: Alex Hung <alex.hung@amd.com> Reviewed-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu: fix aperture iounmap skipped on device removalAsad Kamal
amdgpu_pci_remove() calls drm_dev_unplug() before invoking the fini routines. After drm_dev_unplug() the drm_dev_enter() guard in amdgpu_ttm_fini() always returns false, so iounmap() for aper_base_kaddr is silently skipped. On connected_to_cpu hardware ioremap_cache() maps the aperture as WB; when iounmap() is skipped the stale WB PAT entry persists. On reload IP discovery's memremap(MEMREMAP_WC) on the same aperture range hits a WB/WC conflict, producing an ioremap error and failing re-probe. Remove the drm_dev_enter() guard and call iounmap() unconditionally. The aperture mapping is plain MMIO and does not require device-presence protection. Surprise-removal cleanup of aper_base_kaddr is already handled unconditionally by amdgpu_device_unmap_mmio(). Fixes: 62d5f9f7110a ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged") Signed-off-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Check for tg ops in dce110_set_avmuteRay Wu
Some older DCE timing generators do not implement is_tg_enabled in their ops table. Calling it unconditionally when waiting for AV mute frames causes a NULL pointer dereference on Southern Islands dGPUs when turning the display off over HDMI. Check that tg and the required ops exist before waiting for frames. Fixes: 414da24137ac ("drm/amd/display: Add AV mute wait frames to dce110_set_avmute") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5557 Tested-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de> Signed-off-by: Ray Wu <ray.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/panel: tdo-tl070wsh30: Use mipi_dsi_*_multi(); fix minor bugsAkash Sukhavasi
The mipi_dsi_dcs_*() functions used by this driver are deprecated in favor of their _multi() counterparts, as noted in Documentation/gpu/todo.rst. The _multi() variants record the first error in a context structure and skip every later call once an error is set, so the return value no longer has to be checked after each command. They also log their own failures, which makes the per-call dev_err() calls redundant. Convert prepare() and unprepare(). prepare() uses mipi_dsi_msleep() for the delays between DSI commands. unprepare() uses plain usleep_range() so the delays run unconditionally after the accumulated error is cleared. The delays in the GPIO reset sequence stay as plain msleep() and usleep_range(), since they run before any DSI transaction. unprepare() now disables the regulator unconditionally and returns 0. Previously a failure of set_display_off() was logged and the sequence continued, while a failure of enter_sleep_mode() returned early, leaving the regulator enabled and the panel unable to be brought back up, since drm_panel_unprepare() skips panel->prepared = false on error. The accumulated error from set_display_off() is cleared so that the delay and enter_sleep_mode() are still attempted, preserving the original fall-through behavior. Both drm_panel_prepare() and drm_panel_unprepare() return void, so the error was never propagated to a caller in any case. Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260730-mipi-dsi-tl070wsh30-multi-v3-1-60592caef4f4@gmail.com
2026-08-06Revert "drm/amdgpu: fix aperture mapping leak"Asad Kamal
devres teardown is LIFO. The aperture devres node was registered after the DRM device node, so devres_release_all() unmaps the aperture before the DRM device release callback fires amdgpu_device_fini_sw(). IP sw_fini callbacks (e.g. vcn_v4_0_sw_fini) write to fw_shared through a pointer derived from aper_base_kaddr, causing a kernel page fault on probe failure / rollback: BUG: unable to handle page fault ... PMD 0 RIP: vcn_v4_0_sw_fini+0x7b/0x170 [amdgpu] Call Trace: amdgpu_device_fini_sw amdgpu_driver_release_kms devm_drm_dev_init_release devres_release_all This reverts commit d871e99879cb5fd1fa798b006b4888887e63a17a. Fixes: d871e99879cb ("drm/amdgpu: fix aperture mapping leak") Reported-by: Yuansheng Mao <yuansheng.mao@amd.com> Signed-off-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/radeon: restore hardware polling in fence_is_signaled to fix performance ↵Wang Jiang
regression Commit 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock") removed the hardware polling from radeon_fence_is_signaled() to fix a self-deadlock caused by wake_up_all(&rdev->fence_queue) being called with the fence queue lock held. However, removing the polling entirely causes significant performance regression (e.g. glxgears FPS drop) because the fence signaled check becomes purely passive — it only reads the cached last_seq without probing the GPU, so completed GPU work is not detected in time, causing unnecessary CPU stalls in sync-heavy workloads. Fix this by calling radeon_fence_activity() directly instead of radeon_fence_process(). radeon_fence_activity() reads the hardware fence counter and updates last_seq via atomic ops without calling wake_up_all(), thus avoiding the deadlock while restoring timely fence detection. Fixes: 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock") Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Wang Jiang <jiangwang@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: allow self-refresh exit while entry is blockedDavid Weber
amdgpu_dm_crtc_set_static_screen_optimze() maps sso_enable to the Replay and PSR1 vsync events. allow_sr_entry is an entry gate, but the helper currently applies it to both directions. A non-fast update clears allow_sr_entry. During a modeset, a separate hardware-programming event keeps self-refresh blocked while the stream is reprogrammed. If vblank is enabled before the entry delay expires, the ISM calls the helper with sso_enable false. The early return drops the disable request, so the vsync events are not set. After enough fast commits, allow_sr_entry becomes true and the hardware-programming event can be cleared. Since the vblank reference remains held, there is no further zero-to-one vblank transition to restore the missing vsync events. Replay or PSR1 can then become active while vblank is still enabled. Gate only requests that enable static-screen optimization. Always process disable requests so a vblank requestor keeps Replay and PSR1 blocked. On a Phoenix system, repeated SDDM-to-VT handoffs produced stuck flips followed by flip_done and commit-wait timeouts. The timeout was not observed with this change applied. Fixes: 3c108046e1d6 ("drm/amd/display: Add power module on Linux") Assisted-by: Codex:gpt-5.6-sol Assisted-by: Claude:opus-5 Signed-off-by: David Weber <weber.aulendorf@gmail.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd: Disable DP audio spread spectrum for Cyan SkillfishTravis K. Bangs
The VBIOS for Cyan Skillfish devices (DCN201) indicates there is DisplayPort ref clock spread spectrum downspread, so the audio clock is corrected for it. However, the clock source in this hardware does not seem to actually be running with a clock downspread, so DisplayPort audio desyncs with video after several minutes. Ignore dprefclk SS downspread on CYAN_SKILLFISH2 asic. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5429 Signed-off-by: Travis K. Bangs <tbangs89@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Enable IP block soft reset as a GPU recovery methodTimur Kristóf
Enable IP block soft reset as a GPU recovery method for GFX6 graphics and compute rings. This improves current user experience on all GFX6 chips. The current GPU recovery method is a legacy ASIC reset which always clears the contents of VRAM, which means that a buggy (hanging) app can crash the whole graphical session, which is less than ideal. Also on some GPUs the ASIC reset causes the GPU to fall off the PCIe bus so it's not desireable. Using GFX IP block soft reset means that we can now move on from GFX hangs on GFX6 dGPUs without crashing the whole system. Tested with the "hard_reset_cp_wait" test case from the Hang Test Suite created by Natalie Vock and Konstantin Seurer. This Vulkan testcase waits for an event that never occurs, effectively a WAIT_REG_MEM packet that intentionally hangs. IP block soft reset can resolve that hang and allow the rest of the system to move on and keep functioning without needing a full ASIC reset. Tested on the following chips: Tahiti (FirePro W9000, Radeon HD 7870 XT) Cape Verde (Radeon R7 450) Pitcairn (Radeon R9 270X) Oland (Radeon 430) Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Add IP block soft reset implementationTimur Kristóf
Update the register definition for GRBM_SOFT_RESET to match what was in the old radeon driver and use these bits in the soft reset implementation. For the soft reset, use basically the same implementation as GFX7-8, the main difference being the GRBM_SOFT_RESET bit fields and the fact that GFX6 doesn't have MQD/HQD. Reset every block using the GRBM, then proceed to reset the GRBM and SEM blocks using the SRBM. The soft reset also calls the clock and powergating functions of the IP block. This is necessary for correct operation, otherwise the GPU might fall off the PCIe bus. Add a gfx_v6_0_late_init() function for consistency with other GPU generations. This function will later serve the same purpose as it does on GFX7+ when we get around to enable more IRQs on GFX6. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Use COND_EXECTimur Kristóf
COND_EXEC tells the CP to discard the dwords following it when its condition is zero (false). This is useful for GPU recovery because it can help reduce collateral damage during GFX IP block soft reset, meaning that it reduces the likelyhood that we fail some jobs which are not guilty of the hang as the IP block soft reset mechanism clears the condition before doing the reset. Note that this packet is only 4 DW on GFX6 (as opposed to GFX7 and newer where it's 5 DW). Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Adjust how harvested TCCs are set upTimur Kristóf
Adjust gfx_v6_0_setup_tcc() to keep it working after a GFX IP block soft reset. On a soft reset, the TCP_CHAN_STEER_LO/HI registers are not cleared so the function needs a slight adjustment to how the number of active TCCs are calculated. Additionally, let's expose the disabled TCC mask in the tcc_disabled_mask field, like on other GPUs. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Execute CLEAR_STATE when initializing compute ringsTimur Kristóf
Emit a compute CLEAR_STATE packet on the compute rings after the GFX ring already finished executing ME_INITIALIZE and before the ring test, so that gfx_v6_0_cp_gfx_resume() can wait until the CLEAR_STATE is complete. For reference, see si_cp_start() in the old radeon driver. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Clean up rings during resetTimur Kristóf
Clear the WPTR and RPTR at ring initialization. Additionally clear the ring contents too. This is necessary so that the IP block soft reset can bring the rings back to a clean state. After a reset, the ring contents could contain packets emitted before the reset, and thus need to be cleared to prevent the command processor from executing packets left over in the ring from before the reset. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Initialize compute rings before CP startTimur Kristóf
In GFX6 GPUs, compute takes the same CP path as graphics. CP ME command parser executes packets for each ring buffer: RB0 supports graphics, RB1 and RB2 are compute only. Initialize all three rings before calling gfx_v6_0_cp_gfx_start() to make sure they are all in a sane state before execution starts. Previously, the two compute-only rings were initialized after the ME had been already started, which could cause the ME to start executing the ring contents before the rings could be properly initialized. This happens to work when the HW is first initialized, but not during an IP block reset where we want to reinitialize the compute rings before starting the ME to prevent it from executing garbage from these rings. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Use PFP on the compute queues tooTimur Kristóf
On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well. Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/gfx6: Fixup emitting SWITCH_BUFFER packetsTimur Kristóf
Implement the emit_switch_buffer() function instead of emitting them duing emit_ib, emit_pipeline_sync and emit_vm_flush. Note that it isn't necessary to emit these in both emit_pipeline_sync() and emit_vm_flush() because amdgpu_vm_flush() already calls these when calling either of those functions. Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/mes11: enable MES process/gang load from MES local memPrike Liang
Enable the MES process/gang context load from MES local memory, this will reduce the MES firmware and driver handshake latency. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Michael Chen <michael.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/ras: Handle the lack of mca address case for unirasTao Zhou
For specific old eeprom data, mca address is not stored, get mca address from physical address(pa) and then convert it into pa in current nps mode. Also set cur_nps early so the record carries the target nps even when the conversion returns early. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/ras: add get_die_id for uniras umc v12Tao Zhou
For legacy ras eeprom format(only existed on nps1 system), die id (node instance) is not stored, we get it from mca address and physical address (pa) here, and now we can calculate pa in any nps mode for legacy ras eeprom data as well. It only applies to num_umc == 16 / UMC_VRAM_TYPE_HBM parts. Also factor out __ras_umc_eeprom_rec2nps_addr() so the die id can be passed in. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdkfd: enable rs64mem for kfd queuePrike Liang
Enabled RS64mem for KFD queues by integrating process and gang context index allocation in the per KFD device process and queue creation. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Michael Chen <michael.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/ras: track debug mode for query modeXiang Liu
The RAS manager uses the rascore debug mode setting to control whether MCA data is read directly or collected through PMFW MCA polling and ClearMcaOnRead. Track that debug mode state in ras_mgr so amdgpu_ras_get_error_query_mode() can classify queries as direct or firmware-backed. Limit the PMFW polling wait in recovery to firmware-backed MODE1 fatal recovery so other reset paths, such as MODE2, do not pay the delay unnecessarily. Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/mes: tear down the rs64mem bitmap in sw_finiPrike Liang
It's more reasonable to tear down the rs64mem bitmap software context at MES sw_fini phase. This also can avoid the following lock order issue. [ 2529.150983] kworker/u64:1/3134 is trying to acquire lock: [ 2529.151206] ffff8aebd9a3fa10 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_bo_free_kernel+0x4e/0x130 [amdgpu] [ 2529.151989] but task is already holding lock: [ 2529.152227] ffff8aebd2411648 (&reset_domain->sem){++++}-{4:4}, at: amdgpu_device_lock_reset_domain+0x20/0x30 [amdgpu] [ 2529.153008] which lock already depends on the new lock. [ 2529.153342] the existing dependency chain (in reverse order) is: [ 2529.153645] -> #2 (&reset_domain->sem){++++}-{4:4}: [ 2529.153913] down_read+0x4a/0x240 [ 2529.154081] amdgpu_userq_destroy+0xd8/0x3a0 [amdgpu] [ 2529.154635] amdgpu_userq_ioctl+0x3e2/0xe30 [amdgpu] [ 2529.155157] drm_ioctl_kernel+0xaf/0x110 [drm] [ 2529.155401] drm_ioctl+0x290/0x510 [drm] [ 2529.155612] amdgpu_drm_ioctl+0x52/0x90 [amdgpu] [ 2529.156068] __x64_sys_ioctl+0xa0/0xf0 [ 2529.156249] x64_sys_call+0x1278/0x21c0 [ 2529.156434] do_syscall_64+0xbe/0x5f0 [ 2529.156611] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2529.156842] -> #1 (&userq_mgr->userq_mutex){+.+.}-{4:4}: [ 2529.157127] __mutex_lock+0xb2/0x11a0 [ 2529.157304] mutex_lock_nested+0x1f/0x30 [ 2529.157492] amdgpu_userq_vm_validate_and_restore_queue+0x710/0x9b0 [amdgpu] [ 2529.158098] amdgpu_userq_restore_worker+0x39/0x290 [amdgpu] [ 2529.158646] process_one_work+0x23e/0x6f -> #0 (reservation_ww_class_mutex){+.+.}-{4:4}: [ 2529.159832] __lock_acquire+0x14c4/0x2210 [ 2529.160021] lock_acquire+0xc6/0x310 [ 2529.160193] __ww_mutex_lock.constprop.0+0xd9/0x1a30 [ 2529.160419] ww_mutex_lock+0x40/0xb0 [ 2529.160590] amdgpu_bo_free_kernel+0x4e/0x130 [amdgpu] [ 2529.161077] amdgpu_mes_rs64mem_fini+0x35/0x60 [amdgpu] [ 2529.161601] mes_v11_0_suspend+0x2d/0x40 [amdgpu] [ 2529.162102] amdgpu_ip_block_suspend+0x2b/0x70 [amdgpu] [ 2529.162609] amdgpu_device_ip_suspend_phase2+0xa4/0x270 [amdgpu] [ 2529.163116] amdgpu_device_pre_asic_reset+0x130/0x1f0 [amdgpu] [ 2529.163617] amdgpu_device_asic_reset+0x55/0x530 [amdgpu] [ 2529.164101] amdgpu_device_gpu_recover+0x1e5/0x410 [amdgpu] [ 2529.164592] amdgpu_userq_mgr_reset_work+0x80/0xa0 [amdgpu] [ 2529.165140] amdgpu_userq_hang_detect_work+0xbb/0x1c0 [amdgpu] [ 2529.165693] process_one_work+0x23e/0x6f0 [ 2529.165884] worker_thread+0x1c4/0x380 [ 2529.166065] kthread+0x10c/0x150 [ 2529.166226] ret_from_fork+0x314/0x390 [ 2529.166408] ret_from_fork_asm+0x1a/0x30 [ 2529.166595] other info that might help us debug this: [ 2529.166917] Chain exists of: reservation_ww_class_mutex --> &userq_mgr->userq_mutex --> &reset_domain->sem Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Michael Chen <michael.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/mes: refactor the amdgpu_mes_alloc/free_proc|gang()Prike Liang
- Unify amdgpu_mes_alloc/free_proc|gang_ctx_index to provide centralized RS64mem bitmap management for both KGD and KFD. - Retrieve the bitmap bit for userq contex index based on a per process granularity. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Michael Chen <michael.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amdgpu/mes12: fix dropped dispatches under queue oversubscriptionJesse Zhang
On gfx12, when more queues are ready than there are HQD slots (oversubscription), MES keeps queues unmapped and maps a queue to an HQD on demand when its doorbell rings; a queue is only refetched once its per-queue work_done is cleared. Historically oversubscription was handled via the aggregated doorbell, but that is a shared level-wide signal: MES cannot tell which queue rang and never clears a queue's work_done, so it relies on the coarse oversubscription timer to rescan. gfx12 therefore drives GFX/compute through the per-queue unmapped-doorbell path instead (the aggregated doorbell now only serves SDMA), which can pinpoint the ringing queue and lets MES stay idle otherwise. But with unmapped-doorbell mode 1 (basic) a ring only sets a coarse level-wide ready flag and does not read the per-queue bitmap or clear the ringing queue's work_done. A queue still marked done from a prior dispatch is skipped and its new work is never fetched: the completion never signals, while queue creation succeeds and no dmesg error is reported. Switch to mode 2 (basic+): MES reads the per-queue CP_UNMAPPED_QUEUE bitmap, identifies which queue rang, and clears its work_done so it is rescheduled promptly. This affects every queue MES schedules on gfx12 (KFD and DRM user queues), which share the one MES instance and this global setting. Tested on gfx1201: concurrent multi-queue dispatch that intermittently stalled under mode 1 now passes on both the KFD and DRM userq paths. v2: update commit message: describe the oversubscription case, why the aggregated doorbell is not used for GFX/compute on gfx12, and why basic+ (not basic) is required. Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Shaoyun Liu <shaoyun.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/ras: move some umc v12 specific functions to ras_umc.cTao Zhou
So we can reuse these functions across different ASICs. In order to simplify code, rename some functions as well. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Promote DC to 3.2.392Taimur Hassan
This version brings along the following updates: - Add KUnit tests for crtc functions. - Add KUnit tests for crtc functions. - Add support for dynamic FFE levels. - Configure all CRC engines in pipe CRC source path. - Enable DCN6 compilation. - Fix ABM over VABC. - Fix CRC engine 1 enable/disable on DCN3.1.2+. - Fix MCM blend LUT issues. - Fix seamless mode switch not triggering for HDR to SDR transition. - Fix wb_info leak and NULL deref in writeback. - Increase fclk change latency on dcn351. - Refactor stream validation. - Resize MST HDCP per-connector arrays to 32. - Unify force_yuv debugfs into force_yuv_pixel_format. - Update VRR info packet to support 12-bit refresh rates. Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Migrate color manager HW and fix MCM blend LUT issuesRafal Ostrowski
Combine two related color manager improvements: 1. Migrate MCM/RMCM, shaper and 3DLUT HW programming to dc_plane_cm - Continue convergence with upstream Color Manager refactor - Migrate MCM/RMCM, shaper and 3DLUT programming for dcn401+ to dc_plane_cm - Unify MCM programming across both legacy and 3DLUT DMA paths - Add 3DLUT DMA broadcast support for multi-pipe planes 2. Reprogram MCM blend LUT on blend_enable falling edge - Fix issue where SDR desktop remained desaturated after video playback - Detect blend_enable falling edge (1->0) in surface update detection - Force MCM LUT reprogramming on blend state change Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Rafal Ostrowski <rafal.ostrowski@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Add FFE level defaultsRelja Vojvodic
[How & Why] Follow-up change to set defaults for HDMI FRL training Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Relja Vojvodic <Relja.Vojvodic@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: switch max FFE level cap based on FRL link rateRelja Vojvodic
[How & Why] - Add support for dynamic FFE levels based on debug config and link rate Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Relja Vojvodic <Relja.Vojvodic@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Update BW bounding box unconditionally for DCN6Alvin Lee
[Description] DCN6 needs to update BW bounding box in hw init in order to propagate the Alt-Ch aperture info into DML. In this case update unconditionally on dcn6 HW init. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Fix more KUnit connector use-after-free bugsAlex Hung
drmm_connector_init() and drmm_encoder_init() register their cleanup (drm_connector_cleanup() / drm_encoder_cleanup()) as DRM-managed actions tied to the drm_device lifetime. When the object memory is owned by KUnit, it is freed before that action runs, so the cleanup touches freed memory. Allocate these objects with drmm_kzalloc() so their lifetime matches the cleanup action. Signed-off-by: Alex Hung <alex.hung@amd.com> Assisted-by: Copilot:Claude-Opus-4.8 Acked-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Configure all CRC engines in pipe CRC source pathWayne Lin
Iterate every CRC engine instance when enabling or disabling the pipe CRC source so DCN31x OTG_CRC1_EN is handled alongside OTG_CRC_EN, matching the legacy shared enable behavior used by DisplayCRC multi-ROI. Reviewed-by: ChiaHsuan (Tom) Chung <chiahsuan.chung@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Fix CRC engine 1 enable/disable on DCN3.1.2+Wayne Lin
[Why] Multi-ROI CRC uses OTG_CRC1_EN for the second engine, but the driver only toggled OTG_CRC_EN and cleared the whole OTG_CRC_CNTL register on disable. [How] Program engine 1 via OTG_CRC1_EN where supported, disable each engine independently by crc_eng_inst, and add the missing mask on relevant DCN ASICs. Reviewed-by: ChiaHsuan (Tom) Chung <chiahsuan.chung@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-06drm/amd/display: Add missing OTG_CRC1_SELECT mask for DCN3.2Wayne Lin
[Why] Configuring CRC engine 1 via optc35_configure_crc() triggers ASSERT(mask != 0) in dc_helper.c when programming OTG_CRC1_SELECT. The DCN3.2 OPTC mask list inherited from dcn32 is missing this field, so ROI[1] CRC cannot be enabled in DisplayCRC mode on DCN3.5/3.51. [How] Add OTG_CRC1_SELECT to OPTC_COMMON_MASK_SH_LIST_DCN3_2, matching the existing dcn10 definition so REG_UPDATE can program CRC engine 1. Reviewed-by: ChiaHsuan (Tom) Chung <chiahsuan.chung@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>