aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-12-01drm/xe/pf: Use div_u64 when calculating GGTT profileMichal Wajdeczko1-1/+1
This will fix the following error seen on some 32-bit config: "ERROR: modpost: "__udivdi3" [drivers/gpu/drm/xe/xe.ko] undefined!" Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511150929.3vUi6PEJ-lkp@intel.com/ Fixes: e448372e8a8e ("drm/xe/pf: Use migration-friendly GGTT auto-provisioning") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251115151323.10828-1-michal.wajdeczko@intel.com (cherry picked from commit 0f4435a1f46efc3177eb082cd3f73e29da5ab86a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-01drm/xe: Fix memory leak when handling pagefault vmaMika Kuoppala1-1/+0
When the pagefault handling code was moved to a new file, an extra drm_exec_init() was added to the VMA path. This call is unnecessary because xe_validation_ctx_init() already performs a drm_exec_init(), resulting in a memory leak reported by kmemleak. Remove the redundant drm_exec_init() from the VMA pagefault handling code. Fixes: fb544b844508 ("drm/xe: Implement xe_pagefault_queue_work") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: intel-xe@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251120161435.3674556-1-mika.kuoppala@linux.intel.com (cherry picked from commit 62519b77aecad22b525eda482660ffa127e7ad80) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-01drm/xe/pf: Export helpers for VFIOMichał Winiarski2-0/+84
Device specific VFIO driver variant for Xe will implement VF migration. Export everything that's needed for migration ops. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251127093934.1462188-4-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 17f22465c5a5573724c942ca7147b4024631ef87) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-01drm/xe/pci: Introduce a helper to allow VF access to PF xe_deviceMichał Winiarski2-0/+20
In certain scenarios (such as VF migration), VF driver needs to interact with PF driver. Add a helper to allow VF driver access to PF xe_device. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251127093934.1462188-3-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 8b3cce3ad9c78ce3dae1c178f99352d50e12a3c0) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-01drm/xe/pf: Enable SR-IOV VF migrationMichał Winiarski4-7/+42
All of the necessary building blocks are now in place to support SR-IOV VF migration. Flip the enable/disable logic to match VF code and disable the feature only for platforms that don't meet the necessary prerequisites. To allow more testing and experiments, on DEBUG builds any missing prerequisites will be ignored. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251127093934.1462188-2-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 01c724aa7bf84e9d081a56e0cbf1d282678ce144) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-01drm/xe/pm: Add scope-based cleanup helper for runtime PMMatt Roper2-0/+38
Add a scope-based helpers for runtime PM that may be used to simplify cleanup logic and potentially avoid goto-based cleanup. For example, using guard(xe_pm_runtime)(xe); will get runtime PM and cause a corresponding put to occur automatically when the current scope is exited. 'xe_pm_runtime_noresume' can be used as a guard replacement for the corresponding 'noresume' variant. There's also an xe_pm_runtime_ioctl conditional guard that can be used as a replacement for xe_runtime_ioctl(): ACQUIRE(xe_pm_runtime_ioctl, pm)(xe); if ((ret = ACQUIRE_ERR(xe_pm_runtime_ioctl, &pm)) < 0) /* failed */ In a few rare cases (such as gt_reset_worker()) we need to ensure that runtime PM is dropped when the function is exited by any means (including error paths), but the function does not need to acquire runtime PM because that has already been done earlier by a different function. For these special cases, an 'xe_pm_runtime_release_only' guard can be used to handle the release without doing an acquisition. These guards will be used in future patches to eliminate some of our goto-based cleanup. v2: - Specify success condition for xe_pm runtime_ioctl as _RET >= 0 so that positive values will be properly identified as success and trigger destructor cleanup properly. v3: - Add comments to the kerneldoc for the existing 'get' functions indicating that scope-based handling should be preferred where possible. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251118164338.3572146-31-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 59e7528dbfd52efbed05e0f11b2143217a12bc74) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-01drm/ast: Wrap cursor framebuffer access in drm_gem_fb_begin/end_cpu_access()Thomas Zimmermann1-31/+43
Call drm_gem_fb_begin_cpu_access() and drm_gem_fb_end_cpu_access() around cursor image updates. Imported buffers might have to be synchronized for CPU access before they can be used. Ignore errors from drm_gem_fb_begin_cpu_access(). These errors can often be transitory. The cursor image will be updated on the next frame. Meanwhile display a white square where the cursor would be. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Link: https://patch.msgid.link/20251126094626.41985-4-tzimmermann@suse.de
2025-12-01drm/ast: Support cursor buffers objects in I/O memoryThomas Zimmermann1-1/+14
Copy the ARGB4444 cursor buffer to system memory if it is located in I/O memory. While this cannot happen with ast's native GEM objects, an imported buffer object might be on the external device's I/O memory. If the cursor buffer is located in system memory continue to use it directly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Link: https://patch.msgid.link/20251126094626.41985-3-tzimmermann@suse.de
2025-12-01drm/ast: Move cursor format conversion into helper functionThomas Zimmermann1-23/+39
Move the format conversion of the cursor framebuffer into the new helper ast_cursor_plane_get_argb4444(). It returns a buffer in system memory, which the atomic_update handler copies to video memory. The returned buffer is either the GEM buffer itself, or a temporary copy within the plane in ARGB4444 format. As a small change, list supported formats explicitly in the switch statement. Do not assume ARGB8888 input by default. The cursor framebuffer knows its format, so should we. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20251126094626.41985-2-tzimmermann@suse.de
2025-11-28drm/xe/pf: Export helpers for VFIOMichał Winiarski2-0/+84
Device specific VFIO driver variant for Xe will implement VF migration. Export everything that's needed for migration ops. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251127093934.1462188-4-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-28drm/xe/pci: Introduce a helper to allow VF access to PF xe_deviceMichał Winiarski2-0/+20
In certain scenarios (such as VF migration), VF driver needs to interact with PF driver. Add a helper to allow VF driver access to PF xe_device. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251127093934.1462188-3-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-28drm/xe/pf: Enable SR-IOV VF migrationMichał Winiarski4-7/+42
All of the necessary building blocks are now in place to support SR-IOV VF migration. Flip the enable/disable logic to match VF code and disable the feature only for platforms that don't meet the necessary prerequisites. To allow more testing and experiments, on DEBUG builds any missing prerequisites will be ignored. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251127093934.1462188-2-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-28i915/display/intel_ddi: Reduce severity of failed FEC enablingMichał Grzelak1-1/+1
During some IGT tests (e.g. xe_pm@s2idle-exec-after, xe_pm@s2idle-mocs) sink disconnects across suspend/resume, reconnecting later during resume at some point. Hence during resume, where the driver is restoring the pre-suspend mode, all the AUX transfers to the sink are expected to fail. Switch error message to KMS debug message of failed FEC enabling. Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251117082046.4190705-1-michal.grzelak@intel.com
2025-11-28drm/panic: Report invalid or unsupported panic modesTvrtko Ursulin1-13/+62
Currently the user can write anything into the drm.panic_screen modparam, either at runtime via sysfs, or as a kernel boot time argument. Invalid strings will be silently accepted and ignored at use time by defaulting to the 'user' panic mode. Let instead add some validation in order to have immediate feedback when something has been mistyped, or not compiled in. For example during kernel boot: Booting kernel: `bsod' invalid for parameter `drm.panic_screen' Or at runtime: # echo -n bsod > /sys/module/drm/parameters/panic_screen -bash: echo: write error: Invalid argument Change of behavior is that when invalid mode is attempted to be configured, currently the code will default to the 'user' mode, while with this change the code will ignore it, and default to the mode set at kernel build time via CONFIG_DRM_PANIC_SCREEN. While at it lets also fix the module parameter description to include all compiled in modes. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251127090349.92717-1-tvrtko.ursulin@igalia.com
2025-11-28drm/panthor: Kill panthor_sched_immediate_tick()Boris Brezillon1-9/+2
It's only used in a couple places and everyone else is just using sched_queue_delayed_work(sched, tick, 0) directly, so let's make this consistent. v2: - Add R-b v3: - Collect R-b Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251128094839.3856402-9-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Make sure we resume the tick when new jobs are submittedBoris Brezillon1-9/+34
If the group is already assigned a slot but was idle before this job submission, we need to make sure the priority rotation happens in the future. Extract the existing logic living in group_schedule_locked() and call this new sched_resume_tick() helper from the "group is assigned a slot" path. v2: - Add R-b v3: - Re-use queue_mask to clear the bit - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251128094839.3856402-8-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Fix the logic that decides when to stop tickingBoris Brezillon1-27/+17
When we have multiple active groups with the same priority, we need to keep ticking for the priority rotation to take place. If we don't do that, we might starve slots with lower priorities. It's annoying to deal with that in tick_ctx_update_resched_target(), so let's add a ::stop_tick field to the tick context which is initialized to true, and downgraded to false as soon as we detect something that requires to tick to happen. This way we can complement the current logic with extra conditions if needed. v2: - Add R-b v3: - Drop panthor_sched_tick_ctx::min_priority (no longer relevant) - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251128094839.3856402-7-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Fix immediate ticking on a disabled tickBoris Brezillon1-2/+7
We have a few paths where we schedule the tick work immediately without changing the resched_target. If the tick was stopped, this would lead to a remaining_jiffies that's always > 0, and it wouldn't force a full tick in that case. Add extra checks to cover that case properly. v2: - Fix typo - Simplify the code as suggested by Steve v3: - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251128094839.3856402-6-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Fix the group priority rotation logicBoris Brezillon1-21/+31
When rotating group priorities, we want the group with the highest priority to go back to the end of the queue, and all other active groups to get their priority bumped, otherwise some groups will never get a chance to run with the highest priority. This implies moving the rotation itself to tick_work(), and only dealing with old group ordering in tick_ctx_insert_old_group(). v2: - Add R-b - Fix the commit message v3: - Drop the full_tick argument in tick_ctx_init() - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251128094839.3856402-5-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Fix the full_tick checkBoris Brezillon1-2/+5
We have a full tick when the remaining time to the next tick is zero, not the other way around. Declare a full_tick variable so we don't get that test wrong in other places. v2: - Add R-b v3: - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251128094839.3856402-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Don't try to enable extract eventsBoris Brezillon1-4/+2
Not only this only works once, because of how extract events work (event is enabled if the req and ack bit differ, and it's signalled by the FW by setting identical req and ack, to re-enable the event, we need to toggle the bit, which we never do). But more importantly, we never do anything with this event, so we're better off dropping it when programming the CS slot. v2: - Add R-b v3: - Collect R-b Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251128094839.3856402-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Simplify group idleness trackingBoris Brezillon1-29/+2
csg_slot_sync_queues_state_locked() queries the queues state which can then be used to determine if a group is idle or not. Let's base our idleness detection logic solely on the {idle,blocked}_queues masks to avoid inconsistencies between the group state and the state of its subqueues. v2: - Add R-b v3: - Collect R-b Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251128094839.3856402-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/xe/dsb: drop the unnecessary struct i915_vmaJani Nikula1-20/+8
Now that struct intel_dsb_buffer is opaque, it can be made unique to both drivers, and we can drop the unnecessary struct i915_vma part. Only the struct xe_bo part is needed. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patch.msgid.link/f0bba09d2f185fe3e7f3b803036f036d845a8cc4.1764155417.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/{i915,xe}/dsb: make struct intel_dsb_buffer opaqueJani Nikula3-7/+13
Move the definitions of struct intel_dsb_buffer to the driver specific files, hiding the implementation details from the shared DSB code. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patch.msgid.link/08a8a7745042afcffa647f82ae23ebbeda0234c9.1764155417.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/{i915, xe}/dsb: allocate struct intel_dsb_buffer dynamicallyJani Nikula4-35/+72
Prepare for hiding the struct intel_dsb_buffer implementation details from the generic DSB code. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patch.msgid.link/af94dc06c55a866efa9105ae0a8d244e4c6b17ab.1764155417.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/{i915, xe}/dsb: make {intel, xe}_dsb_buffer.c independent of displayJani Nikula4-9/+7
The DSB buffer implementation is really independent of display. Pass struct drm_device instead of struct intel_crtc to intel_dsb_buffer_create(), and drop the intel_display_types.h include. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patch.msgid.link/a8cee08e8c36c2cf84cb9cda1b9f318db76710af.1764155417.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/panthor: Relax a check in panthor_sched_pre_reset()Boris Brezillon1-2/+0
Groups are only moved out of the runnable lists when panthor_group_stop() is called or when they run out of jobs. What should not happen though is having one group added to one of the runnable list after reset.in_progress has been set to true, but that's not something we can easily check, so let's just drop the WARN_ON() in panthor_sched_pre_reset(). v2: - Adjust explanation in commit message v3: - Collect R-b v4: - No changes Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251128084841.3804658-7-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Make panthor_vm_[un]map_pages() more robustBoris Brezillon1-27/+54
There's no reason for panthor_vm_[un]map_pages() to fail unless the drm_gpuvm state and the page table are out of sync, so let's reflect that by making panthor_vm_unmap_pages() a void function and adding WARN_ON()s in various places. We also try to recover from those unexpected mismatch by checking for already unmapped ranges and skipping them. But there's only so much we can do to try and cope with such SW bugs, so when we see a mismatch, we flag the VM unusable and disable the AS to avoid further GPU accesses to the memory. It could be that the as_disable() call fails because the MMU unit is stuck, in which case the whole GPU is frozen, and only a GPU reset can unblock things. Ater the reset, the VM will be seen as unusable and any attempt to re-use it will fail, so we should be covered for any use-after-unmap issues. v2: - Fix double unlock v3: - Collect R-b v4: - No changes Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251128084841.3804658-6-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Add support for atomic page table updatesBoris Brezillon1-93/+97
Move the lock/flush_mem operations around the gpuvm_sm_[un]map() calls so we can implement true atomic page updates, where any access in the locked range done by the GPU has to wait for the page table updates to land before proceeding. This is needed for vkQueueBindSparse(), so we can replace the dummy page mapped over the entire object by actual BO backed pages in an atomic way. But it's also useful to avoid "AS_ACTIVE bit stuck" failures in the sm_[un]map() path, leading to gpuvm state inconsistencies. v2: - Adjust to match the two new preliminary patches v3: - Collect R-b v4: - No changes Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251128084841.3804658-5-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Recover from panthor_gpu_flush_caches() failuresBoris Brezillon1-7/+12
We have seen a few cases where the whole memory subsystem is blocked and flush operations never complete. When that happens, we want to: - schedule a reset, so we can recover from this situation - in the reset path, we need to reset the pending_reqs so we can send new commands after the reset - if more panthor_gpu_flush_caches() operations are queued after the timeout, we skip them and return -EIO directly to avoid needless waits (the memory block won't miraculously work again) Note that we drop the WARN_ON()s because these hangs can be triggered with buggy GPU jobs created by the UMD, and there's no way we can prevent it. We do keep the error messages though. v2: - New patch v3: - Collect R-b - Explicitly mention the fact we dropped the WARN_ON()s in the commit message v4: - No changes Fixes: 5cd894e258c4 ("drm/panthor: Add the GPU logical block") Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251128084841.3804658-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Kill lock_region()Boris Brezillon1-10/+10
The meat in lock_region() is about packing a region range into a single u64. The rest is just a regular reg write plus a as_send_cmd_and_wait() call that can easily be inlined in mmu_hw_do_operation_locked(). v2: - New patch v3: - Don't LOCK is the region has a zero size v4: - Collect R-b Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251128084841.3804658-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Always wait after sending a command to an ASBoris Brezillon1-15/+12
There's currently no situation where we want to issue a command to an AS and not wait for this command to complete. The wait is either explicitly done (LOCK, UNLOCK) or it's missing (UPDATE). So let's turn write_cmd() into as_send_cmd_and_wait() that has the wait after a command is sent. v2: - New patch v3: - Collect R-b v4: - No changes Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251128084841.3804658-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Prevent potential UAF in group creationAkash Goel1-4/+15
This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags Fixes: de85488138247 ("drm/panthor: Add the scheduler logical block") Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 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> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251127164912.3788155-1-akash.goel@arm.com
2025-11-28drm/{i915,xe}/hdcp: use parent interface for HDCP GSC callsJani Nikula11-81/+126
The HDCP GSC implementation is different for both i915 and xe. Add it to the display parent interface, and call the hooks via the parent interface. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/e397073e91f8aa7518754b3b79f65c1936be91ad.1764090990.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915/hdcp: move i915 specific HDCP GSC implementation to i915Jani Nikula2-2/+5
The HDCP GSC implementation is different for both i915 and xe. Move the i915 specific implementation from display to i915 core. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/d362b256934c6c739d9decda717df2dbc3752481.1764090990.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/display/dp_mst: Add protection against 0 vcpiSuraj Kandpal1-1/+2
When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayed_destroy_work ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0. Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drm_dp_mst_get_port_malloc [drm_display_helper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] Call Trace: <4> [515.287304] <TASK> <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6303 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251119094650.799135-1-suraj.kandpal@intel.com
2025-11-28Merge tag 'drm-xe-fixes-2025-11-27' of ↵Dave Airlie2-12/+10
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix resource leak in xe_guc_ct_init_noalloc()'s error path (Shuicheng Lin) - Fix stack_depot usage without STACKDEPOT_ALWAYS_INIT (Lucas) - Fix overflow in conversion from clock tics to msec (Harish Chegondi) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/7ejiqjgthpqybg5svmkind2pszk4fqadxuq7rngchaaw76iept@5pn6sngqj6lk
2025-11-28Merge tag 'drm-misc-fixes-2025-11-27' of ↵Dave Airlie4-27/+22
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: bridge: - sil902x: Fix HDMI detection imagination: - Update documentation sti: - Fix leaks in probe vga_switcheroo: - Avoid race condition during fbcon initialization Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251127081007.GA13578@2a02-2454-fd5e-fd00-689d-32c0-780c-bb87.dyn6.pyur.net
2025-11-28Merge tag 'amd-drm-fixes-6.18-2025-11-26' of ↵Dave Airlie11-20/+36
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.18-2025-11-26: amdgpu: - Unified MES fix - HDMI fix - Cursor fix - Bightness fix - EDID reading improvement - UserQ fix - Cyan Skillfish IP discovery fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251126204925.3316684-1-alexander.deucher@amd.com
2025-11-28Merge tag 'drm-misc-next-fixes-2025-11-26' of ↵Dave Airlie6-1/+16
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next-fixes for v6.19: - Restrict the pointer size of flush pages to prevent a regression. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/0090a4fc-9cc4-4c03-bfe5-d1b1f0cc7e05@linux.intel.com
2025-11-28Revert "drm/i915/dp: change aux_ctl reg read to polling read"Ville Syrjälä1-5/+7
This reverts commit 5a9b0c7418448ed3766f61ba0a71d08f259c3181. The switch from AUX interrupts to pollign was very hand-wavy. Yes, there have been some situations in CI on a few platforms where the AUX hardware seemingly forgets to signal the timeout, but those have been happening after we switched to polling as well. So I don't think we have any conclusive evidence that polling actually helps here. Someone really should root cause the actual problem, and see if there is a proper workaround we could implemnt (eg. disabling clock gating/etc.). In the meantime just go back to using the interrupt for AUX completion. If the hardware fails to signal the timeout we will just hit the wait_event_timeout() software timeout instead. I suppose we could try to tune the software timeout to more closely match the expected hardware timeout. Might need to use wait_event_hrtimeout() or something to avoid jiffies granularity issues... The AUX polling is also a hinderance towards using poll_timeout_us() because we have a very long timeout, but would need a fairly short polling interval to keep AUX transfer reasonably fast. Someone would need to come up with good numbers in a somewhat scientific way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119185310.10428-3-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915: Enable DDI A/B AUX interrupts on LNL+Ville Syrjälä3-5/+14
Apparently the DDI A/B AUX interrupts move onto the PICA side on LNL. Unmask them properly so that we actually get the interrupts. The interrupt handler was already trying to handle them despite the interrupts remaining masked. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119185310.10428-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915: Eliminate one more frequent drm_format_info()Ville Syrjälä5-14/+20
Another (somewhat expensive) drm_format_info() call has appeared in intel_plane_can_async_flip(). That one may get called several times per commit so we need to get rid of it. Fortunately most callers already have the framebuffer at hand, so we can just grab the format info from there. The one exception is intel_plane_format_mod_supported_async() where we have to do the lookup. But that only gets called (a bunch of times) during driver init to build the IN_FORMATS_ASYNC blob, and afterwards there is no runtime cost. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251112233030.24117-4-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-11-28drm/i915: Expose the IN_FORMATS_ASYNC blob for all planesVille Syrjälä2-0/+4
Since old kernel versions wouldn't expose the IN_FORMATS_ASYNC blob, userspace can't really use the absence of the blob to determine that async flips aren't supported. Thus it seems better to always expose the blob on all planes, whether they support async flips or not. The blob will simply not indicate any format+modifier combinations as supported on planes that aren't async flip capable. Currently we expose the blob for all skl+ universal planes (even though we implement async flips only for the first plane on each pipe), and i9xx primary planes (for ilk+ we have async flips support, for pre-ilk we do not). Complete the full set by also expsosing the blob on pre-skl sprite planes, and cursors. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251112233030.24117-3-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-11-28drm/i915/panic: Clean up the variablesVille Syrjälä3-33/+29
Use the standard variable names for things, and get rid of any annoying aliasing variables. And sprinkle the consts in while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915/panic: Get the crtc from the correct placeVille Syrjälä1-1/+2
Use hw.crtc as opposed to uapi.crtc in the panic code. I suspect this stuff doesn't handle joiner correctly in other ways either but can't be bothered to dig deeper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915: Use hw.active instead of uapi.active in the initial plane readoutVille Syrjälä2-4/+8
We're interested in the actual hardware state rather than the uapi state, so grab the crtc active flag from the correct spot. In practice the two will be identical here becase .get_initial_plane_config() will reject the initial FB when joiner is active. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915/psr: Use hw.rotation instead of uapi.rotationVille Syrjälä1-1/+1
Presumably we're tryign to check if the hw plane is actually rotated or not, so grab that information from the correct plane (hw.rotation). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915/psr: Use hw.crtc instead of uapi.crtcVille Syrjälä1-3/+3
uapi.crtc is not set for joiner secondary pipes, so generally should not be used anywhere after the initial state copy. Switch to hw.crtc which actually indicates that the plane is enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915: Use the proper (hw.crtc) for the cursor unpin vblank workerVille Syrjälä2-3/+3
uapi.crtc is NULL for joiner secondary pipes, so using that is nonsense in most places. Switch to hw.crtc so that we use the deferred cursor unpin also on joiner secondary pipes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit