summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-11-26Revert "drm/amd/display: Move setup_stream_attribute"Alex Deucher
This reverts commit 2681bf4ae8d24df950138b8c9ea9c271cd62e414. This results in a blank screen on the HDMI port on some systems. Revert for now so as not to regress 6.18, can be addressed in 6.19 once the issue is root caused. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4652 Cc: Sunpeng.Li@amd.com Cc: ivan.lipski@amd.com Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d0e9de7a81503cdde37fb2d37f1d102f9e0f38fb)
2025-11-26drm/amdgpu: fix cyan_skillfish2 gpu info fw handlingAlex Deucher
If the board supports IP discovery, we don't need to parse the gpu info firmware. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4721 Fixes: fa819e3a7c1e ("drm/amdgpu: add support for cyan skillfish gpu_info") Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amdgpu: Fix CPER ring debugfs read buffer overflow riskSrinivasan Shanmugam
The CPER ring debugfs read code always writes a 12-byte header when the file is read for the first time (*offset == 0): copy_to_user(buf, ring_header, 12); But the code never checks whether the user buffer (@size) is at least 12 bytes long. After writing the 12-byte header, the code then gives the full original @size to the CPER payload handler: record_req->buf_size = size; This means the function can write: 12 bytes (header) + payload bytes (up to @size) into a buffer that is only @size bytes big. In other words, the kernel may write more data than the user asked for. This can overflow the user buffer. The fix is: - If the user buffer is smaller than 12 bytes on the first read, return -EINVAL instead of copying the header. - After writing the 12-byte header, subtract 12 from @size and pass the reduced size to record_req->buf_size. This ensures the CPER payload only uses the remaining free space in the buffer. Reads after the first one (*offset != 0) do not write the header, so their behavior stays exactly the same. The only user-visible change is that tiny buffers now fail safely instead of risking an overflow. Fixes: drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:523 amdgpu_ras_cper_debugfs_read() warn: userbuf overflow? is 'ring_header_size' <= 'size' Fixes: 527e3d40339b ("drm/amd/ras: Add CPER ring read for uniras") Reported by: Dan Carpenter <dan.carpenter@linaro.org> Cc: Xiang Liu <xiang.liu@amd.com> Cc: Tao Zhou <tao.zhou1@amd.com> Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amdgpu: attach tlb fence to the PTs updatePrike Liang
Ensure the userq TLB flush is emitted only after the VM update finishes and the PT BOs have been annotated with bookkeeping fences. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amdkfd: assign AID to uuid in topology for SPX modeEric Huang
XCD id is assigned to uuid, which causes some performance drop in SPX mode, assigning AID back will resolve the issue. Fixes: 3a75edf93aae ("drm/amdkfd: set uuid for each partition in topology") Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amd/display: Check ATOM_DEVICE_CRT2_SUPPORT in dc_load_detectionIvan Lipski
[WHY & HOW] Fix the typo of the else-if condition from ATOM_DEVICE_CRT1_SUPPORT to ATOM_DEVICE_CRT2_SUPPORT. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amd/display: Add cursor offload abort to the new HWSS pathNicholas Kazlauskas
[HOW] If cursor attributes or position are passed into DC via a stream update and we take the newer HWSS paths then it's possible that the update races with cursor offloading if it's enabled. This can cause the cursor to remain on the screen if no further updates come in if it results in HW cursor support being disabled. [HOW] Add the abort into the HWSS path so that cursor offloading doesn't attempt to reprogram the cursor with outdated params. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amd/display: Increase EDID read retriesMario Limonciello (AMD)
[WHY] When monitor is still booting EDID read can fail while DPCD read is successful. In this case no EDID data will be returned, and this could happen for a while. [HOW] Increase number of attempts to read EDID in dm_helpers_read_local_edid() to 25. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672 Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amd/display: Fix dereference-before-check for dc_linkSrinivasan Shanmugam
The function dereferences amdgpu_dm_connector->dc_link early to initialize verified_link_cap and dc, but later still checks amdgpu_dm_connector->dc_link for NULL in the analog path. This late NULL check is redundant, introduce a local dc_link pointer, use it consistently, and drop the superfluous NULL check while using dc_link->link_id.id instead. The function uses dc_link at the very beginning without checking if it is NULL. But later in the code, it suddenly checks if dc_link is NULL. This check is too late to be useful, because the code has already used dc_link earlier. So this NULL check does nothing. We simplify the code by storing amdgpu_dm_connector->dc_link in a local dc_link variable and using it throughout the function. Since dc_link is already dereferenced early, the later NULL check is unnecessary and is removed. Fixes the below: amdgpu_dm_connector_get_modes(): variable dereferenced before check 'amdgpu_dm_connector->dc_link' drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c 8845 &amdgpu_dm_connector->dc_link->verified_link_cap; 8846 const struct dc *dc = amdgpu_dm_connector->dc_link->dc; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Dereference ... 8856 8857 if (amdgpu_dm_connector->dc_sink && 8858 amdgpu_dm_connector->dc_link && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Checked too late. Presumably this NULL check could be removed? ... Fixes: d46e422f65ae ("drm/amd/display: Cleanup uses of the analog flag") Reported by: Dan Carpenter <dan.carpenter@linaro.org> Cc: Timur Kristóf <timur.kristof@gmail.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amd/display: Don't change brightness for disabled connectorsMario Limonciello (AMD)
[WHY] When a laptop lid is closed the connector is disabled but userspace can still try to change brightness. This doesn't work because the panel is turned off. It will eventually time out, but there is a lot of stutter along the way. [How] Iterate all connectors to check whether the matching one for the backlight index is enabled. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4675 Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Ray Wu <ray.wu@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amd/display: Fix logical vs bitwise bug in get_embedded_panel_info_v2_1()Dan Carpenter
The .H_SYNC_POLARITY and .V_SYNC_POLARITY variables are 1 bit bitfields of a u32. The ATOM_HSYNC_POLARITY define is 0x2 and the ATOM_VSYNC_POLARITY is 0x4. When we do a bitwise negate of 0, 2, or 4 then the last bit is always 1 so this code always sets .H_SYNC_POLARITY and .V_SYNC_POLARITY to true. This code is instead intended to check if the ATOM_HSYNC_POLARITY or ATOM_VSYNC_POLARITY flags are set and reverse the result. In other words, it's supposed to be a logical negate instead of a bitwise negate. Fixes: ae79c310b1a6 ("drm/amd/display: Add DCE12 bios parser support") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amd/display: Check NULL before accessingAlex Hung
[WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26Revert "drm/amd/display: Move setup_stream_attribute"Alex Deucher
This reverts commit 2681bf4ae8d24df950138b8c9ea9c271cd62e414. This results in a blank screen on the HDMI port on some systems. Revert for now so as not to regress 6.18, can be addressed in 6.19 once the issue is root caused. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4652 Cc: Sunpeng.Li@amd.com Cc: ivan.lipski@amd.com Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amdgpu: free job fences on failure in amdgpu_job_alloc_with_ibPierre-Eric Pelloux-Prayer
Otherwise we're leaking memory. Fixes: db36632ea51e ("drm/amdgpu: clean up and unify hw fence handling") Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amdgpu: clear job on failure in amdgpu_job_alloc(_with_ib)Pierre-Eric Pelloux-Prayer
If memory is freed we need to nullify the pointer or the caller might call kfree again (eg: amdgpu_cs_parser_fini calls kfree on all non-null job pointers). Fixes: db36632ea51e ("drm/amdgpu: clean up and unify hw fence handling") Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-26drm/amdgpu: use ttm_resource_manager_cleanupPierre-Eric Pelloux-Prayer
Rather than open-coding it. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20251121101315.3585-3-pierre-eric.pelloux-prayer@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2025-11-26drm/ttm: rework pipelined eviction fence handlingPierre-Eric Pelloux-Prayer
Until now ttm stored a single pipelined eviction fence which means drivers had to use a single entity for these evictions. To lift this requirement, this commit allows up to 8 entities to be used. Ideally a dma_resv object would have been used as a container of the eviction fences, but the locking rules makes it complex. dma_resv all have the same ww_class, which means "Attempting to lock more mutexes after ww_acquire_done." is an error. One alternative considered was to introduced a 2nd ww_class for specific resv to hold a single "transient" lock (= the resv lock would only be held for a short period, without taking any other locks). The other option, is to statically reserve a fence array, and extend the existing code to deal with N fences, instead of 1. The driver is still responsible to reserve the correct number of fence slots. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Link: https://lore.kernel.org/r/20251121101315.3585-20-pierre-eric.pelloux-prayer@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2025-11-26drm/panthor: Reset queue slots if termination failsAshley Smith
Make sure the queue slot is reset even if we failed termination so we don't have garbage in the CS input interface after a reset. In practice that's not a problem because we zero out all RW sections when a hangs occurs, but it's safer to reset things manually, in case we decide to not conditionally reload RW sections based on the type of hang. v4: - Split the changes in two separate patches v5: - No changes v6: - Adjust the explanation in the commit message - Drop the Fixes tag - Put after the timeout changes and make the two patches independent so one can be backported, and the other not v7: - Use the local group variable instead of dereferencing csg_slot->group - Add Steve's R-b v8: - No changes Signed-off-by: Ashley Smith <ashley.smith@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251113105734.1520338-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Make the timeout per-queue instead of per-jobAshley Smith
The timeout logic provided by drm_sched leads to races when we try to suspend it while the drm_sched workqueue queues more jobs. Let's overhaul the timeout handling in panthor to have our own delayed work that's resumed/suspended when a group is resumed/suspended. When an actual timeout occurs, we call drm_sched_fault() to report it through drm_sched, still. But otherwise, the drm_sched timeout is disabled (set to MAX_SCHEDULE_TIMEOUT), which leaves us in control of how we protect modifications on the timer. One issue seems to be when we call drm_sched_suspend_timeout() from both queue_run_job() and tick_work() which could lead to races due to drm_sched_suspend_timeout() not having a lock. Another issue seems to be in queue_run_job() if the group is not scheduled, we suspend the timeout again which undoes what drm_sched_job_begin() did when calling drm_sched_start_timeout(). So the timeout does not reset when a job is finished. v2: - Fix syntax error v3: - Split the changes in two commits v4: - No changes v5: - No changes v6: - Fix a NULL deref in group_can_run(), and narrow the group variable scope to avoid such mistakes in the future - Add an queue_timeout_is_suspended() helper to clarify things v7: - No changes v8: - Don't touch drm_gpu_scheduler::timeout in queue_timedout_job() Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Signed-off-by: Ashley Smith <ashley.smith@collabora.com> Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251113105734.1520338-2-boris.brezillon@collabora.com
2025-11-26drm/gem: Correct error condition in drm_gem_objects_lookupSteven Price
When vmemdup_array_user() fails, 'handles' is set to a negative error code and no memory is allocated. So the call to kvfree() should not happen. Instead just return early with the error code. Fixes: cb77b79abf5f ("drm/gem: Use vmemdup_array_user in drm_gem_objects_lookup") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20251124112039.117748-1-steven.price@arm.com
2025-11-26drm/xe: Add caching pagetable flagZbigniew Kempczyński
Introduce device xe_caching_pt flag to selectively turn it on for supported platforms. It allows to eliminate version check and enable this feature for the future platforms. Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251125153732.400766-2-zbigniew.kempczynski@intel.com
2025-11-26drm/xe/vm: Skip ufence association for CPU address mirror VMA during MAPHimal Prasad Ghimiray
The MAP operation for a CPU address mirror VMA does not require ufence association because such mappings are not GPU-synchronized and do not participate in GPU job completion signaling. Remove the unnecessary ufence addition for this case to avoid -EBUSY failure in check_ufence of unbind ops. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251125075628.1182481-6-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-11-26drm/xe/svm: Enable UNMAP for VMA merging operationsHimal Prasad Ghimiray
ALLOW UNMAP of VMAs associated with SVM mappings when the MAP operation is intended to merge adjacent CPU_ADDR_MIRROR VMAs. v2 - Remove mapping exist check in garbage collector Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251125075628.1182481-5-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-11-26drm/xe/svm: Extend MAP range to reduce vma fragmentationHimal Prasad Ghimiray
When DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR is set during VM_BIND_OP_MAP, the mapping logic now checks adjacent cpu_addr_mirror VMAs with default attributes and expands the mapping range accordingly. This ensures that bo_unmap operations ideally target the same area and helps reduce fragmentation by coalescing nearby compatible VMAs into a single mapping. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251125075628.1182481-4-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-11-26drm/xe: Merge adjacent default-attribute VMAs during garbage collectionHimal Prasad Ghimiray
While restoring default memory attributes for VMAs during garbage collection, extend the target range by checking neighboring VMAs. If adjacent VMAs are CPU-address-mirrored and have default attributes, include them in the mergeable range to reduce fragmentation and improve VMA reuse. v2 -Rebase Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251125075628.1182481-3-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-11-26drm/xe: Add helper to extend CPU-mirrored VMA range for mergeHimal Prasad Ghimiray
Introduce xe_vm_find_cpu_addr_mirror_vma_range(), which computes an extended range around a given range by including adjacent VMAs that are CPU-address-mirrored and have default memory attributes. This helper is useful for determining mergeable range without performing the actual merge. v2 - Add assert - Move unmap check to this patch v3 - Decrease offset to check by SZ_4K to avoid wrong vma return in fast lookup path v4 - *start should be >= SZ_4K (Matt) Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251125075628.1182481-2-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-11-26drm/panthor: Improve IOMMU map/unmap debugging logsLoïc Molinari
Log the number of pages and their sizes actually mapped/unmapped by the IOMMU page table driver. Since a map/unmap op is often split in several ops depending on the underlying scatter/gather table, add the start address and the total size to the debugging logs in order to help understand which batch an op is part of. Signed-off-by: Loïc Molinari <loic.molinari@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251114170303.2800-10-loic.molinari@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Add support for Mali-G1 GPUsKarunika Choo
Add support for Mali-G1 GPUs (CSF architecture v14), introducing a new panthor_hw_arch_v14 entry with reset and L2 power management operations via the PWR_CONTROL block. Mali-G1 introduces a dedicated PWR_CONTROL block for managing resets and power domains. panthor_gpu_info_init() is updated to use this block for L2, tiler, and shader domain present register reads. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://patch.msgid.link/20251125125548.3282320-9-karunika.choo@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Support 64-bit endpoint_req register for Mali-G1Karunika Choo
Add support for the 64-bit endpoint_req register introduced in CSF v4.0+ GPUs. Unlike a simple register widening, the 64-bit variant occupies the next 64 bits after the original 32-bit field, requiring version-dependent access. This change introduces helper functions to read, write, and update the endpoint_req register, ensuring correct handling on both pre-v4.0 and v4.0+ firmwares. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://patch.msgid.link/20251125125548.3282320-8-karunika.choo@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Support GLB_REQ.STATE field for Mali-G1 GPUsKarunika Choo
Add support for the GLB_REQ.STATE field introduced in CSF v4.1+, which replaces the HALT bit to provide finer control over the MCU state. This change implements basic handling for transitioning the MCU between ACTIVE and HALT states on Mali-G1 GPUs. The update introduces new helpers to issue the state change requests, poll for MCU halt completion, and restore the MCU to an active state after halting. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://patch.msgid.link/20251125125548.3282320-7-karunika.choo@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Implement soft reset via PWR_CONTROLKarunika Choo
Add helpers to issue reset commands through the PWR_CONTROL interface and wait for reset completion using IRQ signaling. This enables support for RESET_SOFT operations with timeout handling and status verification. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://patch.msgid.link/20251125125548.3282320-6-karunika.choo@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Implement L2 power on/off via PWR_CONTROLKarunika Choo
This patch adds common helpers to issue power commands, poll transitions, and validate domain state, then wires them into the L2 on/off paths. The L2 power-on sequence now delegates control of the SHADER and TILER domains to the MCU when allowed, while the L2 itself is never delegated. On power-off, dependent domains beneath the L2 are checked, and if necessary, retracted and powered down to maintain proper domain ordering. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://patch.msgid.link/20251125125548.3282320-5-karunika.choo@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Introduce panthor_pwr API and power control frameworkKarunika Choo
Add the new panthor_pwr module, which provides basic power control management for Mali-G1 GPUs. The initial implementation includes infrastructure for initializing the PWR_CONTROL block, requesting and handling its IRQ, and checking for PWR_CONTROL support based on GPU architecture. The patch also integrates panthor_pwr with the device lifecycle (init, suspend, resume, and unplug) through the new API functions. It also registers the IRQ handler under the 'gpu' IRQ as the PWR_CONTROL block is located within the GPU_CONTROL block. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://patch.msgid.link/20251125125548.3282320-4-karunika.choo@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Add architecture-specific function operationsKarunika Choo
Introduce architecture-specific function pointers to support architecture-dependent behaviours. This patch adds the following function pointers and updates their usage accordingly: - soft_reset - l2_power_on - l2_power_off Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://patch.msgid.link/20251125125548.3282320-3-karunika.choo@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Add arch-specific panthor_hw bindingKarunika Choo
This patch adds the framework for binding to a specific panthor_hw structure based on the architecture major value parsed from the GPU_ID register. This is in preparation of enabling architecture-specific behaviours based on GPU_ID. As such, it also splits the GPU_ID register read operation into its own helper function. This framework allows a single panthor_hw structure to be shared across multiple architectures should there be minimal changes between them via the arch_min and arch_max field of the panthor_hw_entry structure, instead of duplicating the structure across multiple architectures. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://patch.msgid.link/20251125125548.3282320-2-karunika.choo@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Avoid adding of kernel BOs to extobj listAkash Goel
The kernel BOs unnecessarily got added to the external objects list of drm_gpuvm, when mapping to GPU, which would have resulted in few extra CPU cycles being spent at the time of job submission as drm_exec_until_all_locked() loop iterates over all external objects. Kernel BOs are private to a VM and so they share the dma_resv object of the dummy GEM object created for a VM. Use of DRM_EXEC_IGNORE_DUPLICATES flag ensured the recursive locking of the dummy GEM object was ignored. Also no extra space got allocated to add fences to the dma_resv object of dummy GEM object. So no other impact apart from few extra CPU cycles. This commit sets the pointer to dma_resv object of GEM object of kernel BOs before they are mapped to GPU, to prevent them from being added to external objects list. v2: Add R-bs and fixes tags Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Signed-off-by: Akash Goel <akash.goel@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251120172118.2741724-1-akash.goel@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-25drm/xe: Fix conversion from clock ticks to millisecondsHarish Chegondi
When tick counts are large and multiplication by MSEC_PER_SEC is larger than 64 bits, the conversion from clock ticks to milliseconds can go bad. Use mul_u64_u32_div() instead. Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Suggested-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Fixes: 49cc215aad7f ("drm/xe: Add xe_gt_clock_interval_to_ms helper") Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/1562f1b62d5be3fbaee100f09107f3cc49e40dd1.1763408584.git.harish.chegondi@intel.com (cherry picked from commit 96b93ac214f9dd66294d975d86c5dee256faef91) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-25drm/xe/guc: Fix stack_depot usageLucas De Marchi
Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: [] BUG: kernel NULL pointer dereference, address: 0000000000000000 [] Workqueue: drm_sched_run_job_work [gpu_sched] [] RIP: 0010:stack_depot_save_flags+0x172/0x870 [] Call Trace: [] <TASK> [] fast_req_track+0x58/0xb0 [xe] Fixes: 16b7e65d299d ("drm/xe/guc: Track FAST_REQ H2Gs to report where errors came from") Tested-by: Sagar Ghuge <sagar.ghuge@intel.com> Cc: stable@vger.kernel.org # v6.17+ Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251118-fix-debug-guc-v1-1-9f780c6bedf8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-25drm/xe/guc: Fix resource leak in xe_guc_ct_init_noalloc()Shuicheng Lin
xe_guc_ct_init_noalloc() allocates the CT workqueue and other helpers before it tries to initialize ct->lock. If drmm_mutex_init() fails we currently bail out without releasing those resources because the guc_ct_fini() hasn’t been registered yet. Since destroy_workqueue() in guc_ct_fini() may flush the workqueue, which in turn can take the ct lock, the initialization sequence is restructured to first initialize the ct->lock, then set up all CT state, and finally register guc_ct_fini(). v2: guc_ct_fini() does take ct lock. (Matt) v3: move primelockdep() together with drmm_mutex_init(). (Lucas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251110184522.1581001-2-shuicheng.lin@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 2e4ad5b0667244f496783c58de0995b9562d3344) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-25drm/xe: Protect against unset LRC when pausing submissionsTomasz Lis
While pausing submissions, it is possible to encouner an exec queue which is during creation, and therefore doesn't have a valid xe_lrc struct reference. Protect agains such situation, by checking for NULL before access. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Fixes: c25c1010df88 ("drm/xe/vf: Replay GuC submission state on pause / unpause") Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251124222853.1900800-1-tomasz.lis@intel.com
2025-11-25drm/xe/vf: Start re-emission from first unsignaled job during VF migrationMatthew Brost
The LRC software ring tail is reset to the first unsignaled pending job's head. Fix the re-emission logic to begin submitting from the first unsignaled job detected, rather than scanning all pending jobs, which can cause imbalance. v2: - Include missing local changes v3: - s/skip_replay/restore_replay (Tomasz) Fixes: c25c1010df88 ("drm/xe/vf: Replay GuC submission state on pause / unpause") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://patch.msgid.link/20251121152750.240557-1-matthew.brost@intel.com
2025-11-25drm/xe/pf: Handle MERT catastrophic errorsLukasz Laguna
The MERT block triggers an interrupt when a catastrophic error occurs. Update the interrupt handler to read the MERT catastrophic error type and log appropriate debug message. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251124190237.20503-5-lukasz.laguna@intel.com
2025-11-25drm/xe/pf: Add TLB invalidation support for MERTLukasz Laguna
Add support for triggering and handling MERT TLB invalidation. After LMTT updates, the MERT TLB invalidation is initiated to ensure memory translations remain coherent. Completion of the invalidation is signaled via MERT interrupt (bit 13 in the GFX master interrupt register). Detect and handle this interrupt to properly synchronize the invalidation flow. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251124190237.20503-4-lukasz.laguna@intel.com
2025-11-25drm/xe/pf: Configure LMTT in MERTLukasz Laguna
On platforms with standalone MERT, the PF driver needs to program LMTT in MERT's LMEM_CFG register. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251124190237.20503-3-lukasz.laguna@intel.com
2025-11-25drm/xe: Add device flag to indicate standalone MERTLukasz Laguna
The MERT subsystem manages memory accesses between host and device. On the Crescent Island platform, it requires direct management by the driver. Introduce a device flag and corresponding helpers to identify platforms with standalone MERT, enabling proper initialization and handling. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251124190237.20503-2-lukasz.laguna@intel.com
2025-11-25drm/i915: use struct drm_device for clock gating funcsJani Nikula
While we want to refactor intel_clock_gating.[ch] and likely move a lot of display related code to display, start off with a little intermediate change to use struct drm_device in the interface instead of struct drm_i915_private, to allow us to drop another dependency on i915_drv.h and struct drm_i915_private. Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20251121112200.3435099-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-25drm/i915/cdclk: drop i915_drv.h includeJani Nikula
intel_cdclk.c no longer needs i915_drv.h. Drop it. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20251121112200.3435099-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-25drm/i915/psr: Reject async flips when selective fetch is enabledVille Syrjälä
The selective fetch code doesn't handle asycn flips correctly. There is a nonsense check for async flips in intel_psr2_sel_fetch_config_valid() but that only gets called for modesets/fastsets and thus does nothing for async flips. Currently intel_async_flip_check_hw() is very unhappy as the selective fetch code pulls in planes that are not even async flips capable. Reject async flips when selective fetch is enabled, until someone fixes this properly (ie. disable selective fetch while async flips are being issued). Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251105171015.22234-1-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> (cherry picked from commit a5f0cc8e0cd4007370af6985cb152001310cf20c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-25drm/fb-helper: Allocate and release fb_info in single placeThomas Zimmermann
Move the calls to drm_fb_helper_alloc_info() from drivers into a single place in fbdev helpers. Allocates struct fb_info for a new framebuffer device. Then call drm_fb_helper_single_fb_probe() to create an fbdev screen buffer. Also release the instance on errors by calling drm_fb_helper_release_info(). Simplifies the code and fixes the error cleanup for some of the drivers. Regular release of the struct fb_info instance still happens in drm_fb_helper_fini() as before. v2: - remove error rollback in driver implementations (kernel test robot) - initialize info in TTM implementation (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> # radeon Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # msm Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20251027081245.80262-1-tzimmermann@suse.de
2025-11-25drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupThomas Zimmermann
Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://elixir.bootlin.com/linux/v6.17/source/drivers/video/fbdev/core/fbcon.c#L2942 # [1] Fixes: 6a9ee8af344e ("vga_switcheroo: initial implementation (v15)") Acked-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: <stable@vger.kernel.org> # v2.6.34+ Link: https://patch.msgid.link/20251105161549.98836-1-tzimmermann@suse.de
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-16 06:35:46 +0000