summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
11 daysMerge tag 'amd-drm-fixes-7.3-2026-10-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-15: amdgpu: - UVD fix - TTM sched entity fixes - SMU 14 fix - Userptr leak fixes - Runpm ref count fix - CRIU fix - UserQ fixes - USB4 fix - SDMA 3 fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20261015221002.1728931-1-alexander.deucher@amd.com
11 daysMerge tag 'drm-xe-fixes-2026-10-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes An OA uAPI fix by zeroing OA buffer at allocation, and other 3 small fixes around eviction and shrinker. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/atDNMV-Aohu6s0gE@intel.com
11 daysMerge tag 'drm-misc-fixes-2026-10-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A revert for the blend mode property patch being applied twice and a patch to reset the device when frozen in virtio, a power state fix for vc4, a Kconfig fix for amdxdna, an error handling, reference counting, and a null pointer dereference fix for rocket, a revert for dma-buf for a commit introducing a dangling reference, a locking fix for exec, and a fix for panthor to handle 10-core GPUs. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/atCZfcTvshZx6mcA@houat
11 daysdrm/amdgpu/sdma3: Work around POLL_REGMEM / FENCE hangTimur Kristóf
SDMA can randomly hang on Polaris 10. Hard to reproduce, but has been occurring sporadically in the Mesa CI on the RADV Polaris 10 job even when Mesa isn't using the SDMA engine. When Mesa actually uses the SDMA on Polaris, the hang becomes more frequent and the reproduction rate goes up significantly in the CI system. We don't know why the hangs occur, but it seems that inserting a single NOP packet before each POLL_REGMEM and FENCE packet works around it. At the moment it's unclear which GPUs are affected, so let's apply this to SDMA 3.x for now. Note that this issue is not documented or acknowledged by AMD. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c343a27ed90823d08de125f7c447d96d056b75d9) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu: keep the eviction fence until the last handle is closedJesse Zhang
amdgpu_gem_object_close() detaches the user queue eviction fence from the BO before it checks bo_va->ref_count, so closing any handle of a BO removes the fence, even when the file still has another handle to the BO and the bo_va with its GPU mappings stays. The BO can then be evicted without suspending the user queues of the file, which keep accessing it through mappings that are only marked for update. Seen on navi31 with a SDMA user queue: a BO opened twice in the same file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second handle is closed (traced attach/detach of the fence): attach bo=ffff8c78a6c84c00 GEM_CLOSE handle=7 detach bo=ffff8c78a6c84c00 while handle 6 and the mapping are still in use. Only detach the fence when the last reference to the bo_va goes away, matching amdgpu_gem_object_open(), which attaches it only when the bo_va is created. With this the fence stays until the file is closed. Fixes: 31f7efcdca4d ("drm/amdgpu: enable eviction fence") Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a) Cc: stable@vger.kernel.org
11 daysdrm/amd/display: Fix NULL sink dereference in USB4 bandwidth functionsSrinivasan Shanmugam
allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT is compiled out in production builds, so a NULL stream->sink causes a NULL pointer dereference. link_set_dpms_off() already guards two earlier accesses to stream->sink with explicit NULL checks, confirming that stream->sink can legitimately be NULL. The subsequent call to deallocate_usb4_bandwidth() had no equivalent guard. Replace the ASSERT() calls with proper NULL checks that return false early, and add a matching stream->sink guard at the call site in link_set_dpms_off() consistent with the surrounding pattern. v2: Keep the existing ASSERT() calls for diagnostics (to report unexpected NULL sink), and add explicit NULL checks that return false before dereferencing stream->sink. Also add a matching stream->sink guard at the deallocation call site in link_set_dpms_off(). (Alex) Fixes: 8fa813b7fd1e ("drm/amd/display: Remove sink usage from DPMS") Reported-by: Dan Carpenter <error27@gmail.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Dominik Kaszewski <dominik.kaszewski@amd.com> Cc: George Zhang <george.zhang@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Roman Li <Roman.Li@amd.com> Cc: Ivan Lipski <ivan.lipski@amd.com> Cc: Dan Wheeler <daniel.wheeler@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 98029a0ce61feb52c563f65349dd9b25f672e355) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu/userq: actually validate userq BOsBenjamin Cheng
This was supposed to loop over the individual evicted list, as the kernel and always_valid evicted lists were already handled in amdgpu_vm_validate. Without this, BOs that were created and evicted before a userq was made would never end up in an eviction fence rearm. Also add the missing ref to the BO before drm_exec locks and refs it. Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4") Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 18decfc9e8cc0fa70b6de9944cc27a37729edfbd) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu: report the BO alignment in bytes in GEM_LIST_HANDLESJesse Zhang
The uapi documents drm_amdgpu_gem_list_handles_entry.alignment as "physical start_addr alignment in bytes", and GEM_OP GET_GEM_CREATE_INFO returns the same value in bytes, but GEM_LIST_HANDLES returns tbo.page_alignment, which is in pages. For a BO created with a 64 KiB alignment on navi31: GET_GEM_CREATE_INFO: alignment=65536 GEM_LIST_HANDLES: alignment=16 so a user such as CRIU that recreates BOs from this list uses the wrong alignment. Convert it to bytes. Fixes: f9db1fc52ceb ("drm/amdgpu: Add ioctl to get all gem handles for a process") Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit aa4493ae949c13e79aba0731394dd7a7e431342b) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu: free the userptr ranges when a CS fails after parser_bosJesse Zhang
amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of the BO list and looks up the user pages. Those ranges are only freed when amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks them under the notifier lock. If amdgpu_cs_patch_jobs(), amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of amdgpu_cs_submit() fails, nothing frees them: neither amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range. Each such CS then leaks the range, its hmm_pfns array (8 bytes per page of the userptr BO) and the BO reference the range holds. An IB on a ring that patches the CS in place (e.g. VCN) with an unmapped va_start fails in amdgpu_cs_patch_ibs() and takes this path. Free the ranges on those error paths. Ranges amdgpu_cs_submit() already dropped are NULL, so freeing them again is a no-op. Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2") 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 c52a9542ed7cfd527feb938bd0accada2ac8d267) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gprJesse Zhang
amdgpu_debugfs_gpr_read() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtime_usage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and copy the buffer with a single copy_to_user() instead of the put_user() loop with its own error path. Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails") 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 31035bbd74f7c3e10c163db875b8e67f8b50ee6a) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctlPerry Yuan
When amdgpu_hmm_range_alloc() fails amdgpu_gem_userptr_ioctl() returns -ENOMEM right away and skips the cleanup every other error path goes through. The GEM object, the bo->parent reference on the VM root and the MMU notifier registration are all left behind. Use release_object here, not user_pages_done, range is still NULL at this point. Fixes: e095b55155ef ("drm/amdgpu: use user provided hmm_range buffer in amdgpu_ttm_tt_get_user_pages") Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bbe739e407a542073ec1a7872b14843566b4919e) Cc: stable@vger.kernel.org
11 daysdrm/amd/pm: add zero fan stop temperature support on smu 14.0.2Kenneth Feng
add zero fan stop temperature support on smu 14.0.2 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5905 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Kevin Wang <kevin.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f990c94a2633d0ead477eb1b174e254a6d292e66) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu: destroy mutex when tearing down ttm buffer entityPerry Yuan
Pair mutex_init() with mutex_destroy() on the GART window allocation failure path and in amdgpu_ttm_buffer_entity_fini(). This is a no-op without CONFIG_DEBUG_MUTEXES, but it keeps lockdep from seeing a live mutex after the entity is freed or re-initialized. Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 03ac40aeed034a0a0d5824ad26f8fbe1f6463698) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu: fix sched entity leak in ttm buffer entity initPerry Yuan
amdgpu_ttm_buffer_entity_init() checks num_gart_windows after drm_sched_entity_init() has already attached the entity to a scheduler run-queue. Returning -EINVAL from that check leaks the entity. Move the ARRAY_SIZE() check before any resources are acquired. Fixes: 2c3725572561 ("drm/amdgpu: statically assign gart windows to ttm entities") Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4000d1cdd1eacd3422267d6c8b4f1c9333b0317e) Cc: stable@vger.kernel.org
11 daysdrm/amdgpu/uvd3.1: Fix checking whether UVD firmware keyselect was already setTimur Kristóf
The PASS_MASK is for a different register not for UVD_FW_START. It was a mistake to check this flag. It should be enough to check that the register is non-zero. Fixes: 889a2cfd889c ("drm/amdgpu/uvd3.1: Don't validate the firmware when already validated") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20261006211607.75407-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9dee462c83259ca769aa1bf82228adee9831685c) Cc: stable@vger.kernel.org
12 daysdrm/panthor: fix immortalis conditionErik Faye-Lund
Exactly 10 cores is also valid for an Immortalis configuration, according to the public documentation: https://support.arm.com/compute-ip/immortalis-g715 So let's report this G715 with 10 cores as Immortalis as well, as long as it supports the ray-intersection feature. This matches what we do for more recent GPUs as well. Fixes: 3b1dc21d6d80 ("drm/panthor: Add support for Mali-Gx15 family of GPUs") Signed-off-by: Erik Faye-Lund <erik.faye-lund@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20261014070902.169273-1-erik.faye-lund@arm.com Signed-off-by: Steven Price <steven.price@arm.com>
12 daysdrm/i915/cx0_phy: Fix ARL-S host bridge detectionDnyaneshwar Bhadane
Fix is_arrowlake_s_by_host_bridge() which always returned false. The while loop always exits with pdev as NULL, so the return condition was always false, causing the wrong tx_misc value to be used. Check the host bridge ID inside the loop body. Once found early exit from the loop release the pci reference "pdev" and return true. v2: - Update commit message (Chaitanya) Bspec:74165,74491 Suggested-by: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> Fixes: 3630a47b700e ("drm/i915/cx0_phy: Update HDMI TMDS C20 algorithm value") Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patch.msgid.link/20260921090226.946472-1-dnyaneshwar.bhadane@intel.com (cherry picked from commit 0507cc5a476af0b6d037b19248bdd20dbe27487d) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
12 daysdrm/i915/dmc: Add sanity check for DMC load addressDibin Moolakadan Subrahmanian
For DMC firmware header version 3, the firmware load address is stored in dmc_info->start_mmioaddr and later used by dmc_load_program(). Unlike the MMIO address table, the firmware load address is not validated. Add a sanity check to ensure it is within the valid range. BSpec: 69671, 68378 Fixes: 3d5928a168a9 ("drm/i915/xelpd: Pipe A DMC plugging") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Reviewed-by: Mitul Golani<mitulkumar.ajitkumar.golani@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260922133535.3180973-6-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit 5e47ee5c76ca9becde8df4ad5202845b7ffcbc4c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
12 daysdrm/i915/dmc: Harden DMC firmware payload parsingDibin Moolakadan Subrahmanian
Validate the conversion of the DMC firmware size from dwords to bytes using check_mul_overflow() before calculating the firmware payload size. Reject zero-length payloads and zero MMIO counts in the DMC firmware header so malformed firmware is caught early. Also set dmc_fw_size only after the payload allocation succeeds. Fixes: eb805623d8b1 ("drm/i915/skl: Add support to load SKL CSR firmware.") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Reviewed-by: Mitul Golani<mitulkumar.ajitkumar.golani@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260922133535.3180973-5-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit efde6601a1f1daedfe3dcc2816c934ddb44e3eef) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
13 daysdrm/exec: don't immediately add prelocked obj to array of locked objsChristian König
When a contention is detected the drm_exec object grabs a reference to the contended object, unlocks all other objects and pre-locks the contended one before anything else. The problem is that it is possible that this pre-locked object was about to be destroyed and drm_exec is now holding the last reference to it. So we never actually see this pre-locked object again to be explicitly locked and so also never reserve a slot for a dma_fence object on it. Should the driver now use drm_exec_for_each_locked_object() to add a new fence to all locked objects we eventually see a warning or even a BUG_ON() to prevent random memory corruption. Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again. If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop. Signed-off-by: Christian König <christian.koenig@amd.com> Reported-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: stable@vger.kernel.org # v6.6+ Link: https://lore.kernel.org/r/20261007124657.9664-1-christian.koenig@amd.com
13 daysdrm/virtio: Reset device before deleting virtqueues on freezeYuho Choi
virtgpu_freeze() waits for the control and cursor queues to drain and then deletes the virtqueues, but nothing tells the device to stop first. del_vqs() frees the vring backing, but does not provide a generic device quiesce operation. In particular, modern virtio-pci keeps enabled queues active until the device is reset, so the device is left DRIVER_OK with its queues pointing at memory that has been freed and may be reused while the guest is suspended. virtio_device_restore() only resets the device later, on resume. Reset the device before deleting the virtqueues, the way virtio_gpu_deinit() already does on removal. Fixes: cad6a879a7fb ("drm/virtio: Freeze and restore hooks to support suspend and resume") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi <oss.patchbox@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260926202040.1313385-1-oss.patchbox@gmail.com
13 daysdrm/xe: Bump LRU for external objects on exec and rebindThomas Hellström
The VM's private BOs get their LRU position refreshed in bulk via ttm_lru_bulk_move_tail() on vm->lru_bulk_move, both after a successful non-LR exec and after the LR preempt-fence rebind worker runs. External objects (BOs potentially shared across VMs) are never added to that per-VM bulk move list, so their LRU position is never refreshed by either path. This makes external objects in active use look more evictable than they are. Add xe_vm_bump_lru(), which, under a single lru_lock critical section, performs the bulk move of the VM's private BOs and bumps each external object locked by the drm_exec transaction. Use it from both the non-LR exec path and the LR rebind worker, replacing the open-coded bulk move. Fixes: d490ecf57790 ("drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helper") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Assisted-by: LLM Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20261012132607.21387-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 324ba30cca180c2e1d02090743dd78ccb15b9e4a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
13 daysdrm/xe/oa: Zero OA buffer at allocationBommu Krishnaiah
ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and may contain data from previously freed pages. Since the OA buffer is mmap'able by userspace, this can expose stale kernel memory contents. Streams opened with DRM_XE_OA_PROPERTY_OA_DISABLED allocate the OA buffer without calling xe_oa_init_oa_buffer(). Zero the buffer at allocation to prevent information disclosure through mmap. The existing zeroing in xe_oa_init_oa_buffer() remains necessary for zero report-id/timestamp detection on enable/re-enable. Fixes: 392bf22238ff ("drm/xe/oa/uapi: OA buffer mmap") Assisted-by: LLM Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Ghimiray, Himal Prasad <himal.prasad.ghimiray@intel.com> Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20261006020314.2711762-1-krishnaiah.bommu@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 126c4c5388f9311a390b9b254a835b0cf0f55331) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
13 daysdrm/xe: skip eviction of a BO with no resourceNiranjana Vishwanathapura
xe_evict_flags() switches on tbo->resource->mem_type to choose an eviction placement. An xe BO can reach eviction with no ttm.resource, e.g. an imported dma-buf BO whose resource was freed during teardown while its attachment is still live: the exporter then invalidates it via xe_dma_buf_move_notify() -> xe_bo_evict(), and the switch dereferences a NULL resource and faults. A BO with no resource has nothing placed or mapped, so there is nothing to evict. Return an empty placement (num_placement = 0), mirroring the handling already used for non-xe scatter-gather BOs just above; ttm_bo_validate() then takes the pipeline-gutting path and returns 0. Without the fix the xe_dma_buf@xe_test_dmabuf_move_notify_no_resource dynamic live selftest will fail with below stack. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:xe_evict_flags+0xf4/0x140 [xe] Call Trace: <TASK> xe_bo_evict+0x40/0xa0 [xe] ? ttm_bo_pipeline_gutting+0x71/0x180 [ttm] xe_test_dmabuf_move_notify_no_resource+0x182/0x440 [xe] xe_dma_buf_kunit+0x387/0x580 [xe] v2: Add Fixes tag and failure info in commit text (Matt Brost) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Assisted-by: GitHub-Copilot:claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20261012215014.1495677-5-niranjana.vishwanathapura@intel.com (cherry picked from commit dbcfaac6331f1fcb0c2fe3ad3e9adb1e5d43ec0c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-12drm/xe: Don't transfer shrinker pages for pinned bos on purgeable state changeThomas Hellström
Pinned bos have their pages removed from the shrinker's shrinkable / purgeable counts on pin, and added back on unpin according to the bo's purgeable state at that time. However, xe_bo_set_purgeable_shrinker() unconditionally transfers pages between the shrinkable and purgeable counts. If the purgeable state of a pinned bo changes, for example by userspace madvising DONTNEED on a VMA of a bo that is also pinned as a scanout buffer, this underflows one count and, after unpin, leaves the other one permanently inflated. Only update the purgeable flag for pinned bos, and leave the page accounting to unpin. Fixes: 536a2ead3a8f ("drm/xe/bo: Add purgeable shrinker state helpers") Cc: Arvind Yadav <arvind.yadav@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v7.1+ Assisted-by: LLM Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20261009070053.7790-1-thomas.hellstrom@linux.intel.com (cherry picked from commit afe6bc012034123fd838328668e609bf57e46bd3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-12drm/vc4: hdmi: Move packet RAM enable to PM runtimeDave Stevenson
Audio can be triggered by the HPD handler and start up before video has been restored, calling vc4_hdmi_write_infoframe() for the audio infoframe. vc4_hdmi_write_infoframe() needs Packet RAM to be on to store the infoframe, however, if the video hasn't been enabled, vc4_hdmi_encoder_post_crtc_enable() hasn't been called and therefore, the Packet RAM can be disabled by the time vc4_hdmi_write_infoframe() executes, causing the following splat: [ 201.570266] ------------[ cut here ]------------ [ 201.570293] Packet RAM has to be on to store the packet. [ 201.570367] WARNING: drivers/gpu/drm/vc4/vc4_hdmi.c:683 at vc4_hdmi_write_infoframe+0x404/0x494 [vc4], CPU#0: wireplumber/1606 [...] [ 201.658650] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 201.758499] Call trace: [ 201.760967] vc4_hdmi_write_infoframe+0x404/0x494 [vc4] (P) [ 201.766607] vc4_hdmi_write_audio_infoframe+0x1c/0x28 [vc4] [ 201.772247] write_infoframe+0xbc/0x140 [drm_display_helper] [ 201.777975] drm_atomic_helper_connector_hdmi_update_audio_infoframe+0x80/0xdc [drm_display_helper] [ 201.787140] vc4_hdmi_audio_prepare+0x4ac/0x570 [vc4] [ 201.792252] drm_connector_hdmi_audio_prepare+0x24/0x30 [drm_display_helper] [ 201.799390] hdmi_codec_prepare+0x100/0x160 [snd_soc_hdmi_codec] [ 201.805471] snd_soc_pcm_dai_prepare+0xd4/0x100 [snd_soc_core] [ 201.811375] __soc_pcm_prepare+0x60/0x12c [snd_soc_core] [ 201.816752] soc_pcm_prepare+0x34/0x58 [snd_soc_core] [ 201.821863] snd_pcm_do_prepare+0x70/0x8c [snd_pcm] [ 201.826798] snd_pcm_action_nonatomic+0xe4/0x174 [snd_pcm] [ 201.832350] snd_pcm_prepare+0xc8/0xd8 [snd_pcm] [ 201.837021] snd_pcm_common_ioctl+0x458/0x614 [snd_pcm] [ 201.842308] snd_pcm_ioctl+0x30/0x48 [snd_pcm] [ 201.846802] __arm64_sys_ioctl+0x88/0xd8 [ 201.850769] invoke_syscall+0x48/0xf4 [ 201.854470] el0_svc_common+0x80/0xd8 [ 201.858171] do_el0_svc+0x1c/0x28 [ 201.861520] el0_svc+0x3c/0xb0 [ 201.864605] el0t_64_sync_handler+0x68/0xdc [ 201.868834] el0t_64_sync+0x198/0x19c [ 201.872536] ---[ end trace 0000000000000000 ]--- Considering that Packet RAM enable is essentially a power management configuration, move its enabling/disabling to the Runtime PM hooks. Note that post_crtc_disable() still stops all infoframes, but keeps Packet RAM enabled, leaving it to be disabled by runtime suspend. Link: https://github.com/raspberrypi/linux/issues/7069 Fixes: b47a72f30768 ("drm/vc4: hdmi: Switch to HDMI connector") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20261002-vc4-hdmi-packet-ram-fix-v1-1-3d73148096c9@igalia.com Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-10-12Revert "drm/virtio: Add pixel blend mode property to cursor plane"Dmitry Osipenko
The cursor blending mode was added twice because the same change was applied by accident from different patches. Revert the second patch. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/dri-devel/ce84d3d2-e78b-4939-aecf-9ef7267bd42a@samsung.com/ Fixes: 6947b78df4d2 ("drm/virtio: Add pixel blend mode property to cursor plane") Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20261007222244.295186-1-dmitry.osipenko@collabora.com
2026-10-11Merge tag 'drm-misc-fixes-2026-10-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A pointer assignment fix for gud, a reference fix and a preallocation size fix for imagination, a suspend fix and an allocation fix when idle for vc4, and a hardware variant fix for nouveau. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <self@mripard.dev> Link: https://patch.msgid.link/asjkbknTHg2t8JGy@houat
2026-10-11Merge tag 'amd-drm-fixes-7.3-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-08: amdgpu: - Fix direct scanout alpha on some DRM_FORMATs - UserQ fixes - Fix tearing flips with PSR - GPU reset vblank fix - Debugfs register interface fix - Fix display mode patching - Expand Mac reserved memory workaround amdkfd: - SDMA doorbell fix - Fix dma-buf reference leak in error path Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20261008174658.2506431-1-alexander.deucher@amd.com
2026-10-11Merge tag 'drm-xe-fixes-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Fixes on: - i2c removal (Fan) - system Controller Maibox header handling (Mallesh) - two bo pin/unpin accounting bugs (Thomas) - not emitting a w/a twice (Tvrtko) - xe_mmio_wait32() to honor delay/sleep maximums (Alan) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/asfEfgbIjs0GJ-RF@intel.com
2026-10-08drm/nouveau: Skip the Turing CE workaround object for non-GR channelsMary Guillemard
This workaround is here for the old Gallium driver and predate async CE and NVDEC. Instead of only skipping it for NVDEC, let's only apply it in case of GR channels. This should make async CE work properly on Turing by stopping the assign of a GRCE. (here CE0) Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20261007-turing-async-ce-fix-v1-1-12ee6ccd1a3c@mary.zone
2026-10-08drm/vc4: Fix binner slot allocation failing on an idle GPUMaíra Canal
A job's binner slots are returned to bin_alloc_used by vc4_complete_exec(), which runs from the job_done workqueue, but the seqno vc4_v3d_get_bin_slot() waits on is incremented earlier, in the function vc4_irq_finish_render_job(). Therefore, a waiter can wake, retry, and still find the pool full because the worker has not run. By then, the job might have left the render_job_list, so no seqno remains to wait on and the allocation fails returning -ENOMEM. This scenario can be reproduced on a Raspberry Pi 3 by using a burst of small jobs (e.g. Piglit's `quick_gl` suite), with userspace seeing a rejected submit for a pool about to become free. Note that the slots are held from validation until the render completes, so the pool can also be exhausted by jobs still queued on bin_job_list, leaving render_job_list empty and nothing to wait on. Release the slots from the FRDONE handler and wait on the pool instead of on one job's seqno. This bounds the wait to the actual resource. Also, by claiming the slot inside the wait condition, another submit is unable to take the slot between the wakeup and the retry. vc4_complete_exec() keeps clearing the slots for jobs that never completed, and now wakes the waiters too. Note that the wait takes a deadline, since the two callers need different ones. The submit path is a user task and can be interrupted, so it waits without one. On the other hand, vc4_overflow_mem_work() runs on a worker and never sees a signal, so it needs a deadline. During a reset, vc4_irq_disable() masks V3D_DRIVER_IRQS before draining the worker, and with those masked nothing can release a slot. This deadlocks: the worker would wait for slots that only the reset can free, while the reset waits in cancel_work_sync() for the worker. Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260930182204.1877361-1-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-10-08drm/vc4: Disable the V3D interrupt across runtime suspendMaíra Canal
vc4_irq_disable() masks the V3D interrupt sources and then calls synchronize_irq() before the V3D is powered down. However, by itself, this is not enough to quiesce the interrupt handler. synchronize_irq() waits for handlers that have already set IRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE. A GIC interrupt chip is able to mark an interrupt active as soon as a CPU acknowledges it, so there these checks cover the whole dispatch path. On RPi 0-3, however, the interrupt controller is ARMCTRL, which has no active state. A CPU that has read the hwirq out of the pending register but has not yet reached handle_level_irq() stays invisible to synchronize_irq(). During a power transition, vc4_irq() may therefore run after the power domain is off, where every V3D register read will return 0xdeadbeef. 0xdeadbeef has FLDONE, FRDONE and OUTOMEM set. This problem doesn't trigger NULL pointer dereference issues only because the functions vc4_irq_finish_bin_job() and vc4_irq_finish_render_job() return early when there is no job pointer, but OUTOMEM is still able to schedule vc4_overflow_mem_work() after vc4_irq_disable() has already cancelled it. Therefore, fix the spurious interrupts by disabling the interrupt line across the PM transition. To preserve the enable/disable balance, move vc4_irq_install() and request the IRQ line disabled before the first runtime resume. Fixes: 9b6f461582e6 ("drm/vc4: v3d: Stop disabling interrupts") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260925191318.541938-1-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-10-09Merge tag 'drm-intel-fixes-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for v7.3-rc7: - Fix a GT park race that could trigger spurious RPM wakelock warnings - Fix execbuffer relocation cleanup to avoid out-of-bounds free Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/49ac4a9f496e1dadbf71740eb0d1f443598b2632@intel.com
2026-10-08drm/imagination: Size page table preallocation by device addressGyeyoung Baek
Commit 0a8224058a58 ("drm/imagination: Fix page count for page table for map() interface") passed the device address to pvr_mmu_op_context_create(), but the preallocation is still sized from device_addr + sgt_offset with an exclusive end. The offset into the object's pages has no place in a device-virtual range, and the exclusive end allocates one table too many when the range ends on a table boundary. Count the tables from device_addr and the inclusive end of the range. The new calculation does not take page table indices into account. This fixes another issue with the previous implementation, where the difference between start and end indices could underflow when a mapping crossed a page table boundary. This would lead to the driver preallocating a huge number of MMU pages, exhausting system memory and triggering an out of memory panic. Fixes: 0a8224058a58 ("drm/imagination: Fix page count for page table for map() interface") Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Gyeyoung Baek <gye976@gmail.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Cc: stable@vger.kernel.org [Alessio: add paragraph to point out OOM bug being fixed, cc stable] Link: https://patch.msgid.link/20261001-pvr-fixes-a-v2-2-f58254e5dfb8@gmail.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-10-08drm/imagination: Fix reference and vm_bo handling in remap()Gyeyoung Baek
When a map overlaps part of an existing mapping, pvr_vm_gpuva_remap() splits the mapping into prev/next parts covering what the request did not take, instead of creating something new. It gets two things wrong. - A GEM reference is taken for each part but it's never needed and never dropped, so it leaks one reference per split (remap-next-in-2m in tests/imagination/pvr_vm_map.c): CRITICAL: 33558528 bytes of shmem still held after close - The parts still belong to the original object being split, but pvr_vm_gpuva_remap() links them to ctx->gpuvm_bo, the new object's vm_bo: prev_va --obj--> BO_A BO_B <--obj-- vm_bo (ctx->gpuvm_bo) \___________link___________/ (mismatch: BO_A != BO_B) drm_gpuva_link() catches the mismatch: WARNING: drivers/gpu/drm/drm_gpuvm.c:2108 at drm_gpuva_link+0x2ec/0x310 drm_WARN_ON(obj != vm_bo->obj) Call trace: drm_gpuva_link pvr_vm_gpuva_remap __drm_gpuvm_sm_map pvr_vm_map pvr_ioctl_vm_map Link them to op->remap.unmap->va->vm_bo instead. The locking of the GPUVA lists of the other objects touched by a split is not addressed here; it is handled by switching the GPUVM to immediate mode. Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Gyeyoung Baek <gye976@gmail.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20261001-pvr-fixes-a-v2-1-f58254e5dfb8@gmail.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-10-07drm/amdgpu: make Mac FB workaround genericAlex Deucher
Rather than adding a case of every chip where this is seen just check if the FB is at 0 and the ssid is apple. This should cover all chips which fall into this case. Tested-by: Ayhan Çiçek <ayhancicek@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c54e4d10507722398dc90cf3c532e50b86cf425a) Cc: stable@vger.kernel.org
2026-10-07drm/amdkfd: fix dma_buf reference leak in get_dmabuf_infoHaojie Li
When kzalloc fails for metadata_buffer in amdgpu_amdkfd_get_dmabuf_info(), the function returns -ENOMEM directly without calling dma_buf_put(), leaking the dma_buf reference obtained earlier via dma_buf_get(). Fix both issues by: - Adding an error check after the first amdgpu_bo_get_metadata() call - Replacing the direct return with r = -ENOMEM and goto out_put to ensure dma_buf_put() is called on all error paths Fixes: f54ce9e8cbd3 ("drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl") Signed-off-by: Haojie Li <lihaojie@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ffa699553332f8caf8688d312279ddcea9e3c141) Cc: stable@vger.kernel.org
2026-10-07drm/amd/display: Don't replace a sink mode that shares the native totalsAdrian Betschart
decide_crtc_timing_for_drm_display_mode() copies the native mode's CRTC timing into the requested mode when clock, htotal and vtotal match. That is meant for the modes amdgpu inserts itself: amdgpu_dm_create_common_mode() duplicates the native mode and changes only hdisplay and vdisplay, so those are sent with the native timing and scaled. A sink can also offer a real mode with the same clock and totals as its native mode. CTA-861 VIC 102 (4096x2160@60) and VIC 97 (3840x2160@60) both use 594 MHz and 4400x2250. With 3840x2160@60 as the preferred mode, a 4096x2160@60 request goes out with the 3840x2160 timing and the framebuffer scaled into it (dst 3840x2025 at y=67), while the AVI InfoFrame still carries VIC 102. A JVC projector then reports 3840x2160 and shows a corrupted right edge. 4096x2160@24, whose totals differ, is sent and displayed correctly. Inserted modes keep the native sync positions; a real mode with its own active width does not. Compare those too, so only inserted modes are patched. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Adrian Betschart <adrian.betschart@cinemaone.ch> Assisted-by: Claude-Code:claude-opus-5-5 Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 22f9a2da101c37f821cd00954f81dc598754f4d5) Cc: stable@vger.kernel.org
2026-10-07drm/amdkfd: align SDMA doorbell base for shader doorbell writesSaleel Kudchadker
On GC 9.4.3, 9.4.4 and 9.5.0, doorbell writes issued from shaders are routed to an SDMA engine at 32-byte (4 doorbell index) granularity. SDMA engine doorbell ranges are 10 indices apart, so the range of every odd engine starts 2 indices into a 4-index block that begins in the previous engine's range. A shader ringing the doorbell of a queue on an odd engine therefore rings the previous engine instead. The intended queue never sees the doorbell, so its work stalls and the application hangs. Align the per-engine doorbell base up to a 4-index boundary on these ASICs. Each engine only uses 4 of its 10 indices, so the aligned base plus the queue offset stays within the engine's range. Even engines are already aligned, so only the doorbell IDs of odd-engine queues change. Only doorbells rung by the device itself are routed this way. Doorbell writes from the host, including the kernel's own SDMA rings, are not affected. The doorbell ID of an SDMA queue is saved in CRIU checkpoints and checked again on restore. A checkpoint taken before this change that contains an SDMA queue on an odd engine will fail to restore with -EINVAL. This is intentional: the restored process still holds the old doorbell address, so accepting the stale ID would bring back the same stall. Tested on MI300X with a shader-rung SDMA doorbell test: queues on odd engines hung before this change and complete with it. v2: use u32 instead of uint32_t for the new locals (checkpatch) v3: name the routing granularity, use dev->node_id, document the layout invariants, describe impact v4: express the granularity in doorbell indices, drop unrelated cleanups, explain the CRIU restore behavior, add test note Fixes: 6df442a03d1a ("drm/amdgpu: add new doorbell assignment table for aqua_vanjaram") Signed-off-by: Saleel Kudchadker <Saleel.Kudchadker@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ee1379e6d7da47bdf7a8d5b89c2d1b28473701fb) Cc: stable@vger.kernel.org
2026-10-07drm/amdgpu: copy debugfs register data outside the GRBM/SRBM locksMikhail Gavrilov
Reading or writing a register through the amdgpu_regs2 debugfs file with GRBM bank selection, which umr does for every banked access (a single "umr -b x x x -r <reg>" is enough, as is the wave dump with "-O halt_waves"), makes lockdep report a circular locking dependency, after which lockdep stays off until reboot: WARNING: possible circular locking dependency detected umr/63306 is trying to acquire lock: ffff8882cf4b8350 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x9b/0x140 but task is already holding lock: ffff8881aec010d0 (&amdgpu_grbm_lock_key){+.+.}-{4:4}, at: amdgpu_debugfs_regs2_op.isra.0+0x20d/0xd00 [amdgpu] ... Chain exists of: &mm->mmap_lock --> &amdgpu_srbm_lock_key --> &amdgpu_grbm_lock_key ... __might_fault+0xc5/0x140 amdgpu_debugfs_regs2_op.isra.0+0x441/0xd00 [amdgpu] full_proxy_write+0x10e/0x1d0 vfs_write+0x1d0/0xf50 ksys_write+0x116/0x250 amdgpu_debugfs_regs2_op() and amdgpu_debugfs_process_reg_op() call get_user()/put_user() for every dword while holding grbm_idx_mutex or srbm_mutex, and pm.mutex if requested, so a fault there takes mmap_lock inside those locks. The lock hierarchy in amdgpu_lockdep.c puts srbm_mutex and grbm_idx_mutex below notifier_lock, which amdgpu_cs_submit() takes with the BO reservations held, and dma_resv_lockdep() orders the reservations inside mmap_lock. So mmap_lock is outside grbm_idx_mutex and srbm_mutex, and these two debugfs paths nest it the other way round. The copies under the locks are as old as the bank selection in both files; commit 1d0f5838b126 ("drm/amdgpu: Add lockdep annotations for lock ordering validation") only made them visible to lockdep. Copy the user buffer in before any of the locks is taken and the result out after all of them are dropped, as amdgpu_debugfs_wave_read(), amdgpu_debugfs_gpr_read() and amdgpu_debugfs_gprwave_read() already do. The buffer is sized by the count passed to read() or write(), so an access larger than PAGE_SIZE is now rejected with -EINVAL; umr reads and writes one register at a time. A fault on the user buffer of a write now fails with -EFAULT before any register is written, instead of after a partial write. Fixes: 566281595037 ("drm/amd/amdgpu: Add bank selection for MMIO debugfs (v3)") Fixes: 37df9560cd3e ("drm/amd/amdgpu: New debugfs interface for MMIO registers (v5)") Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ccf9e35ed6811f2c25ba6368e7dc6481da17159d) Cc: stable@vger.kernel.org
2026-10-07drm/amdgpu: serialize vblank counter reads against GPU resetVitaly Prosyak
The vblank counter callback reads display registers and scanout position without holding reset_domain->sem. During GPU recovery, display commit work can call the callback while reset owns the semaphore for writing. The hardware access then triggers the lockdep_assert_held() in amdgpu_device_skip_hw_access() and sets TAINT_WARN when lockdep is enabled. Try to acquire the reset semaphore for reading before accessing the hardware, and hold it across the counter and scanout-position reads. If reset is already in progress, return DRM's cached software vblank count instead. This avoids blocking behind reset and avoids accessing display hardware while it is being reset. The cached count is less accurate than the hardware count, but is used only when reset prevents a safe hardware read. This addresses the reset-time warning from this vblank path; it does not suppress or fix unrelated lockdep warnings. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Sunpeng Li <sunpeng.li@amd.com> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Sunpeng Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 51a4359f7431a4be5e42803c8bdaf7e0e5be2934) Cc: stable@vger.kernel.org
2026-10-07drm/amd/display: disable self-refresh on tearing flipsLeo Li
[Why & How] Immediate (tearing) flips breaks self refresh state machine assumptions, so disable PSR/Replay for them. Tested-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit acbdd213b37e095f15685f3e3ee6d35defa05616) Cc: stable@vger.kernel.org
2026-10-07drm/amdgpu/userq: return the memdup_user() error for the user MQDJesse Zhang
mes_userq_mqd_create() returns -ENOMEM when copying the user MQD fails, even though memdup_user() returns -EFAULT for a bad pointer or -EINTR when interrupted by a signal. Return PTR_ERR() instead. While at it drop the error messages. Neither case is a driver error and userspace shouldn't be able to spam the log with invalid IOCTL parameters. v2: drop the error messages (Christian) Fixes: 2c695d7c0720 ("drm/amdgpu: enable compute/gfx usermode queue") Fixes: 543b61453774 ("drm/amdgpu: enable SDMA usermode queues") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 49a443fcb829be9fc780f10850652ddea2fe81f0) Cc: stable@vger.kernel.org
2026-10-07drm/amdgpu/userq: only accept doorbell BOs as queue doorbellJesse Zhang
amdgpu_userq_get_doorbell_index() pins any BO passed as doorbell_handle into the doorbell domain. For a regular BO, TTM moves it with ttm_bo_move_null() and its contents are lost. Since an importer on the same device gets the exporter's GEM object, a client can do this to a buffer another client shared with it. Reject BOs that were not created in the doorbell domain. v2: drop the error message, use a local abo variable (Christian) Fixes: f09c1e6077ab ("drm/amdgpu: generate doorbell index for userqueue") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f7497bbc19db4821c62b9d97b31c9086feb2d917) Cc: stable@vger.kernel.org
2026-10-07drm/amd/display: Fix direct scanout alpha on some DRM_FORMATsLeo Li
[Why] DM was declaring it's own list of has_alpha DRM formats to check against for enabling alpha blending, when the format->has_alpha already does that for us. The self-declared list missed some has_alpha formats, causing direct-scanout planes with such formats to appear opaque. [How] Drop the self-declared list, instead use the format->has_alpha field directly. Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9ecdac91ed43d836683d5daa467f4907405420e2) Cc: stable@vger.kernel.org
2026-10-07drm/xe/i2c: cancel the client work on removeFan Wu
xe_i2c_notifier() stores the DesignWare adapter in i2c->adapter and schedules i2c->work when the adapter is registered under the xe I2C platform device, and xe_i2c_client_work() then instantiates the AMC client device on that adapter. xe_i2c_remove() tears down the AMC, unregisters the client devices, the bus notifier and the adapter platform device, but it never drains i2c->work. A work item that is still queued or running when the adapter is unregistered dereferences i2c->adapter in i2c_new_client_device() after platform_device_unregister() has released the adapter. The work item is also embedded in the devm-allocated struct xe_i2c, so a work item still queued after the drm device devm unwind frees that allocation runs its callback on freed memory. The bus notifier is the only thing that schedules this work, and it is unregistered after the client devices. An instance that is still queued when the teardown runs can therefore write i2c->client[XE_I2C_CLIENT_AMC] while the loop is unregistering and clearing the same array, and an AMC client it instantiates late is only cleaned up by the adapter's own child sweep in i2c_del_adapter(). Move bus_unregister_notifier() in front of the client teardown loop and cancel the work right after it, so no new instance can be scheduled and a queued instance is drained before the client array is touched. A running instance still finds a live adapter, since the adapter is unregistered later. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Link: https://lore.kernel.org/intel-xe/20260912085932.101598-1-fanwu01@zju.edu.cn/ Cc: stable@vger.kernel.org Assisted-by: LLM, in-house static analysis tool Co-developed-by: Song Li <songl@zju.edu.cn> Signed-off-by: Song Li <songl@zju.edu.cn> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260928013030.612592-1-fanwu01@zju.edu.cn Link: https://patch.msgid.link/20261006000413.318561-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit a23f27d5ec11c3f418c5e5531eea34ccda2b5b20) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-07Merge tag 'drm-misc-fixes-2026-10-01' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Multiple patches for vc4 that improve memory safety and leaks, one error handling fix and a wrongful cast fix for th1520-dw-hdmi, one input validation fix and the blend mode property addition for vmwgfx, two locking fixes for drm_bridge, an input validation fix for panthor, an error handling fix for drm_dp_helper, EAGAIN handling fix for drm_fb_helper, and a clock reference leakage fix for aspeed. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <self@mripard.dev> Link: https://patch.msgid.link/ar5wE6ElDrxOfNBL@houat
2026-10-06drm/xe/sysctrl: Fix mailbox header handlingMallesh Koujalagi
The mailbox header was defined as __le32, which required cpu_to_le32() and le32_to_cpu() conversions whenever it was write or read. These conversions are unnecessary because the header is always handled as a 32-bit value, not as raw bytes. It is written with xe_mmio_write32() and read with xe_mmio_read32(), which already handle any required byte-order conversion through the underlying writel()/readl() accessors. As a result, the header value is already in CPU byte order when used by the driver. Keeping the extra conversions had no effect on little-endian systems and could cause an incorrect on big-endian systems. So use u32 for the mailbox header and remove the unnecessary endianness conversions. Fixes: 1f95f618182b ("drm/xe/xe_sysctrl: Add System Controller mailbox communication support") Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Tested-by: Anoop Vijay <anoop.c.vijay@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260924060900.146167-18-mallesh.koujalagi@intel.com (cherry picked from commit 5137b391599579371c32f555958d3cf55e19bd88) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-06drm/i915/gt: Unmask interrupts only when ACTIVE is trueKrzysztof Karas
There is a small race window between intel_rps_boost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via asynchronous calls triggered by wakeref drop. This means that rps_work() could be triggered after the GT has been parked, so unmasking RPS PM interrupts would happen without holding PM wakelock. This sequence of events may be observed during live_rc6_ctx_wa() selftest: 1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put() ASYNC1) wakeref_put() callback -> __engine_park() -> intel_gt_pm_put_async() -> intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async() ASYNC2) wakeref_put_async() callback -> __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [clear ACTIVE] WITH INTERRUPTS: -> rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0] WITHOUT INTERRUPTS (TIMER mode): -> rps_stop_timer() -> cancel_work_sync(rps->work) 2) live_rc6_ctx_wa() -> intel_gt_wait_for_idle() -> intel_gt_retire_requests_timeout() -> dma_fence_wait_timeout() -> ops->wait() [i915_fence_wait()] -> i915_request_wait_timeout() -> intel_rps_boost() -> intel_rps_is_active() [check ACTIVE] [OPEN RACE WINDOW] -> queue_work(rps->work) -> retire_requests() -> i915_request_retire() -> intel_rps_dec_waiters() [from 1 to 0] If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW], then: 3) rps_work() executes from the workqueue and may satisfy "(!pm_iir && !client_boost)" test (in TIMER mode rps->pm_iir is zeroed by an earlier rps_work() call or never gets a new value after previous intel_rps_unpark() event), so it jumps to "out" label, bypassing intel_rps_is_active() guard and executes gen6_gt_pm_unmask_irq(); 4) GT is parked and runtime PM wakelock is dropped, so only a raw reference in __gt_park() -> intel_display_power_put_async() remains for 100ms, then the MMIO write in gen6_gt_pm_unmask_irq() detects missing wakelock via assert_rpm_wakelock_held() and emits "RPM wakelock ref not held during HW access" tainting kernel. Commit 3e7abf814193 ("drm/i915: Extract GT render power state management") dropped the "if (rps->interrupts_enabled)" guard that gen6_pm_rps_work() had around this unmask in i915_irq.c. INTEL_RPS_ACTIVE brackets the same window, since it is set in intel_rps_unpark() before rps_enable_interrupts() and rps_start_timer() and cleared in intel_rps_park() before rps_stop_timer() and rps_disable_interrupts(). Skip unmasking when RPS is no longer active (reaching unmask operation is independent of INTERRUPT mode). This does not prevent RPS operation from resuming on the next unpark. In interrupt mode, intel_rps_unpark() calls rps_enable_interrupts(), which enables and unmasks the PM interrupts. In timer mode, it calls rps_start_timer(), restarting periodic engine-busyness evaluation. The timer generates software RPS events and queues rps_work() directly, independently of PM interrupt delivery. Neither mode requires the late worker to unmask interrupts while the GT is parked Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/16562 Cc: stable@vger.kernel.org # v5.5+ Assisted-by: GitHub-Copilot:claude-opus-5 Assisted-by: GitHub-Copilot:gpt-6-astra Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patch.msgid.link/20260910081329.3300417-1-krzysztof.karas@intel.com (cherry picked from commit ca4a6deadad15b91ee083afe445fa6bdbfb68206) Signed-off-by: Jani Nikula <jani.nikula@intel.com>