kernel/linux.git/drivers/gpu, branch v6.12.101

gpu: Fix uninitialized buddy for built-in drivers

2026-08-03T09:17:37+00:00

commit cc27314c67516c138ee3829197d1c3b998e29fae upstream. Move buddy to the start of the link order, so its __init runs before any other built-in drivers that may depend on it. Otherwise, a built-in driver that tries to use the buddy allocator will run into a kernel NULL pointer dereference because slab_blocks is uninitialized. Specifically, this fixes drm/xe (as built-in) running into a kernel panic during boot, because it uses buddy during device probe. Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)") Cc: Joel Fernandes Cc: Dave Airlie Cc: intel-xe@lists.freedesktop.org Reviewed-by: Dave Airlie Tested-by: Peter Senna Tschudin Signed-off-by: Koen Koning Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260213152047.179628-1-koen.koning@linux.intel.com Signed-off-by: Greg Kroah-Hartman

gpu/buddy: bail out of try_harder when alignment cannot be honoured

2026-08-03T09:17:33+00:00

[ Upstream commit 56bc6384314fb9ae98975fb2af8b143097ede3dc ] The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew). Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Suggested-by: Christian König Cc: Matthew Auld Cc: Christian König Cc: Timur Kristóf Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld Tested-by: John Olender Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260709131050.1022759-1-Arunpravin.PaneerSelvam@amd.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

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

2026-08-03T09:17:33+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:17:29+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/amd/pm: fix smu13 power limit range calculation

2026-08-03T09:17:28+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:17:28+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:17:28+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 division by zero with invalid uvd dimensions

2026-08-03T09:17:28+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

drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe()

2026-08-03T09:17:28+00:00

commit 613059875958e7b217b250ed14c3b189f9488421 upstream. A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost. Fixes: dbaeef363ea5 ("drm/dp_mst: Add a helper to queue a topology probe") Cc: Imre Deak Cc: Lyude Paul Cc: stable@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jonas Emilsson Signed-off-by: Luca Coelho Link: https://lore.kernel.org/all/20260503034533.1023686-1-jonas.emilsson@gmail.com Acked-by: Imre Deak Link: https://patch.msgid.link/20260622140532.526722-1-luciano.coelho@intel.com Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/vcn4: avoid rereading IB param length

2026-08-03T09:17:28+00:00

commit 3b4082fabc67c9780b06eb959e59dd92fa79c0f0 upstream. Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. Signed-off-by: Boyuan Zhang Reviewed-by: David Rosca Signed-off-by: Alex Deucher (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman