linux/drivers/gpu, branch v6.14

Merge tag 'amd-drm-fixes-6.14-2025-03-20' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes

2025-03-21T01:59:49Z

amd-drm-fixes-6.14-2025-03-20: amdgpu: - Fix video caps limits on several asics - SMU 14.x fixes - GC 12 fixes - eDP fixes - DMUB fix amdkfd: - GC 12 trap handler fix - GC 7/8 queue validation fix radeon: - VCE IB parsing fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20250320210800.1358992-1-alexander.deucher@amd.com

Merge tag 'drm-xe-fixes-2025-03-20' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes

2025-03-21T01:31:40Z

Driver Changes: - Fix for an error if exporting a dma-buf multiple time (Tomasz) Signed-off-by: Dave Airlie From: Thomas Hellstrom Link: https://patchwork.freedesktop.org/patch/msgid/Z9xalLaCWsNbh0P0@fedora

Merge tag 'drm-misc-fixes-2025-03-20' of ssh://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes

2025-03-21T00:41:51Z

A sched fence reference leak fix, two fence fixes for v3d, two overflow fixes for quaic, and a iommu handling fix for host1x. Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20250320-valiant-outstanding-nightingale-e9acae@houat

drm/xe: Fix exporting xe buffers multiple times

2025-03-20T16:59:49Z

The `struct ttm_resource->placement` contains TTM_PL_FLAG_* flags, but it was incorrectly tested for XE_PL_* flags. This caused xe_dma_buf_pin() to always fail when invoked for the second time. Fix this by checking the `mem_type` field instead. Fixes: 7764222d54b7 ("drm/xe: Disallow pinning dma-bufs in VRAM") Cc: Thomas Hellström Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: "Thomas Hellström" Cc: Michal Wajdeczko Cc: Matthew Brost Cc: Matthew Auld Cc: Nirmoy Das Cc: Jani Nikula Cc: intel-xe@lists.freedesktop.org Cc: # v6.8+ Signed-off-by: Tomasz Rusinowicz Signed-off-by: Jacek Lawrynowicz Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20250218100353.2137964-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Thomas Hellström (cherry picked from commit b96dabdba9b95f71ded50a1c094ee244408b2a8e) Signed-off-by: Thomas Hellström

gpu: host1x: Do not assume that a NULL domain means no DMA IOMMU

2025-03-19T18:05:40Z

Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain could have been left as NULL. The NULL domain is specially recognized by host1x_iommu_attach() as meaning it is not the DMA domain and should be replaced with the special shared domain. This happened prior to the below commit because tegra-smmu was using the NULL domain to mean IDENTITY. Now that the domain is properly labled the test in DRM doesn't see NULL. Check for IDENTITY as well to enable the special domains. This is the same issue and basic fix as seen in commit fae6e669cdc5 ("drm/tegra: Do not assume that a NULL domain means no DMA IOMMU"). Fixes: c8cc2655cc6c ("iommu/tegra-smmu: Implement an IDENTITY domain") Reported-by: Diogo Ivo Closes: https://lore.kernel.org/all/c6a6f114-3acd-4d56-a13b-b88978e927dc@tecnico.ulisboa.pt/ Tested-by: Diogo Ivo Signed-off-by: Jason Gunthorpe Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/0-v1-10dcc8ce3869+3a7-host1x_identity_jgg@nvidia.com

drm/amdgpu/pm: Handle SCLK offset correctly in overdrive for smu 14.0.2

2025-03-18T20:34:06Z

Currently, it seems like the code was carried over from RDNA3 because it assumes two possible values to set. RDNA4, instead of having: 0: min SCLK 1: max SCLK only has 0: SCLK offset This change makes it so it only reports current offset value instead of showing possible min/max values and their indices. Moreover, it now only accepts the offset as a value, without the indice index. Additionally, the lower bound was printed as %u by mistake. Old: OD_SCLK_OFFSET: 0: -500Mhz 1: 1000Mhz OD_MCLK: 0: 97Mhz 1: 1259MHz OD_VDDGFX_OFFSET: 0mV OD_RANGE: SCLK_OFFSET: -500Mhz 1000Mhz MCLK: 97Mhz 1500Mhz VDDGFX_OFFSET: -200mv 0mv New: OD_SCLK_OFFSET: 0Mhz OD_MCLK: 0: 97Mhz 1: 1259MHz OD_VDDGFX_OFFSET: 0mV OD_RANGE: SCLK_OFFSET: -500Mhz 1000Mhz MCLK: 97Mhz 1500Mhz VDDGFX_OFFSET: -200mv 0mv Setting this offset: Old: "s 1 " New: "s " Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4036 Reviewed-by: Yang Wang Signed-off-by: Tomasz Pakuła Signed-off-by: Alex Deucher (cherry picked from commit 1cfeb60e6e8837b1de5eb4e17df7cf31f4442144) Cc: stable@vger.kernel.org # 6.12.x

drm/amd/display: Fix incorrect fw_state address in dmub_srv

2025-03-18T20:33:38Z

[WHY] The fw_state in dmub_srv was assigned with wrong address. The address was pointed to the firmware region. [HOW] Fix the firmware state by using DMUB_DEBUG_FW_STATE_OFFSET in dmub_cmd.h. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Lo-an Chen Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit f57b38ac85a01bf03020cc0a9761d63e5c0ce197)

drm/amd/display: Use HW lock mgr for PSR1 when only one eDP

2025-03-18T20:33:11Z

[WHY] DMUB locking is important to make sure that registers aren't accessed while in PSR. Previously it was enabled but caused a deadlock in situations with multiple eDP panels. [HOW] Detect if multiple eDP panels are in use to decide whether to use lock. Refactor the function so that the first check is for PSR-SU and then replay is in use to prevent having to look up number of eDP panels for those configurations. Fixes: f245b400a223 ("Revert "drm/amd/display: Use HW lock mgr for PSR1"") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3965 Reviewed-by: ChiaHsuan Chung Signed-off-by: Mario Limonciello Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ed569e1279a3045d6b974226c814e071fa0193a6) Cc: stable@vger.kernel.org

drm/amd/display: Fix message for support_edp0_on_dp1

2025-03-18T20:32:33Z

[WHY] The info message was wrong when support_edp0_on_dp1 is enabled [HOW] Use correct info message for support_edp0_on_dp1 Fixes: f6d17270d18a ("drm/amd/display: add a quirk to enable eDP0 on DP1") Reviewed-by: Aurabindo Pillai Signed-off-by: Yilin Chen Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 79538e6365c99d7b1c3e560d1ea8d11ef8313465) Cc: stable@vger.kernel.org

drm/amdkfd: Fix user queue validation on Gfx7/8

2025-03-18T20:31:25Z

To workaround queue full h/w issue on Gfx7/8, when application create AQL queue, the ring buffer bo allocate size is queue_size/2 and map queue_size ring buffer to GPU in 2 pieces using 2 attachments, each attachment map size is queue_size/2, with same ring_bo backing memory. For Gfx7/8, user queue buffer validation should use queue_size/2 to verify ring_bo allocation and mapping size. Fixes: 68e599db7a54 ("drm/amdkfd: Validate user queue buffers") Suggested-by: Tomáš Trnka Signed-off-by: Philip Yang Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit e7a477735f1771b9a9346a5fbd09d7ff0641723a) Cc: stable@vger.kernel.org