summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-07-28drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO sizeJose Maria Casanova Crespo
vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB binner BO, but writes the size of the whole BO to BPOS. On every binner out-of-memory event the PTB is therefore authorized to write tile lists across all the other slots (which may hold the tile state, tile alloc and overflow memory of in-flight jobs) and, for any slot but the first, past the end of the binner BO into unrelated CMA memory. Since CMA pages are recycled into page cache and user allocations, this is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU hangs with corrupted control list pointers, userspace heap corruption, a GPU that stays permanently wedged after the first hang, and occasional full system crashes, whenever a job overflows the initial binner slot. The bug dates back to the conversion from a dedicated overflow BO (where writing the full BO size was correct) to the slotted binner BO. Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-1-0d8a5eddc7c9@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-28Merge remote-tracking branch 'drm/drm-next' into drm-rust-nextDanilo Krummrich
Backmerge to pull in commit 21fcb222f0d1 ("drm: Remove DRIVER_GEM_GPUVA feature flag"), which a Tyr patch series depends on. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-28drm/xe/pt: check no-DMA huge-pte cases before DMA segment testHimal Prasad Ghimiray
On a non-range clear, curs.size is never set, so the segment test (next - va_curs_start > curs->size) returns false for every level > 0 before the clear_pt short-circuit is reached. The clear then descends to level 0 instead of forming a huge zero-leaf, wasting page tables and risking -ENOMEM on unbind. Move the null-VMA, purged-BO and clear_pt short-circuits above the curs->size test. The bind path always sets curs.size, so it is unaffected. v2 - Also set curs.size on the clear path so the cursor stays meaningful during the walk. clear_pt is only reached with range == NULL, so assert that invariant. (Matthew Brost) Cc: Matthew Brost <matthew.brost@intel.com> Fixes: 5b658b7e89c3 ("drm/xe: Clear scratch page on vm_bind") Reported-by: Sashiko <sashiko-bot@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260728055916.593707-2-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2026-07-28gpu: nova-core: fix packed registry table sizeAlexandre Courbot
`PACKED_REGISTRY_TABLE::size` describes the entire table, including its fixed-size header. `SetRegistry` currently initializes it with only the variable payload length, omitting the 8 bytes header. Fix this by using `CommandToGsp::size` to obtain the actual command size, including its header. Fixes: 19b0a6e7c2be ("gpu: nova-core: gsp: Add SetRegistry command") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/r/20260722075253.B6DDB1F00A3D@smtp.kernel.org Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260723-nova-registry-size-fix-v1-1-8f471ba00ab4@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-27Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixesMaarten Lankhorst
Backmerge v6.2-rc5 to pick up merged fixes.
2026-07-27drm/nouveau/kms/nv50-: Unconditionally create blend_mode prop for wndwsLyude Paul
Since the commit mentioned down below, it looks like we've been triggering this WARN_ON(): [ 31.477009] ------------[ cut here ]------------ [ 31.477012] [PLANE:66:curs-0] pixel format with alpha exposed but blend mode not setup [ 31.477014] WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate+0x38c/0x4c0, CPU#1: modprobe/1264 [ 31.477125] CPU: 1 UID: 0 PID: 1264 Comm: modprobe Not tainted 7.2.0-rc2Lyude-Test+ #1 PREEMPT(lazy) [ 31.477129] Hardware name: Micro-Star International Co., Ltd. MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.M4 05/10/2023 [ 31.477132] RIP: 0010:drm_mode_config_validate+0x394/0x4c0 [ 31.477136] Code: 41 3b 9e 80 00 00 00 73 bd 49 8b 46 78 8b 3c 98 e8 c1 3d ff ff 80 78 14 00 74 e1 48 8d 3d 64 e6 e7 01 49 8b 56 18 41 8b 76 50 <67> 48 0f b9 3a 49 8b 46 08 4c 8d 70 f8 49 39 c5 75 97 8b 95 b8 02 [ 31.477139] RSP: 0018:ffffd48e053bb7f8 EFLAGS: 00010202 [ 31.477143] RAX: ffffffffaf1da9c0 RBX: 0000000000000000 RCX: 0000000000000034 [ 31.477145] RDX: ffff8cd883c1feb0 RSI: 0000000000000042 RDI: ffffffffb069f840 [ 31.477148] RBP: ffff8cd88ea3d800 R08: 0000000034325241 R09: ffff8cd88ea3dac0 [ 31.477150] R10: fffffaf5c4043600 R11: ffff8cd88004f600 R12: 0000000000000001 [ 31.477152] R13: ffff8cd88ea3da90 R14: ffff8cd88b9ec038 R15: ffff8cd88ea3dab0 [ 31.477154] FS: 00007fb934898780(0000) GS:ffff8cd9f3a6a000(0000) knlGS:0000000000000000 [ 31.477157] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 31.477160] CR2: 0000555efff79520 CR3: 0000000122cd5000 CR4: 00000000003506f0 [ 31.477162] Call Trace: [ 31.477165] <TASK> [ 31.477168] ? nouveau_hwmon_init+0x2d6/0x330 [nouveau] [ 31.477346] drm_dev_register+0x19d/0x270 [ 31.477352] nouveau_drm_device_init+0x17a/0x230 [nouveau] [ 31.477523] nouveau_drm_probe+0x13d/0x1e0 [nouveau] [ 31.477690] local_pci_probe+0x3e/0x90 [ 31.477697] pci_call_probe+0x59/0x190 [ 31.477702] ? srso_return_thunk+0x5/0x5f [ 31.477706] ? pci_match_device+0x15a/0x180 [ 31.477710] ? pci_assign_irq+0x2d/0x160 [ 31.477714] pci_device_probe+0x95/0x160 [ 31.477719] call_driver_probe+0x26/0x100 [ 31.477724] ? driver_sysfs_add+0x59/0xd0 [ 31.477738] really_probe+0xcc/0x2c0 [ 31.477743] ? srso_return_thunk+0x5/0x5f [ 31.477749] __driver_probe_device+0x85/0x170 [ 31.477754] driver_probe_device+0x1f/0x90 [ 31.477760] ? __pfx___driver_attach+0x10/0x10 [ 31.477766] __driver_attach+0xcb/0x210 [ 31.477772] bus_for_each_dev+0x85/0xd0 [ 31.477779] bus_add_driver+0x13e/0x220 [ 31.477786] ? __pfx_init_module+0x10/0x10 [nouveau] [ 31.477979] driver_register+0x75/0xe0 [ 31.477984] ? srso_return_thunk+0x5/0x5f [ 31.477990] nouveau_drm_init+0x8b/0xff0 [nouveau] [ 31.478192] do_one_initcall+0x5d/0x300 [ 31.478204] do_init_module+0x86/0x290 [ 31.478212] init_module_from_file+0xd8/0x140 [ 31.478223] idempotent_init_module+0x114/0x310 [ 31.478233] __x64_sys_finit_module+0x71/0xe0 [ 31.478238] do_syscall_64+0xe2/0x630 [ 31.478252] ? srso_return_thunk+0x5/0x5f [ 31.478257] ? vfs_read+0x165/0x390 [ 31.478267] ? srso_return_thunk+0x5/0x5f [ 31.478271] ? srso_return_thunk+0x5/0x5f [ 31.478276] ? switch_fpu_return+0x52/0xe0 [ 31.478282] ? srso_return_thunk+0x5/0x5f [ 31.478286] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90 [ 31.478292] ? srso_return_thunk+0x5/0x5f [ 31.478296] ? do_syscall_64+0x11f/0x630 [ 31.478301] ? srso_return_thunk+0x5/0x5f [ 31.478305] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90 [ 31.478310] ? srso_return_thunk+0x5/0x5f [ 31.478314] ? do_syscall_64+0x11f/0x630 [ 31.478320] ? srso_return_thunk+0x5/0x5f [ 31.478324] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90 [ 31.478329] ? srso_return_thunk+0x5/0x5f [ 31.478334] ? srso_return_thunk+0x5/0x5f [ 31.478338] ? do_syscall_64+0x99/0x630 [ 31.478343] ? exc_page_fault+0x82/0x1c0 [ 31.478350] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 31.478355] RIP: 0033:0x7fb93410030d [ 31.478372] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 5a 0f 00 f7 d8 64 89 01 48 [ 31.478375] RSP: 002b:00007ffc587ce738 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 31.478381] RAX: ffffffffffffffda RBX: 0000562f5fb3da60 RCX: 00007fb93410030d [ 31.478385] RDX: 0000000000000000 RSI: 0000562f5fb40590 RDI: 000000000000000d [ 31.478388] RBP: 00007ffc587ce7d0 R08: 0000000000000000 R09: 0000000000000000 [ 31.478391] R10: 0000000000000000 R11: 0000000000000246 R12: 0000562f5fb40590 [ 31.478394] R13: 0000000000040000 R14: 0000562f5fb3db80 R15: 0000000000000009 [ 31.478404] </TASK> [ 31.478407] ---[ end trace 0000000000000000 ]--- Fix it by making sure we unconditionally call drm_plane_create_blend_mode_property for all types of wndws, including those (such as cursors) without a blend_set function. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260720215058.398210-4-lyude@redhat.com
2026-07-27drm/nouveau/kms/nv50-: Introduce nv50_wndw_default_state()Lyude Paul
While we don't currently read-in the hardware state of planes, now that we're about to start exposing blend properties for all planes that can support alpha channels: We need to make sure that the initial atomic state for a wndw always starts off with a supported value in pixel_blend_mode. The easiest way to do this is to introduce a nv50_wndw_default_state() function, and use it in nv50_display_read_hw_state() - and use that function to enforce a valid value for pixel_blend_mode during driver startup. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Link: https://patch.msgid.link/20260720215058.398210-3-lyude@redhat.com
2026-07-27drm/nouveau/kms/nv50-: Add .blend_modes to nv50_wndw_funcLyude Paul
At the moment, we currently (incorrectly) only expose a blend property on the plane if we have a nv50_wndw_func->blend_set function for the given wndw type. But we need to expose a blend property for all types of planes that can display color formats with an alpha channel. Prepare for doing this by introducing a way of looking up the supported blend modes for a type of wndw by introducing .blend_modes, which describes all possible blending modes nouveau currently supports for a type of wndw. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Link: https://patch.msgid.link/20260720215058.398210-2-lyude@redhat.com
2026-07-27drm/vmwgfx: validate external BO copy bounds for both stride pathsZack Rusin
vmw_external_bo_copy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps: - The equal-stride memcpy() bound was clamped after subtracting the offsets from dst_size and src_size; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dst_stride * height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) * stride + width_in_bytes, with only a WARN_ON(dst_stride < width_in_bytes), and could likewise step past the end of either mapping. The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path. Validate the exact row-copy endpoint against each BO's size up front using check_mul_overflow() and check_add_overflow(). Use the bulk memcpy() path only when width_in_bytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < width_in_bytes, both of which the row-by-row path cannot represent safely. Fixes: 50f119925091 ("drm/vmwgfx: Fix prime with external buffers") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-13-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: use check_add_overflow for shader size+offset boundZack Rusin
vmw_shader_define() validates the user-supplied shader window against its backing buffer with (u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-12-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: skip hash_del_rcu when validation context has no hash tableZack Rusin
vmw_validation_add_resource() calls hash_add_rcu() only when ctx->sw_context is non-NULL, but the doomed-resource error path calls hash_del_rcu() unconditionally. The validation contexts declared with DECLARE_VAL_CONTEXT(_, NULL, 0) in vmwgfx_kms.c, vmwgfx_scrn.c, vmwgfx_stdu.c and vmwgfx_execbuf.c consequently reach a delete for a node that was never added to any hash chain. That is harmless today, but only incidentally so. hash_del_rcu() is hlist_del_init_rcu(), which is guarded by hlist_unhashed(), and vmw_validation_mem_alloc() hands out memory from __GFP_ZERO pages that are never recycled within a context's lifetime, so node->hash.head.pprev is always NULL and the delete does nothing. Neither property is apparent at the call site, and the asymmetry with the add side invites a real bug the first time either one changes. Mirror the condition from the add side so the node is only unlinked when it was actually linked. No functional change. Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-11-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: enforce cursor size limits for MOB cursorsZack Rusin
vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB. Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-10-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failureZack Rusin
Two paths through vmw_vkms_init() can leave vmw->crc_workq NULL while still leaving the rest of the driver in a state that calls vmw_vkms_cleanup() at module unload: 1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or returning an oversized buffer -- the common case on hosts without a VBLANK guestinfo entry -- early-returned before the workqueue allocation. 2. alloc_ordered_workqueue() returning NULL on memory pressure. vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which dereferences wq->name and panics. Fix the first case by removing the early return: vmw->vkms_enabled is already false on the rpci-failure path so no work will ever be queued, and allocating the workqueue unconditionally keeps the control flow simple. Fix the second case by guarding the cleanup with a NULL check, since alloc_ordered_workqueue() can still fail under low memory. Fixes: 7b0062036c3b ("drm/vmwgfx: Implement virtual crc generation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-9-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: bound DMA command body size against suffix pointerZack Rusin
vmw_cmd_dma() locates the DMA suffix at (unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit. Fixes: 4e4ddd477743 ("drm/vmwgfx: Fix queries if no dma buffer thrashing is occuring.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-8-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: validate DRAW_PRIMITIVES header size before divisionZack Rusin
vmw_cmd_draw() computes maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front. Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-7-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: drop dma_buf reference on foreign-fd prime importZack Rusin
ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped. Fixes: 65981f7681ab ("drm/ttm: Add a minimal prime implementation for ttm base objects") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-6-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: take fman->lock around fence list mutation in fifo_downZack Rusin
vmw_fence_fifo_down() drops fman->lock to wait on a fence and, on timeout, mutates fman->fence_list via list_del_init() and signals the fence without re-acquiring the lock. __vmw_fences_update() walks and removes entries from the same list under fman->lock from any other waiter, the fence-IRQ thread, or vmw_fences_update(), so the unlocked list_del_init() can corrupt the list head. Re-take fman->lock before manipulating fence->head and use dma_fence_signal_locked(). Wrap the locked signalling in dma_fence_begin_signalling() / dma_fence_end_signalling() so the lockdep annotation that dma_fence_signal() previously provided is preserved (the same pattern as __vmw_fences_update()). dma_fence_put() is moved outside the lock to avoid a recursive acquire from vmw_fence_obj_destroy(), which also takes fman->lock. Fixes: ae2a104058e2 ("vmwgfx: Implement fence objects") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-5-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: clamp dirty-page range with min, not maxZack Rusin
vmw_bo_dirty_transfer_to_res() and vmw_bo_dirty_clear() compute the intersection of a resource's page range with the BO's tracked dirty range, but clamp res_end against dirty->end with max() instead of min(). When dirty->end exceeds the resource end, the loop walks past the resource's pages, calls vmw_resource_dirty_update() for ranges owned by other resources sharing the same backing MOB and clears their pending dirty bits via bitmap_clear(). The result is silent loss of writeback for unrelated resources whenever two resources share a MOB. Use min() in both functions so the loop is bounded to the intersection of the resource and dirty ranges. Fixes: b7468b15d271 ("drm/vmwgfx: Implement an infrastructure for write-coherent resources") Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-4-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: reject DX_BIND_QUERY without a DX contextZack Rusin
vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published. Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-3-zack.rusin@broadcom.com
2026-07-27drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as sizeZack Rusin
Two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res->guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://patch.msgid.link/20260505222728.519626-2-zack.rusin@broadcom.com
2026-07-27drm/bridge: Use named initializers for arrays of i2c_device_dataUwe Kleine-König (The Capable Hub)
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. The mentioned robustness is relevant for a planned change to struct i2c_device_id that replaces .driver_data by an anonymous union. While touching all these arrays, unify usage of whitespace in the list terminator and drop trailing commas there. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Acked-by: Douglas Anderson <dianders@chromium.org> # ti-sn65dsi86.c Link: https://patch.msgid.link/9fa3a8e372b7211c06ec885617051f5006227e3a.1784545092.git.u.kleine-koenig@baylibre.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-27drm/bridge: display-connector: Fix I2C adapter resource leakLaurent Pinchart
If the probe function returns an error after getting the I2C adapter for DDC, the reference to the adapter is never released. Fix it by releasing it in the bridge .destroy() handler. There is no need to test the ddc pointer with !IS_ERR(), as of_get_i2c_adapter_by_node() returns NULL on error. Fixes: 2e2bf3a5584d ("drm/bridge: display-connector: add DP support") Cc: stable@vger.kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Johan Hovold <johan@kernel.org> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260717184836.2017386-1-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-27drm/bridge: dw-hdmi: fix i2c adapter leak on probe failureJohan Hovold
Make sure to drop the i2c adapter device and module references before returning when detecting a malformed devicetree during probe. Fixes: 80e2f97968b5 ("drm: bridge: dw-hdmi: Switch to regmap for register access") Cc: stable@vger.kernel.org # 4.12 Cc: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260717090819.1630965-1-johan@kernel.org Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-27drm/bridge: lontium-lt8912b: make read-only const array supply_names staticColin Ian King
Don't populate the read-only const array supply_names on the stack at run time, instead make it static Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20260714190400.194605-1-colin.i.king@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-27drm/bridge: tc358764: use devm for bridge registration and DSI attachOsama Abdelkader
Replace manual drm_bridge_remove()/mipi_dsi_detach() in remove with devm_drm_bridge_add() and devm_mipi_dsi_attach() in probe. Also check the return value from bridge registration. Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260521215228.188615-2-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-27drm/bridge: tc358762: use devm for bridge registration and DSI attachOsama Abdelkader
Replace manual drm_bridge_remove()/mipi_dsi_detach() in remove with devm_drm_bridge_add() and devm_mipi_dsi_attach() in probe. Also check the return value from bridge registration. Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260521215228.188615-1-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-27drm/xe/bo: optimise TT population for DONTNEED BOsMatthew Auld
When a VRAM buffer object is marked as DONTNEED, like in Mesa, the driver skips migrating its contents to system memory and instead purges the backing store during eviction (via xe_ttm_bo_purge). However, xe_evict_flags() still returns tt_placement (XE_PL_TT) for VRAM BOs even if they were marked DONTNEED. This causes ttm_bo_handle_move_mem() to always call ttm_bo_populate() to allocate destination system pages, only for those pages to be immediately freed right after when xe_bo_move() calls xe_ttm_bo_purge(). Fix this by changing xe_evict_flags() to return sys_placement (XE_PL_SYSTEM) for DONTNEED BOs. This causes TTM to skip the population step while still ensuring that TTM calls xe_bo_move(), so xe_ttm_bo_purge() still triggers. v2 (Thomas): - Add a comment to highlight why sys_placement over purge_placement. Assisted-by: Copilot:gemini-3.1-pro-preview Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260723161542.1220276-2-matthew.auld@intel.com
2026-07-27drm/panel: novatek-nt36536: Fix panel double-remove on attach failureDavid Carlier
The DSI attach error path calls drm_panel_remove() by hand even though the panel was registered with devm_drm_panel_add(), which already arranges for drm_panel_remove() to run on driver detach. When mipi_dsi_attach() fails the panel is therefore removed twice: once directly and once again while devres unwinds. drm_panel_add() takes a reference and drm_panel_remove() drops one, so the extra removal releases the last reference early and frees the panel container. The put registered by devm_drm_panel_alloc() then operates on freed memory, resulting in a use-after-free and a reference-count underflow when a DSI host rejects the requested configuration during probe. Drop the manual drm_panel_remove() and let the managed cleanup handle it, matching the other dual-DSI panel drivers. Fixes: 75a5dbd1f4f7 ("drm/panel: Add Novatek NT36536 panel driver") Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260724041746.12887-1-devnexen@gmail.com
2026-07-27drm/panel: simple: Add Ampire AM-800480N3TZQW-00HPaul Louvel
Add support for the Ampire AM-800480N3TZQW-00H 5" WVGA TFT LCD panel. Signed-off-by: Paul Louvel <paul.louvel@bootlin.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260723-support-am-800480n3tzqw-00h-v1-2-6a4ae0575a19@bootlin.com
2026-07-27drm/panel: st7703: Add AYANEO Pocket DS Lower Panel SupportAlexandre Hamamdjian
Add support for the lower (secondary) panel of the AYANEO Pocket DS, a dual-screen QCS8550 (Snapdragon 8 Gen 2) handheld. It is a 5.0" 1024x768 4:3 IPS LCD driven by a Sitronix ST7703 DDIC: every command in the vendor init sequence maps to an ST7703 manufacturer command (SETEXTC, SETMIPI, SETRGBIF, SETSCR, SETPOWER, SETGAMMA, SETGIP1/2), and the SETMIPI and SETRGBIF payloads are near-identical to the already-supported Powkiddy RGB10MAX3. The panel is mounted in portrait (768x1024) and rotated 270 degrees in the device, expressed through the panel rotation property. The SETEXTC unlock password ends in 0x87 rather than the canonical 0x83; this is the value shipped by the vendor firmware and is kept verbatim. Init sequence extracted from the AYANEO Pocket DS BSP kernel, via the ROCKNIX SM8550 port. Signed-off-by: Alexandre Hamamdjian <azkali.limited@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260723-b4-st7703-pocketds-lower-v1-2-e3db246589f4@gmail.com
2026-07-27drm: panel: jd9365da: Add DCLTek 300250 9.35in displayMarc-Olivier Champagne
The DCLTek dt300250 is a LCD panel using the jd9365da controller. Add the panel to the driver. Suggested-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Marc-Olivier Champagne <marc-olivier.champagne@savoirfairelinux.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260722173840.3576444-5-marc-olivier.champagne@savoirfairelinux.com
2026-07-27drm: panel: jd9365da: Enable LPM modeMarc-Olivier Champagne
The JD9365DA-H3 uses DSI LPM for command transmissions, make sure this is configured correctly in the DSI mode flags. Suggested-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Marc-Olivier Champagne <marc-olivier.champagne@savoirfairelinux.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260722173840.3576444-2-marc-olivier.champagne@savoirfairelinux.com
2026-07-27drm/nouveau: allow allocating NVDEC channels via abi16Dave Airlie
Add NOUVEAU_FIFO_ENGINE_NVDEC to the abi16 uAPI and accept it in channel allocation, mapping it to the NVDEC engine runlist. Skip the Turing copy-engine workaround object for NVDEC channels: the copy engines are not part of the NVDEC runlist, so the workaround object cannot be instantiated on such channels (and is not needed there). This is required for NVK to implement Vulkan Video H.264 decode on top of the NVDEC engine: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31867 Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260725035912.1016464-1-daniel.almeida@collabora.com
2026-07-24drm/xe/eustall: Add WA 14027054324 support for graphics IP 35.11Harish Chegondi
WA 14027054324 is implemented in the firmware and is applied before EU stall sampling and reverted after EU stall sampling. The driver needs to notify the firmware whenever EU stall sampling is being enabled/disabled so that the firmware takes the necessary action. The driver uses a scratch pad register to communicate with the firmware. Before enabling EU stall sampling, write 0x20 to the SWF scratch pad register to request the firmware to apply the workaround. The firmware applies the workaround and sets the scratch pad register to 0x60 as an ACK. Before disabling EU stall sampling, write 0x40 to the SWF scratch pad register to request the firmware to revert the workaround. The firmware reverts the workaround and sets the scratch pad register to 0 as an ACK. The firmware is expected to take about 1 ms to apply/revert the workaround. 10 ms timeout is used in the driver while waiting for an ack from the firmware to have adequate grace period. Bspec update for the SWF scratch pad register is still pending, but has been confirmed offline with the firmware team. Bspec: 53188 Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/16b6b972691943daddebad6e7b93b9d73add5249.1784745545.git.harish.chegondi@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-07-25Merge tag 'drm-misc-next-2026-07-24' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.3: UAPI Changes: cgroup: - dmem: accept one region per limit drm: - send per-connector hotplug events Core Changes: buddy: - tests: test buffer clearence on resume panel: - implement ref counting for struct drm_panel throughout the DRM tree Driver Changes: etnaviv: - force flush on power register ops gma: - replace simple-kms helpers with regular atomic helpers - clean up host1x: - support Tegra264 plus DT bindings - fix minor issues throughout driver hypervdrm: - clean up PCI-device binding imagination: - mark BXM-4-64 MC1 (36.52.104.182) as supported - clean up ivpu: - clean up nouveau: - remove redundant call to pm_runtime_mark_last_busy() panel: - support Novatek NT36536 plus DT bindings - sofef00: fix backlight updates - osd101t2587: use mipi_dsi_*_multi interface - panel-edp: adjust timing for AUO displays - panel-lvds: support Opto Logic SCX1001511GGC49 - panel-simple: support Kyocera tcg070wvlq panfrost: - clean up solomon: - clean up variables tve200: - add OF module alias for autoloading v3d: - fix job BO handling vc4: - ref i2c-adapter module Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260724082204.GA18774@linux.fritz.box
2026-07-24drm/panthor: reject firmware sections with oversized dataOsama Abdelkader
In panthor_fw_load_section_entry(), the data size to copy is calculated without validating it against the allocated section_size: section->data.size = hdr.data.end - hdr.data.start; If a crafted firmware sets data.size larger than the allocated memory, this could cause a heap buffer overflow in panthor_fw_init_section_mem() memcpy(section->mem->kmap, section->data.buf, section->data.size); Additionally, if the section->data.size exceeds the BO size, could this memset underflow the size calculation, leading to a massive out-of-bounds zeroing of kernel memory? memset(section->mem->kmap + section->data.size, 0, panthor_kernel_bo_size(section->mem) - section->data.size); Reject section entries whose initial data is larger than the section size. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260716143939.21903-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price <steven.price@arm.com>
2026-07-24drm/panthor: return PTR_ERR() from devm_drm_dev_alloc()Osama Abdelkader
devm_drm_dev_alloc() returns an ERR_PTR() on failure, but panthor_probe() always converts that failure to -ENOMEM. Preserve the actual error code returned by the DRM core instead. Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block") Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260716140337.10679-1-osama.abdelkader@gmail.com
2026-07-24drm/panel-edp: take i2c adapter module referenceJohan Hovold
The i2c subsystem currently blocks during adapter deregistration whenever there are consumers holding a reference. Switch to using of_get_i2c_adapter_by_node() which also takes a reference to the adapter module so that an attempt to unload the module while in use fails gracefully instead of blocking uninterruptibly. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260717143119.1815106-3-johan@kernel.org
2026-07-24drm/panel-edp: fix i2c adapter leak on probe failureJohan Hovold
Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus. Fixes: cc5a3fc041f0 ("drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC") Cc: stable@vger.kernel.org # 5.15 Reported-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/CAD=FV=VZPhzHU+Pet2m3L+Pqc7mOPfZC-f5p0OuNL79wNZPxRg@mail.gmail.com Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260717143119.1815106-2-johan@kernel.org
2026-07-24drm/amd/display: Fix missing DCE check in dm_gpureset_toggle_interrupts()Leo Li
This line was lost when cping from amd-staging-drm-next to drm-fixes. So add it back. Cc: stable@vger.kernel.org Fixes: 8382cd234981 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Reported-by: Lu Yao <yaolu@kylinos.cn> Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260723134450.13838-1-sunpeng.li@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2026-07-24drm/amd/display: Fix flip-done timeouts on mode1 resetLeo Li
The vblank on/off callbacks mixed use of amdgpu_irq_get/put() and amdgpu_dm_crtc_set_vupdate_irq() to enable and disable IRQs. With get/put, base driver will callback into DC to disable IRQs when refcount == 0. With set_vupdate_irq(), DC is called directly to disable IRQs, bypassing base driver's refcount tracking. During gpu reset, base driver can restore IRQs via amdgpu_irq_gpu_reset_resume_helper() > amdgpu_irq_update(). So if get/put() is not used (i.e. refcount == 0), then vupdate_irq will be disabled. This is problematic if DRM requests vblank on before amdgpu_irq_update() is called: drm_vblank_on() > set_vupdate_irq() enables vupdate_irq, but the refcount is still 0. gpu_reset_resume_helper() > irq_update() then immediately disables it, thus leading to flip done timeouts. This is made worse on DCN since VUPDATE_NO_LOCK is the only IRQ enabled. Prior to 8382cd234981, a combination of GRPH_FLIP and VSTARTUP IRQs were used, and they used get/put(). This explains why 8382cd234981 exposed this issue. Fix by using get/put() instead of set_vupdate_irq(). DCE is unchanged, since it relies on unbalanced enable/disable calls based on VRR status, and hence requires direct set_vupdate_irq(). Plus, it also uses GRPH_FLIP and VLINE IRQs, which are properly tracked by get/put(). Cc: stable@vger.kernel.org Fixes: 8382cd234981 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260723180159.52121-1-sunpeng.li@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2026-07-24drm/i915/fbc: No surface size restrictions from LNL onwardsVinod Govindapillai
From xe2_lpd+ platforms, enabling FBC do not depend on the surface size. So remove the check. v2: changes to patch description Bspec: 69560 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-3-vinod.govindapillai@intel.com
2026-07-24drm/i915/fbc: No need of any hardcoded plane width limit from LNL+Vinod Govindapillai
In xe2_lpd+ platforms, there are no restrictions to enable FBC on planes with respect to the plane width - width can be as per the platform's maximum supported resolution. v2: patches squashed and changes in patch descriptions Bspec: 69560 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-2-vinod.govindapillai@intel.com
2026-07-24drm/xe/display: Expose plane max width/height helpers to global scopeVinod Govindapillai
Enabling features like FBC on platforms may depend on a plane's maximum supported resolutions or some other arbitrary constant values because of hw restrictions. Currently the helpers that report a plane's max width and height are private to skl_plane / skl_universal_plane. Change the scope to golbal so that this can be queried from other areas as well. v2: function parameter alignment fixes Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-1-vinod.govindapillai@intel.com
2026-07-24Merge tag 'drm-misc-fixes-2026-07-24' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2-rc5: - Improve damage handling in appletbdrm. - Fix harmful fragmenting of MM by backing up TTM pages at native page order. - Fix timeout handling in amdxdna. - Fix imagination locking for map/unmap operations. - Fix mm leak in gpusvm eviction. - Properly zero page array in gpusvm mm scanning. - Prevent trusted shader bo's from being mapped again in vc4. - Validate shader array size in vmwgfx. - Fix length calculation bugs in ethosu. - Better error handling during pagemap migration. - Improve v3d suspend. - Kconfig updates for some panels. - Handle missing iovcc in ili9881c panel. - Fix vc4 unbind. - Add i2c error handling in gma500. - Fix kunit tests on pp64le and s390x. - Prevent rearming vc4 timer on shutdown. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/07284633-6b9b-40f9-8949-b1516a42a34c@linux.intel.com
2026-07-24drm/imagination: Fix value of HWRT address in pvr_job_create tracepointAlessio Belle
The pvr_job_create tracepoint was using pvr_fw_object::fw_addr_offset to display the firmware address of the render target structure attached to a job, but that's an offset into the firmware heap, not the expected full address, which is more useful in general e.g. for cross referencing against firmware logs. Use pvr_fw_object_get_fw_addr() to get the full firmware address. Fixes: c1079aebb4de ("drm/imagination: Add support for trace points") Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260720-fix-pvr-job-trace-hwrt-v1-1-b24551802efb@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/imagination: promote BXM-4-64 MC1 (36.52.104.182) to supported statusFrank Binns
Support for this GPU is now in a very good state, with only a handful of Vulkan CTS tests still failing when testing using CTS version 1.4.5.3 on the BeagleV-Ahead SBC. With the firmware having been upstreamed [1], now is the time to promote this GPU from experimental to supported. [1] https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1138 Signed-off-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260720-promote-bxm-4-64-v1-2-39abcd1cf263@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/imagination: update GPU support documentationFrank Binns
The list of supported GPUs contains the GPU model, along with the SoCs they're found in. The SoC information can easily get out of date, as typically GPU models will be integrated into many different SoCs and upstream support for these can potentially happen over a long stretch of time without necessarily requiring any GPU driver changes. Replace the SoC information with the BVNC instead. This uniquely identifies a GPU implementation and is useful in cases where a GPU model may have multiple implementations due to, e.g. hardware errata having been fixed, and the driver doesn't yet support all of them. Signed-off-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260720-promote-bxm-4-64-v1-1-39abcd1cf263@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/tve200: add OF module alias for autoloadingCan Peng
The TVE200 DRM driver can be built as a module and uses tve200_of_match as its OF match table, but the table is not exported for module alias generation. Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module aliases for OF based module autoloading. Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200") Signed-off-by: Can Peng <pengcan@kylinos.cn> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260715024130.186416-1-pengcan@kylinos.cn
2026-07-24Revert "drm/pagemap: Guard HPAGE_PMD_ORDER use with ↵Maarten Lankhorst
CONFIG_ARCH_ENABLE_THP_MIGRATION" This reverts commit 04b177544a040cbafab760d6b766381c6b22e0a8. The original author requested it to be reverted, as it conflicts with changes in the -next branch for MM: "I'm not sure who is doing the drm-misc-fixes PR, but if you are can you omit this patch: https://patchwork.freedesktop.org/series/170865/ I guess this conflicts with MM changes in their next tree and it easy enough on our side to do this slightly differently to avoid a conflict so going to post revert + a different change. If this is already sent nbd." Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>