linux-stable.git/drivers/gpu/drm, branch v6.18.42

drm: drop lib from header search path.

2026-08-03T09:22:09+00:00

commit ee8bfb15d02dddb554ad4bdd6c44297f19556563 upstream.

This was leftover from when I dropped it in
4a9671a03f2b ("gpu: Move DRM buddy allocator one level up (part one)")

Signed-off-by: Dave Airlie 
Cc: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

gpu: Move DRM buddy allocator one level up (part two)

2026-08-03T09:22:09+00:00

[ Upstream commit ba110db8e1bc206c13fd7d985e79b033f53bfdea ]

Move the DRM buddy allocator one level up so that it can be used by GPU
drivers (example, nova-core) that have usecases other than DRM (such as
VFIO vGPU support). Modify the API, structures and Kconfigs to use
"gpu_buddy" terminology. Adapt the drivers and tests to use the new API.

The commit cannot be split due to bisectability, however no functional
change is intended. Verified by running K-UNIT tests and build tested
various configurations.

Signed-off-by: Joel Fernandes 
Reviewed-by: Dave Airlie 
[airlied: I've split this into two so git can find copies easier.
I've also just nuked drm_random library, that stuff needs to be done
elsewhere and only the buddy tests seem to be using it].
Signed-off-by: Dave Airlie 
Stable-dep-of: 56bc6384314f ("gpu/buddy: bail out of try_harder when alignment cannot be honoured")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources

2026-08-03T09:22:08+00:00

commit 76a2db58e95e328007043f54ac3c7336ccbee440 upstream.

dcn32_update_clocks_update_dtb_dto() and its dcn35 counterpart reprogram
the DTB DTO of every timing generator in the context whenever the DTBCLK
reference changes, passing a zeroed pixel rate and never setting
is_hdmi. Both dccg set_dtbclk_dto() implementations treat a zero pixel
rate as a disable request. On dcn32 that branch drives PIPE_DTO_SRC_SEL
to the DP DTO source, so a timing generator actively scanning out an
HDMI stream has its pixel rate source re-muxed out from under the live
raster and the OTG stops on the spot. On dcn35 it clears
DTBCLK_DTO_ENABLE and restores DTBCLK_Pn clock gating, which does the
same to a live 128b/132b stream.

Two displays where only one runs a 128b/132b link hit this reliably.
is_dtbclk_required() holds the DTBCLK reference high while both are
active, and the moment the 128b/132b stream is torn down (compositor
switch, display disable, hot-unplug) the next safe_to_lower pass drops
the reference to the lowest DPM level and the DTO walk freezes the
surviving screen. On Navi31 the DAL mailbox then goes deaf on the
DISPCLK hard-min that follows the walk in dcn32_update_clocks(),
stranding both SMU mailboxes until reboot.

Set is_hdmi for HDMI and DVI signals so the disable path leaves the
pixel rate source selection on the HDMI path, and pass the real pixel
rate for 128b/132b streams so a reference change rescales their DTO
instead of disabling it.

Fixes: 128c1ca0303f ("drm/amd/display: Update DTBCLK for DCN32")
Fixes: 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR")
Signed-off-by: Harry Wentland 
Reviewed-by: Fangzhi Zuo 
Tested-by: Dan Wheeler 
Signed-off-by: Alex Deucher 
[ mschwartz: dcn32 and dcn35 clk_mgr hunks only. The rest is HDMI FRL
  enablement, absent before 7.2, so the FRL conditions and the
  req_audio_dtbclk_khz assignment they guard are dropped and the
  FRL-centric changelog is rewritten. Added the pipe_ctx->stream check
  the new dereferences need. ]
Signed-off-by: Matthew Schwartz 
Signed-off-by: Sasha Levin

drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR

2026-08-03T09:22:07+00:00

commit 4d58d7535e826a3175527b6174502f0db319d7f6 upstream.

Add validation in xe_vm_bind_ioctl() to reject PAT indices
with XE_COH_NONE coherency mode when used with
DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR.

CPU address mirror mappings use system memory that is CPU
cached, which makes them incompatible with COH_NONE PAT
indices. Allowing COH_NONE with CPU cached buffers is a
security risk, as the GPU may bypass CPU caches and read
stale sensitive data from DRAM.

Although CPU_ADDR_MIRROR does not create an immediate
mapping, the backing system memory is still CPU cached.
Apply the same PAT coherency restrictions as
DRM_XE_VM_BIND_OP_MAP_USERPTR.

v2:
- Correct fix tag

v6:
- No change

v7:
- Correct fix tag

v8:
- Rebase

v9:
- Limit the restrictions to iGPU

v10:
- Just add the iGPU logic but keep dGPU logic

Fixes: b43e864af0d4 ("drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR")
Cc:  # v6.15+
Cc: Shuicheng Lin 
Cc: Mathew Alwin 
Cc: Michal Mrozek 
Cc: Matthew Brost 
Cc: Matthew Auld 
Signed-off-by: Jia Yao 
Reviewed-by: Matthew Auld 
Acked-by: Michal Mrozek 
Signed-off-by: Matthew Auld 
Link: https://patch.msgid.link/20260417055917.2027459-3-jia.yao@intel.com
Signed-off-by: Sasha Levin

drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx

2026-08-03T09:22:07+00:00

commit 52f650963d8825e97a0ccdd2b616f8a01d9d3d38 upstream.

For a short moment during alloc/free the userptr BO is not part of his VM,
so bo->vm_bo can be NULL.

Keep a reference to the VM root PD as parent of the userptr BO so that
we can always use that to wait for all submissions of the VM instead of
only the one involving the userptr BO.

Signed-off-by: Christian König 
Fixes: 91250893cbaa ("drm/amdgpu: fix waiting for all submissions for userptrs")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5399
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
(cherry picked from commit 631849ff5d603841e74f19f4a5e30fe1f7d7cf30)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/pm: fix smu13 power limit range calculation

2026-08-03T09:22:07+00:00

commit 220f22e1d66c1cfb63387eb1c4210f92a357c2d9 upstream.

SMU13 reports SocketPowerLimitAc/Dc as the default power limit, but
MsgLimits.Power may carry a different firmware bound for the same PPT
throttler. Using only the socket limit for both min and max can therefore
expose an incorrect power range.

Keep the socket limit as the default, but derive the range from both values:
use the lower value for the min base and the higher value for the max base
before applying OD percentages. Keep the current limit query independent
from the cap calculation.

Fixes: 1eaf26db9590 ("drm/amd/pm: fix smu13 power limit default/cap calculation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5419
Signed-off-by: Yang Wang 
Reviewed-by: Kenneth Feng 
Signed-off-by: Alex Deucher 
(cherry picked from commit f45bbf0f62f266ed8422d84f347d75d5fca846a7)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix aperture mapping leak

2026-08-03T09:22:07+00:00

commit ea772a440d56b285f4d491affac50ecd41f6b402 upstream.

amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver
fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to
always return false, so iounmap(aper_base_kaddr) never runs on normal
driver unload, leaving an orphaned entry in the x86 PAT interval tree.

On connected_to_cpu hardware, the aperture is mapped write-back (WB) via
ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC)
over the same range. The WC vs WB conflict causes:

  ioremap error for 0x..., requested 0x1, got 0x0
  amdgpu: discovery failed: -2

Fix by switching to devres-managed mappings so cleanup is guaranteed
regardless of drm_dev_enter() state:

- connected_to_cpu path: devm_memremap(MEMREMAP_WB). For
  IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut,
  returning __va(offset) from the existing kernel direct map. No new
  ioremap VA or PAT entry is created, so there is nothing to orphan.

- dGPU path: devm_ioremap_wc() registers iounmap() as a devres action,
  guaranteeing cleanup at device_del() time.

Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio()
since the mapping is now devres-owned.

v2: Remove redundant x86_64 guard (Lijo)

Fixes: 9d0af8b4def0 ("drm/amdgpu: pre-map device buffer as cached for A+A config")
Signed-off-by: Asad Kamal 
Reviewed-by: Christian König 
Reviewed-by: Lijo Lazar 
Signed-off-by: Alex Deucher 
(cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: invoke pm_genpd_remove() before freeing genpd

2026-08-03T09:22:07+00:00

commit 28c9b3c5dc35cc790d11e26ca3fc6e068be63998 upstream.

Call pm_genpd_remove() to unregister from global list prior to releasing
acp_genpd memory, and clear the pointer after free.

Signed-off-by: Ce Sun 
Reviewed-by: Tao Zhou 
Signed-off-by: Alex Deucher 
(cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix resource leak on ACP reset timeout

2026-08-03T09:22:07+00:00

commit 020da7c5aac5b86bad8a1571f6eda6b8cff9331d upstream.

When ACP soft reset poll times out, original code returns early without cleanup,
leaking MFD child devices, genpd links and all ACP heap allocations.

Replace direct early return with goto out to force run all cleanup logic
regardless of reset success, preserve timeout error code for caller.

Signed-off-by: Ce Sun 
Reviewed-by: Tao Zhou 
Signed-off-by: Alex Deucher 
(cherry picked from commit 98073e4328d7a8d75d03696ab27f6de70ef1aeda)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix division by zero with invalid uvd dimensions

2026-08-03T09:22:07+00:00

commit 0c01c811be47e6b146552dd59bfedbea8f09b8f4 upstream.

When width or height is less than 16, width_in_mb or height_in_mb
becomes 0, leading to fs_in_mb being 0. This causes a division by
zero when calculating num_dpb_buffer in H264 and H264 Perf decode
paths.

Add validation to reject frames with width < 16 or height < 16
before performing any calculations that depend on these values.

V2: Format change - move up all vaiable definitions.
V3: Use warn_once to avoid spam.

Signed-off-by: Boyuan Zhang 
Reviewed-by: Leo Liu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
(cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman