summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
6 daysdrm/xe/guc: Fix race around q->guc->suspend_pending accessJagmeet Randhawa
q->guc->suspend_pending is accessed without any common lock. __suspend_fence_signal(), called from guc_exec_queue_kill() and the suspend-timeout ban path, clears the flag asynchronously. Meanwhile handle_sched_done(), guc_exec_queue_stop() and __guc_exec_queue_process_msg_suspend() check the flag and then call suspend_fence_signal(), which asserts that it is still set. As the check and suspend_fence_signal() are not atomic, the clear can land in between and trip the xe_gt_assert(q->guc->suspend_pending). Rather than serializing those clears, drop them. Signalling the suspend fence from kill or from the suspend-timeout ban completes a suspend while the queue may still be executing on the hardware, so neither is a valid place to do it. Split the wake up out of __suspend_fence_signal() into suspend_wait_wake() and use that in guc_exec_queue_kill(), so a waiter still observes the killed state immediately rather than waiting out the full timeout - guc_exec_queue_wait_suspend_done() already breaks on exec_queue_killed(). The suspend-timeout ban needs no wake at all, as the waiter that timed out is its caller. suspend_pending now stays set on a killed or banned queue until it is torn down, so relax the !suspend_pending assert in __guc_exec_queue_resume() to permit that state. handle_sched_done() and guc_exec_queue_stop() can still race with each other, so take the per-queue msg_lock, which already covers the set on the suspend path, across their check-then-act. In handle_sched_done() the flag is snapshotted under the lock and deregister_exec_queue() is kept outside it. __guc_exec_queue_process_msg_suspend() is left unlocked: it runs on the scheduler message worker, which guc_exec_queue_stop() parks via xe_sched_submission_stop() before touching the flag. v2: Document that sched->msg_lock also protects guc->suspend_pending, which indicates a suspend message is in flight, in addition to the sched->msgs list (Niranjana) v3: Drop __suspend_fence_signal() from guc_exec_queue_kill() and guc_exec_queue_suspend_timeout_ban() rather than serializing them with msg_lock, keeping only the wake up in kill and guarding the !suspend_pending assert in resume (Matthew, Niranjana) Signed-off-by: Jagmeet Randhawa <jagmeet.randhawa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260902201222.30022-1-jagmeet.randhawa@intel.com Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Unwrap sync fences before adding them as job dependenciesChen, Junjia
A timeline syncobj point is a dma_fence_chain node that carries its own fence context, separate from the contexts of the fences it wraps. xe_sync_entry_add_deps() passed that container straight to drm_sched_job_add_dependency(). drm_sched_entity_add_dependency_cb() only drops a dependency when the fence context is one of the entity's own (fence_context or fence_context + 1). A chain node never matches, so a wait on a point whose inner fence is the finished fence of an earlier job on the same exec queue is treated like a cross-queue dependency: the job is held until the previous job has completed on the GPU. Every job queued behind it waits too, and the ring drains before the next batch of jobs is released. Unwrap the fence with dma_fence_unwrap_for_each() and add each unsignaled underlying fence as a dependency, so drm_sched sees the real fence contexts and ignores same-entity fences. Dependencies on other exec queues still wait for completion. drm_sched_job_add_dependency() keeps only the latest fence per context, so the dependency array does not grow with the length of the chain. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Chen, Junjia <junjia.chen@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/intel-xe/20261028161358.1917359-1-junjia.chen@intel.com/ (cherry picked from commit 3b8860fe2581a8db796150728687ba1c6b78ddab) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/svm: Preserve default PAT index when resetting VMA attributesArvind Yadav
xe_vma_set_default_attributes() replaces the VMA attributes with a default structure. It sets pat_index to the saved default PAT index, but leaves default_pat_index zero. When the saved default is non-zero, the two fields no longer match. xe_vma_has_default_mem_attrs() then reports that the reset VMA has non-default attributes, triggering a warning in xe_vm_alloc_vma() during SVM garbage collection. A later reset also uses the incorrect zero value. Preserve default_pat_index when restoring the default attributes. Fixes: 4a938d3886d6 ("drm/xe: Merge adjacent default-attribute VMAs during garbage collection") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20261027085952.2882874-1-arvind.yadav@intel.com (cherry picked from commit ce155027427a0c76be173f19f911b414d9d686bc) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/xe_late_bind_fw: Fix firmware leak on missing manifest entryBadal Nilawar
Release firmware when the "LTES" manifest entry is not found in the firmware header. Fixes: efa29317a553 ("drm/xe/xe_late_bind_fw: Extract and print version info") Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20261102172527.2794537-9-badal.nilawar@intel.com Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> (cherry picked from commit 3e4b2a6349ed7258057fa95a1e58730615703dae) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Access GT MMIO after pcode initVinay Belgaumkar
Allow pcode initialization to complete before we start poking around the GT MMIO space during resume as these accesses go through sgunit. We do write to MMIO registers in xe_wa_apply_tile_workarounds(), but those are in uncore space. Those accesses remain viable even during d3cold suspend. v2: Clarify about xe_wa_apply_tile_workarounds (Karthik Poosa) v3: Add fixes tag (Anshuman) Fixes: 95d0883ac810 ("drm/xe: Ensure GT is in C0 during resumes") Cc: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Karthik Poosa <karthik.poosa@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patch.msgid.link/20261027174351.619929-7-vinay.belgaumkar@intel.com (cherry picked from commit 638d116d755ed89628ad07bde33ae7d7658db834) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Toggle the D3Cold enable flag at runtime resumeVinay Belgaumkar
We enable this flag during runtime suspend, need to set it back to false early during resume to maintain consistency in pci driver's internal state. d3cold_toggle() updates the root port's ability to go into d3cold via the dev->no_d3cold flag. With this patch, we are ensuring this internal state remains consistent with that of the endpoint. v2: Clarify the commit message (Matt Auld) v3: Add fixes (Karthik Poosa) Fixes: f026520367be ("drm/xe: Only set PCI d3cold_allowed when we are really allowing.") Cc: Matthew Auld <matthew.auld@intel.com> Acked-by: Karthik Poosa <karthik.poosa@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Karthik Poosa <karthik.poosa@intel.com> Link: https://patch.msgid.link/20261027174351.619929-6-vinay.belgaumkar@intel.com (cherry picked from commit e994e0f1ba52e4be3607ba7f952a8d835f1f6563) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Rebind BOs evicted before the first LR queueArvind Yadav
A VM bind can evict BOs before the first LR exec queue is added. There is no preempt fence to trigger at that point. When the queue is added later, its new preempt fence is not triggered. The exec IOCTL does not validate or rebind BOs in preempt fence mode, and the rebind worker skips that work because no preempt fence is waiting. The first exec can then use stale mappings. Trigger the new preempt fence in xe_vm_add_compute_exec_queue() when the VM has evicted BOs or pending rebinds. This keeps the queue suspended until the rebind worker validates the BOs and restores their mappings. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patch.msgid.link/20261015162639.3528278-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 928ee5d4fb1f211aa361524801c15b54603fae52) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/amc: Guard xe_amc_work() with runtime PMRaag Jadav
xe_device_declare_wedged() callers are expected to hold a runtime PM reference. Fix it. Fixes: f43fa4b8522b ("drm/xe/i2c: Fix the interrupt handling") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20261022051303.282805-8-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 5fb4aefb5f4baaa1cbec6c4cee0f91925b33f310) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/pci_error: Flush GT wedge worker before bus resetRaag Jadav
With GT wedging now done async, make sure the wedge worker is flushed to avoid side-effects during PCI bus reset. Fixes: 13b9555ffb03 ("drm/xe/xe_pci_error: Implement PCI error recovery callbacks") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261022051303.282805-7-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 0dbc1d0762bc89649aeaea98a63f6e5f786ea1b8) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Make xe_device_declare_wedged() IRQ safeRaag Jadav
Currently, xe_device_declare_wedged() implementation wedges the GTs and sends wedged uevent to userspace. This is problematic for usecases which require declaring the device as wedged in IRQ context, as it allocates memory for event buffer and acquires mutexes deep into its call path. Fix this by deferring wedge handling into its dedicated worker, so that xe_device_declare_wedged() can be called in IRQ context. First user of this requirement is introduced in commit def675cf3f10 ("drm/xe/mert: Improve handling of MERT CAT errors"), which declares the device as wedged on catastrophic errors received in form of an IRQ. Fixes: def675cf3f10 ("drm/xe/mert: Improve handling of MERT CAT errors") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261022051303.282805-6-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 49c00ef335741eb3c6ce21e49eb988a17cf2e62a) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Move xe_device_wedged_fini() registration to xe_device_probe_early()Raag Jadav
The device can be declared wedged while processing boot-time hardware errors, which can result in PM reference leak if driver probe fails before xe_device_wedged_fini() is registered. Early register the required cleanup action and fix this. Fixes: a7df563b45b0 ("drm/xe/xe_hw_error: Handle CSC Firmware reported Hardware errors") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261022051303.282805-5-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 6599a0eb0990cde96c4e66a4e1e2ae1b172e85d2) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/hw_error: Guard csc_hw_error_work() with runtime PMRaag Jadav
xe_device_declare_wedged() callers are expected to hold a runtime PM reference. Fix it. Fixes: a7df563b45b0 ("drm/xe/xe_hw_error: Handle CSC Firmware reported Hardware errors") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20261022051303.282805-4-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit fc8d229d76102489b6f56538a818c285a87db1e9) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Drop xe_device_set_wedged_method()Raag Jadav
Commit 60439ac3f235 ("drm/xe: Add a helper function to set recovery method") introduced xe_device_set_wedged_method() helper to allow setting preferred recovery method before wedging the device, but also introduced a flaw where the previously set method can be overwritten by concurrent racing wedge call. This can result in unintended recovery method being sent to userspace and possibly failed recovery. Drop xe_device_set_wedged_method() entirely and pass the recovery method as part of xe_device_declare_wedged() argument, which places the preferred recovery method on the stack and avoids this issue. Fixes: 60439ac3f235 ("drm/xe: Add a helper function to set recovery method") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261022051303.282805-3-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 972234baa32845afe458fc547434c250035b5466) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/gt: Use GT ordered workqueue for wedgingRaag Jadav
Currently, xe_gt_declare_wedged() stops GuC CT and initiates exec queue teardown synchronously. This can result in tdr timeout in cases where the device is declared wedged while jobs are still in-flight. Introduce a worker for GT specific wedge handling and queue the teardown on GT ordered workqueue, so we don't disrupt the scheduler while jobs are still in-flight. While at it, introduce for_each_initialized_gt() macro and use it for wedging GT. This helps avoid races in case the device is declared wedged in probe sequence before GT is initialized. Fixes: c9474b726b93 ("drm/xe: Wedge the entire device") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20261022051303.282805-2-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 913d394eb2be6536c66995affde44255d1e36493) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/madvise: use already clamped pat_indexMatthew Auld
Pass the nospec-clamped pat_index to check_pat_args_are_sane() instead of the raw args->pat_index.val, and fold into the preceding DRM_XE_MEM_RANGE_ATTR_PAT block. Assisted-by: LLM Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/message/sashiko-outbox-172627%40kernel.org Fixes: 016ccdb674b8 ("drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: <stable@vger.kernel.org> # v7.2+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20261015103415.442931-2-matthew.auld@intel.com (cherry picked from commit 3be1bd59ced603d2e6a6ba9a4fe274308cea9965) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Fix build with DRM_XE=y and CONFIGFS_FS=mRodrigo Vivi
When xe is built-in but configfs is a module, xe_configfs.o is not linked into xe, while IS_ENABLED(CONFIG_CONFIGFS_FS) in xe_configfs.h still exposes the real declarations, leading to undefined references. Use IS_REACHABLE() so this case falls back to the stubs, the same as CONFIGFS_FS=n. Fixes: 16280ded45fb ("drm/xe: Add configfs to enable survivability mode") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202610160935.Qk4ZxBxY-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202610162335.FEwMdGY9-lkp@intel.com/ Suggested-by: Matt Roper <matthew.d.roper@intel.com> Assisted-by: LLM Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20261021194555.2171344-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 30499cbd796117b63be3b59a1781c25ea3f4b27f) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/lrc: Restore CTX_CS_INDIRECT_CTX_OFFSET programming for pre-Xe2Helen Koike
CTX_CS_INDIRECT_CTX_OFFSET default value is not retrieved from the GPU by inhibit+context save mechanism since it is not part of the Engine Context. Thus, at restore, 0x0 is programmed back to the GPU, which is an invalid value according to the PRM. This causes sporadic hangs on Alder Lake when executing test IntelAngleEnd2EndTestCases (error VK_DEVICE_LOST). Fix it by partially reverting commit c9dfd66cb91e ("drm/xe/lrc: Allow INDIRECT_CTX for more engine classes"). Re-add the programming of CTX_CS_INDIRECT_CTX_OFFSET for pre-Xe2 (in theory it should apply to all platforms, but we got an unexpected behaviour on Xe2 that still requires investigation). Fixes: c9dfd66cb91e ("drm/xe/lrc: Allow INDIRECT_CTX for more engine classes") Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Helen Koike <koike@igalia.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20261016214112.1647202-1-koike@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit b99292acb2dce61ce50d37f54a66d84b768b8927) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Mark xe_vma_ops_alloc() noinline for error injectionShuicheng Lin
Since xe_vma_ops_alloc() was reduced to a loop around xe_pt_job_ops_alloc(), the compiler inlines it into all of its callers, including xe_vm_bind_ioctl(). ALLOW_ERROR_INJECTION() only keeps an out-of-line copy of the function alive for the kprobe, so fail_function injection on xe_vma_ops_alloc is armed on a copy that is never called and the bind IOCTL succeeds. This is seen with the nodebug kernel config used in CI, where igt@xe_fault_injection@vm-bind-fail-xe_vma_ops_alloc fails with: Failed assertion: simple_vm_bind(fd, vm) != 0 Mark xe_vma_ops_alloc() noinline so callers go through the injectable function. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/9432 Fixes: 0e33330f1238 ("drm/xe: Add struct xe_pt_job_ops") Cc: Matthew Brost <matthew.brost@intel.com> Assisted-by: LLM Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20261007222426.1350374-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit 26f7daea5b0667a0af06c60dc204e7cf4856182c) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Don't abort the shrinker walk on -EBUSYThomas Hellström
xe_bo_shrink() returns -EBUSY for bos that can't currently be shrunk, for example imported dma-bufs, bos whose vm is currently validating, bos that are still busy after the wait timeout, or bos whose backup fails. The shrinker LRU walk treats any negative return value as fatal and aborts, which also skips the remaining shrinker passes. As a result, a single such bo, like an imported dma-buf on the XE_PL_TT LRU, prevents reclaim of all bos behind it on the LRU. Skip bos for which xe_bo_shrink() returns -EBUSY and continue the walk, like the TTM LRU walk does. v4: - Patch introduced. Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.15+ Assisted-by: LLM Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20261019095655.3501-2-thomas.hellstrom@linux.intel.com (cherry picked from commit 846f333b3e0b48065f96bee74ffa0b9d390ed05f) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/gsc: Fix NVL-S GSC compatibility numberDaniele Ceraolo Spurio
The compatibility number for the published GSC number is 1.0. The binary is correctly named nvl_gsc_1.bin (matching the major compatibility version number), but the driver is instead looking for compatibility 0.0 (which maps to nvl_gsc_0.bin), leading to the binary not being found. The driver supports running without GSC so this is not fatal, but all content protection features will not work without the GSC FW. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Fixes: 8a90f0d1098f ("drm/xe/gsc: Define GSC for NVL-S") Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Julia Filipchuk <julia.filipchuk@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patch.msgid.link/20261015204548.147348-1-daniele.ceraolospurio@intel.com (cherry picked from commit 11f8678d6a702ab9d6abb2f50c45e82a56974068) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/tuning: Restrict Anyhit NULL-query tuning to render enginesNitin Gote
The "Disable NULL query for Anyhit Shader" tuning uses xe_rtp_match_first_render_or_compute to program RT_CTRL once per GT. On a GT with no render (RCS) engine, that match falls back to a compute (CCS) engine instead, so the tuning is still written even though RT_CTRL's ray-tracing logic has no hardware behind it there. A CRI compute-only GT hits exactly this path, causing igt@xe_debugfs@check-gt-reg-sr to report a save-restore mismatch: Mismatch on 0xe530, expected 0x400 got 0x0 Restrict the rule to ENGINE_CLASS(RENDER) so it only applies where ray-tracing hardware is actually present. Every other in-tree platform in this version range (BMG, LNL, PTL, NVL) always has a render engine, which xe_rtp_match_first_render_or_compute already resolves ahead of any compute engine, so this is a no-op for them. Assisted-by: LLM Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Fixes: 8d8431298f69 ("drm/xe/xe3: Disable null query for anyhit shader") Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20261012171901.19508-6-nitin.r.gote@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 65e2e108e466a2def170797a6d1b4b7849cec3a1) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/hwmon: Handle unavailable memory controller sensorsKarthik Poosa
Skip memory controller sensors that report invalid readings when computing the average temperature in get_mc_temp(). Return -ENXIO when no valid sensor data is available, and allow the helper to be used as an availability probe by making the output parameter optional. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Fixes: 3a0cb885e111 ("drm/xe/hwmon: Expose memory controller temperature") Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261015071434.1063785-6-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 99ceaebb888944d00932063a649ebb41bd8af1d2) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/hwmon: Add helpers to validate thermal sensor readingsKarthik Poosa
Add mmio_temp_valid() and mbx_temp_valid() to check whether a temperature sensor reading is valid. An MMIO value of 0xFFFFFFFF or a mailbox value of 0xFF indicates the sensor is unavailable. Gate these checks behind has_temp_sentinel, enabled on CRI currently. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261015071434.1063785-5-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/hwmon: Fix thermal sensor data handlingKarthik Poosa
Read all required thermal groups in get_mc_temp() and store them in a dword-aligned buffer, avoiding unaligned pcode accesses and ensuring correct memory controller temperature reporting. Store the pcode thermal data and thermal limit words as little-endian, so their per-byte views match the hardware layout on big-endian hosts. Fixes: 3a0cb885e111 ("drm/xe/hwmon: Expose memory controller temperature") Fixes: c332fba805d6 ("drm/xe/hwmon: Expose temperature limits") Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261015071434.1063785-4-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit ca6e33701de8676118f1d039e0c00839d7de13c6) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/hwmon: Decode mailbox temperature as sign-magnitudeKarthik Poosa
The mailbox temperature is an 8-bit sign-magnitude value (bit 7 sign, bits 6:0 magnitude, range -127..127), not two's-complement. Casting the raw byte to s8 decodes negative readings incorrectly. Add mbx_temp_decode(), store the raw byte as u8, and use it in get_mc_temp() and get_pcie_temp() so temperatures are decoded correctly. Fixes: 3a0cb885e111 ("drm/xe/hwmon: Expose memory controller temperature") Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261015071434.1063785-3-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 1bbbd7d98fa588d5ace3d79ce56d8928f18768f5) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/hwmon: Fix pcode power limit handlingKarthik Poosa
Return early on pcode read failure in xe_hwmon_pcode_rmw_power_limit() and propagate errors to callers. Replace boot_power_limit_read with per-channel read_power_limit_from_pcode[], set on the first successful pcode write, so reads and writes stay consistent even if the default limit write at boot fails. Also return PWR_LIM_EN for power label so card label visibility works. v2: Move default power limit writes to helper xe_hwmon_pcode_set_default_power_limits(). Fixes: 8aa7306631f0 ("drm/xe/hwmon: Fix xe_hwmon_power_max_write") Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20261015071434.1063785-2-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit c5b502e43f7cd6456663d5bae495551646a5e125) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/gt: Disable GT reset worker before engine teardownSatyanarayana K V P
During tear-down process, a reset queued from Guc timeout handler can still access hwe after hwe is freed. Register a separate devm action that disables and drains the reset worker, so it runs before any engine is torn down. Fixes: 09c452d1171f ("drm/xe/gt: Synchronize GT reset with device unbind") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Assisted-by: LLM Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20261013152417.3189567-8-satyanarayana.k.v.p@intel.com (cherry picked from commit 861590f69994e41c9ef1b65db8e9ba433f1d1c1c) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/guc: Protect timeout handling from device unplugSatyanarayana K V P
The GuC scheduler timeout callback accesses device and GT state while handling a timed-out job. Guard the callback with drm_dev_enter() and drm_dev_exit() so device unplug waits for in-flight timeout handling. If unplug has already started, mark the job with -ENODEV and return it to the scheduler for cleanup. Fixes: 6eb2aad402cc ("drm/xe: Move hw_engine_fini to devm managed") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Assisted-by: LLM Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20261013152417.3189567-7-satyanarayana.k.v.p@intel.com (cherry picked from commit 3e9a95f3df5b0f9de163c5ee4e4e287750ef9655) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Prevent VF memory IRQ from accessing a torn-down engineSatyanarayana K V P
The VF memory IRQ handler iterates over HW engines whose names are set. Engine teardown clears hwe->gt but leaves hwe->name set, so the handler can select an engine whose GT has already been invalidated. This can cause a NULL pointer dereference in xe_hw_engine_handle_irq(). Invalidate the engine name during teardown so subsequent engine scans skip it. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Fixes: 6eb2aad402cc ("drm/xe: Move hw_engine_fini to devm managed") Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20261013152417.3189567-6-satyanarayana.k.v.p@intel.com (cherry picked from commit f88c6f2fa88bc5892b1e842972096613086c06b2) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/pat: Return error from xe_pat_init_early() on unknown platformDnyaneshwar Bhadane
xe_pat_init_early() currently only logs an error when the platform's graphics version doesn't match any known PAT table, but continues probing with an uninitialized pat.ops. This can lead to a NULL pointer dereference later when pat.ops is used. Change xe_pat_init_early() to return an int and propagate -ENODATA to xe_device_probe() so the driver fails to load cleanly instead of continuing in a broken state. Fixes: 152d7f2db978 ("drm/xe/pat: Handle unicast vs MCR PAT registers") Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Link: https://patch.msgid.link/20261012122522.2307625-8-dnyaneshwar.bhadane@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit e952337c3dbccf600ddae3bb1d38e996172ac8f8) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe/ras: Fix sysctrl and drm-ras discrepancyRaag Jadav
There are cases where a reported error is valid for sysctrl but it's not exposed as a valid uapi through drm-ras. We allow such error to be logged but it's redundant to try to send an error-event for it. Early return such cases and prevent misleading drm-ras error-event failures. Fixes: 6a9493e47075 ("drm/xe/xe_ras: Report correctable/uncorrectable error events to userspace") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20261012101712.125146-1-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 505f803cfdea3a5f75d5f3b049a39024f966280f) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Keep VRAM fault injection within the usable rangeTejas Upadhyay
xe_ttm_vram_inject_fault() picked its starting address from vr->actual_physical_size, which includes the CCS/GSM/DSM infrastructure zone beyond vr->usable_size. The buddy allocator (vram_mgr->mm) only manages usable_size, so the first probed address can land in that infra zone; xe_ttm_vram_addr_to_region() then returns NULL for it and xe_ttm_vram_handle_addr_fault() requests an SBR instead of exercising page offlining. Start the probe at usable_size - PAGE_SIZE and stay within usable_size so the injected fault always lands on real, buddy-managed VRAM. Fixes: 6ef3eb10aea4 ("drm/xe: Add fault-inject based VRAM page offline injection") Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20261006124125.1560295-10-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit ea5b438eff857e92cb0eace759f969cb7a436326) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Drop RCU list handling for VRAM bad-page tracking, use mgr->lockTejas Upadhyay
queued_pages and offlined_pages were mutated with list_add_rcu()/ list_del_rcu()/kfree_rcu(), but the only lockless consumer was the vram_bad_pages debugfs show function. Every other reader and writer already runs under mgr->lock, so the RCU protection bought nothing but complexity and a rcu_head field on every tracked entry. Convert all list operations to plain list_add()/list_del()/kfree(), including the retry helper added by the ghost-ownership fix, and have vram_bad_pages_show() take mgr->lock instead of rcu_read_lock() so list traversal is always serialized against mutation. Fixes: 7737f819e9f1 ("drm/xe/vram: Add VRAM page offline fault handler") Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20261006124125.1560295-9-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit ef5c65f507d248dd39e147a35844dcac9e94f0ac) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysdrm/xe: Re-validate external pin under resv lock before VRAM purgeTejas Upadhyay
xe_ttm_vram_reserve_page_at_addr() checks xe_bo_is_user() && xe_bo_is_pinned() while holding only mgr->lock, not the BO's reservation lock, since it must run before the owning BO is even known to be purgeable. A user BO can become pinned after that check passes but before xe_ttm_vram_purge_page() runs. xe_ttm_vram_purge_page() takes the reservation lock but only rechecks xe_bo_is_pinned(), not xe_bo_is_user(). If the race is hit, it calls xe_bo_unpin() (the kernel-BO unpin path, not xe_bo_unpin_external())on an externally pinned BO and then purges its backing store while userspace/hardware still expects it to be resident. Recheck xe_bo_is_user() && xe_bo_is_pinned() under the reservation lock and reject the purge, requesting SBR with -EIO the same way the caller's own critical-BO check already does. Fixes: 7737f819e9f1 ("drm/xe/vram: Add VRAM page offline fault handler") Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20261006124125.1560295-8-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 5da52b08381a35c03ad443265dcec091ab26eeb7) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
6 daysMerge tag 'devm_kmalloc_obj-v7.4-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull devm_kmalloc_obj conversion from Kees Cook: - treewide refresh of kmalloc_obj() conversions - devm_kmalloc_obj conversion rules added to Coccinelle scripting - treewide conversion of devm_kmalloc() family to devm_kmalloc_obj() * tag 'devm_kmalloc_obj-v7.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: Convert devm_kmalloc() family to the devm_kmalloc_obj() family coccinelle: kmalloc_obj: Include devm_kmalloc_obj conversion rules treewide: refresh kmalloc_obj() conversions
7 daysMerge tag 'drm-fixes-2026-11-07' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "This is the weekly drm fixes, amdgpu leading the way with some i915, nouveau and other fixes. There should be a bunch of xe fixes, but their tree got screwed up so I guess I'll send those next week once they cleanup whatever happened. atomic: - Fix CRTC dma-fence handling drm: - Add parsing for additional HDMI 2.2 FRL rates bridge: - nwl-dsi: Fix LCDIF handling dma-buf: - Fix IOVA offset - Restore the scatter-list entry count before freeing dp: - Keep MOT set between messages when no_zero_sized is set panel: - visionox-r66451: Set brightness MSB first; Increase reset waiting time panic: - Fix display loop - Fix line parsing sched: - Fix out of bounds entity priority check - Adjust run-queue when changing priority at runtime amdgpu: - UALink fixes - RAS fixes - GEM_OP fix - Parse IB fixes - CS user fence fix - GPU reset fixes - Multi-media idle work handler cleanup fixes - UserQ fixes - CRC fix - SR-IOV fixes - IP discovery fix - HDMI 2.2 FRL fixes - DDC pin fix - HUBP fix - SPM fix - DCN 3.2 fixes - VRR/freesync fix - Seamless boot fix - SMU 13.0.7 fix - Backlight fix - dma-buf fixes - GPUVM fixes - Move DMCUB back to VRAM - Non-DC audio fix - BACO fix amdkfd: - Fix WPTR BO eviction fence handling - GPUVM locking fix i915: - Fix GitLab #8991 where tiled displays (LG UltraFine 5K) broken on PTL - Limit NVL TRANS_VTOTAL.Vtotal skip display workaround to A-step - Single scaler per pipe number to 1 and disable pipe joiner on WCL - Add quirk to force backlight type on some TUXEDO devices - Fix "CMTG: A disable timeout" splat - Fix intel_vrr_dcb_vmin_vblank_start - Bunch of PSR fixes - Static checker fixes etnaviv: - Fix NULL dereference in etnaviv_unbind() - Flush the tile status cache through both the PE and BLT imagination: - Align rogue_fwif_hwrtdata to 64 bytes loongson: - Fix BO handling in several places nouveau: - Map Kepler video engine contexts non-privileged - Clear use.enabled when subdev init fails - Avoid running VBIOS twice - Fix CE channel creation on pre-Kepler GPUs v3d: - Initialize job timedout_batches - Fix cache_clean_lock vc4: - Move output fence and BO unreserve out of job_lock - Power down PYH when output is disabled - hdmi: Fix scrambling" * tag 'drm-fixes-2026-11-07' of https://gitlab.freedesktop.org/drm/kernel: (91 commits) drm/sched: Adjust run-queue when changing priority at runtime drm/sched: Fix out of bounds entity priority check drm/etnaviv: Flush the tile status cache through both the PE and BLT drm/etnaviv: Fix NULL dereference on unbind without PPU flop reset drm/nouveau: Fix CE channel creation on pre-Kepler GPUs drm/nouveau/devinit/gf100-: try to avoid double-running vbios scripts drm/dp: keep MOT set between messages when no_zero_sized is set drm/nouveau/nvkm: clear use.enabled when subdev init fails drm/nouveau/fifo: map Kepler video engine contexts non-privileged drm/amdgpu: don't drop the gang dependency fence twice drm/amdgpu: stop GPU recovery wait for the JPEG/VCN idle work drm/amd/pm: track BACO state in the SMU v11 ArmD3 sequence drm/amdgpu: Only enable HDMI audio if display supports it Revert "drm/amd/display: Allocate DCN32/1 dmub memory to GTT" drm/amdgpu: don't walk the CS chunks when allocating them failed drm/amdgpu/vce: don't allocate a scheduler fence in the direct IB test drm/amdgpu: rewrite all PTEs of the BOs after a VM reset drm/amdgpu: unlock the VM and BO when attaching a KFD BO fails drm/amdgpu: drop the dma-buf reference when a KFD import fails drm/amdgpu: Clamp the ATIF backlight curve to its 99 points ...
9 daysiommu/amd: Enable PerfOpt automatically for integrated GPUsMario Limonciello (AMD)
PerfOpt is usable by integrated GPUs in identity mode. Enable it from the IOMMU driver's domain attachment paths instead of requiring an amdgpu policy knob and exported enable/disable interfaces. Mark supported integrated GPUs as PerfOpt-eligible when selecting their default identity domain. Skip GCR3 setup and ATS/PRI/PASID enablement for these identity attachments, then enable PerfOpt after installing the DTE. Clear PerfOpt before attaching an eligible GPU to a translated or blocked domain, including unmanaged domains used by VFIO. Propagate failures to clear bypass, but keep a completed identity attachment successful if the optional PerfOpt enable fails. Clear inherited PerfOpt state during initialization, including when a crash kernel reuses device tables. Read feature support directly from hardware because cached features may not be available yet, and stop initialization if the initial clear fails. Each IOMMU has at most one PerfOpt-eligible GPU, so track activation with a boolean under the IOMMU lock. Preserve this state while clearing hardware at suspend and shutdown, and restore the bit on resume only where it was active. Do not enable PerfOpt unconditionally during early IOMMU initialization. Remove the amdgpu parameter, driver callbacks, and exported interfaces. Translated attachments retain their normal device capability setup. Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
9 daystreewide: Convert devm_kmalloc() family to the devm_kmalloc_obj() familyKees Cook
Mirroring the earlier kmalloc_obj() conversion, convert the device-managed allocators over to the type-based API using the now updated scripts/coccinelle/api/kmalloc_objs.cocci. The size is derived from the type rather than written out as a sizeof(), and the result is a pointer to that type rather than void *, so a mismatch between the size requested and the variable assigned becomes a build error instead of being silently accepted. The conversions break down as: 6713 devm_kzalloc_obj() 1749 devm_kzalloc_objs() 307 devm_kzalloc_flex() 91 devm_kmalloc_objs() 82 devm_kmalloc_obj() 2 devm_kmalloc_flex() The rules deliberately leave alone allocations sized by a string or a byte-sized type, or assigned to a pointer to a byte-sized type, since those are byte buffers rather than objects. Allocations sized by a multi-byte integer type are only converted when they are assigned to a pointer to that same type, and allocations of pointers to integers or of void pointers are left alone too. After this change, 528 files still call devm_kmalloc(), devm_kzalloc(), devm_kcalloc(), or devm_kmalloc_array(). Build tested with allmodconfig on x86_64, arm64, i386, arm, riscv, s390, m68k, mips, parisc, sparc, loongarch, arc, xtensa, and openrisc with GCC 16.2.0 with no new warnings. Signed-off-by: Kees Cook <kees+treewide@kernel.org>
9 daystreewide: refresh kmalloc_obj() conversionsKees Cook
Refresh the tree with run of the existing Coccinelle rules in scripts/coccinelle/api/kmalloc_objs.cocci, now that they also convert arrays of multi-byte integers. The conversions break down as: 435 kzalloc_objs() 169 kmalloc_objs() 52 kvzalloc_objs() 47 kzalloc_obj() 42 kvmalloc_objs() 8 kmalloc_obj() 2 kzalloc_flex() 2 kvmalloc_flex() and 37 existing kmalloc_obj() family calls drop a redundant GFP_KERNEL. Build tested with allmodconfig on x86_64 with GCC 16.2.0, and, together with the devm_kmalloc_obj() conversion that follows, on x86_64, arm64, i386, arm, riscv, s390, m68k, mips, parisc, sparc, loongarch, arc, xtensa, and openrisc with GCC 16.2.0 with no new warnings. Signed-off-by: Kees Cook <kees+treewide@kernel.org>
9 daysMerge tag 'amd-drm-fixes-7.4-2026-11-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.4-2026-11-05: amdgpu: - UALink fixes - RAS fixes - GEM_OP fix - Parse IB fixes - CS user fence fix - GPU reset fixes - Multi-media idle work handler cleanup fixes - UserQ fixes - CRC fix - SR-IOV fixes - IP discovery fix - HDMI 2.2 FRL fixes - DDC pin fix - HUBP fix - SPM fix - DCN 3.2 fixes - VRR/freesync fix - Seamless boot fix - SMU 13.0.7 fix - Backlight fix - dma-buf fixes - GPUVM fixes - Move DMCUB back to VRAM - Non-DC audio fix - BACO fix amdkfd: - Fix WPTR BO eviction fence handling - GPUVM locking fix drm: - Add parsing for additional HDMI 2.2 FRL rates Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20261105212000.2846044-1-alexander.deucher@amd.com
9 daysMerge tag 'drm-misc-fixes-2026-11-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: atomic: - Fix CRTC dma-fence handling bridge: - nwl-dsi: Fix LCDIF handling dma-buf: - Fix IOVA offset - Restore the scatter-list entry count before freeing dp: - Keep MOT set between messages when no_zero_sized is set etnaviv: - Fix NULL dereference in etnaviv_unbind() - Flush the tile status cache through both the PE and BLT imagination: - Align rogue_fwif_hwrtdata to 64 bytes loongson: - Fix BO handling in several places nouveau: - Map Kepler video engine contexts non-privileged - Clear use.enabled when subdev init fails - Avoid running VBIOS twice - Fix CE channel creation on pre-Kepler GPUs panel: - visionox-r66451: Set brightness MSB first; Increase reset waiting time panic: - Fix display loop - Fix line parsing sched: - Fix out of bounds entity priority check - Adjust run-queue when changing priority at runtime v3d: - Initialize job timedout_batches - Fix cache_clean_lock vc4: - Move output fence and BO unreserve out of job_lock - Power down PYH when output is disabled - hdmi: Fix scrambling Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20261105143915.GA896462@linux.fritz.box
10 daysdrm/sched: Adjust run-queue when changing priority at runtimeTvrtko Ursulin
Another consequence of the recent revert of commit 77a6809f1dc3 ("drm/sched: Remove FIFO and RR and simplify to a single run queue") is that after the revert we need to adjust entity->rq_priority when runtime priority changes are requested. Only amdgpu does that so the impact is minimal. Also considering dynamic priority changes are largely broken there, due currently broken entity scheduler list handling where the special case of a single scheduler can never change it's run-queue. And coupled with the fact for the rest a two- tier approach of drm_sched_entity_set_priority() and drm_sched_entity_modify_sched() is used, where later directly maps to different hardware queue priority by replacing the set of schedulers completely. Hence the regression is limited to rings which have multiple instances other than compute and graphics, which would be SDMA only, for which I am not sure any userspace actually does dynamic priority changes in the first place. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 2fa4d8e2c109 ("drm/sched: Add fair scheduling policy") Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: stable@vger.kernel.org # v7.2+ [phasta: fix checkpatch error] Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20261021094227.48034-3-tvrtko.ursulin@igalia.com
10 daysdrm/sched: Fix out of bounds entity priority checkTvrtko Ursulin
When the out of range priority at entity init time is clamped to the number of run queues in the supplied scheduler the internal run-queue priority needs to be adjusted as well. There is no impact since none of the drivers hit the clamping path, but we still need to address it by moving the entity->rq_priority assignment to after the clamping is done. Note that a lot of this will hopefully get removed once again when the single run-queue simplification lands. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 2fa4d8e2c109 ("drm/sched: Add fair scheduling policy") Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: stable@vger.kernel.org # v7.2+ Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20261021094227.48034-2-tvrtko.ursulin@igalia.com
10 daysdrm/etnaviv: Flush the tile status cache through both the PE and BLTChristian Gmeiner
Since commit f232d9ec029c ("drm/etnaviv: fix TS cache flushing on GPUs with BLT engine"), jobs on GPUs with a BLT engine use a BLT command to flush the tile status cache instead of TS_FLUSH_CACHE, which is broken on most of these GPUs. GC7000 r6008/r6009 and GC8200 r6401 are the other way around: TS_FLUSH_CACHE works, but the BLT command does not flush the cache. The vendor driver handles these GPUs using TS_FLUSH_CACHE, but the etnaviv kernel driver has no way to identify them. As a result, dirty tile status cache lines survive the end of a job. They are written back by the next cache flush, using the page table of the job issuing it. If that job belongs to another process, the write goes to the wrong address space. On GC7000 r6009 this causes MMU faults and GPU recoveries blamed on an innocent process. I see around 1100 per run of a multisample depth/stencil test running alongside two other GPU clients. Emit both flushes at the end of every job on GPUs with a BLT engine. Whichever does not work on a given GPU is a no-op. Since dirty lines are only written back once, this costs one additional state load per job. Fixes: f232d9ec029c ("drm/etnaviv: fix TS cache flushing on GPUs with BLT engine") Cc: stable@vger.kernel.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patch.msgid.link/20261102-etna-pe-ts-flush-v1-1-e4454ed86f85@igalia.com Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
10 daysdrm/etnaviv: Fix NULL dereference on unbind without PPU flop resetChristian Gmeiner
flop_reset_data_ppu is only allocated on GPUs that need the PPU flop reset. However, etnaviv_unbind(..) frees it unconditionally, and etnaviv_cmdbuf_free(..) dereferences cmdbuf->suballoc before checking whether cmdbuf is NULL. As a result, unloading the driver on GPUs that do not need the PPU flop reset causes a NULL pointer dereference at address 0. Fixes: 85ba57ad88cf ("drm/etnaviv: Add PPU flop reset") Cc: stable@vger.kernel.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patch.msgid.link/20261102-etnaviv-unbind-flop-fix-v1-1-588fd16f6768@igalia.com Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
10 daysdrm/nouveau: Fix CE channel creation on pre-Kepler GPUsMunique Feitoza
Commit 04e0481526e3 ("nouveau/dmem: Fix privileged error in copy engine channel") changed nouveau_accel_ce_init() to unconditionally request a privileged channel (priv = true) when calling nouveau_channel_new(). However, privileged channels (func->ramfc->priv) are only supported on Kepler (gk104_chan_ramfc) and newer FIFO implementations. On pre-Kepler GPUs that expose a Copy Engine runlist, func->ramfc->priv is false, which causes nvkm_chan_new_() to reject the channel creation with -EINVAL: nouveau 0000:01:00.0: DRM: failed to create ce channel, -22 Only request a privileged CE channel when device->info.family >= NV_DEVICE_INFO_V0_KEPLER. Fixes: 04e0481526e3 ("nouveau/dmem: Fix privileged error in copy engine channel") Signed-off-by: Munique Feitoza <muniquefeitoz4@gmail.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20261030202809.28723-1-muniquefeitoz4@gmail.com
10 daysdrm/nouveau/devinit/gf100-: try to avoid double-running vbios scriptsIlia Mirkin
Turns out some VBIOSes don't actually set the bit in question in 2240c. Use the nv50-style detection to try avoiding running the vbios twice. Fixes: a6a0f67ca7aa ("drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit") Link: https://bugs.freedesktop.org/show_bug.cgi?id=97620 Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20170128205347.17453-1-imirkin@alum.mit.edu
10 daysdrm/dp: keep MOT set between messages when no_zero_sized is setFinn Zeruhn
When aux->no_zero_sized is set, drm_dp_i2c_xfer() cannot use a bare address packet to close the transaction, so it clears MOT on the last data packet instead. The check only looks at the position within the current i2c_msg, so MOT is cleared at the end of every message and each one is terminated by an I2C stop. This breaks E-DDC reads of EDID blocks 2 and up. Those are read as three messages: a write of the segment pointer to 0x30, a write of the offset to 0x50, and the read. The stop after the first message resets the segment pointer, so the read returns segment 0 again. On a Pimax Dream Air (three EDID blocks, native timings in a DisplayID extension in block 2) connected to an RTX 5070 Ti with nouveau, block 2 reads back as a copy of block 0. The checksum is valid, so nothing is reported, and the connector only offers fallback modes. Clear MOT only on the last packet of the last message, as the commit that added the option describes. With this, block 2 reads correctly and the native 7104x3840 modes are listed for the Dream Air. The same problem was pointed out by the Sashiko review of the patch that sets no_zero_sized for all DisplayPort connectors in nouveau. Fixes: f0ddbb1eed18 ("drm/dp: add option to disable zero sized address only transactions.") Link: https://lore.kernel.org/all/20260827015758.0B4FB1F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Finn Zeruhn <fzeruhn@icloud.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20261002212833.9674-1-fzeruhn@icloud.com
10 daysdrm/nouveau/nvkm: clear use.enabled when subdev init failsRosen Penev
On Kepler boards without the video decode falcon firmware installed (msvld/mspdec/msppp), every other VA-API decode attempt binds to an engine with no ucode loaded. The submitted work never completes, which leads to a context switch timeout, a channel recovery that cannot reset the engine, and eviction waits on fences that never signal. The process ends up stuck in D state, or killed by SIGBUS when it touches a buffer evicted after the wait times out: msvld: unable to load firmware data msvld: init failed, -19 fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] vo[5444]: channel 14 killed! WARNING: drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:117 at nvkm_runl_rc+0x2a4/0x3b0 [nouveau] [TTM] Buffer eviction failed WARNING: drivers/gpu/drm/nouveau/nouveau_bo.c:1092 at nouveau_bo_move_ntfy.part.0+0x9b/0x100 [nouveau] Tracing nvkm_subdev_ref() and nvkm_subdev_init_() shows the pattern: a reference taken with enabled=0 runs nvkm_falcon_init(), which returns -ENODEV; the next reference sees enabled=1 and succeeds without running it. Clear use.enabled when init() fails, so that every later reference retries init and fails cleanly. The other readers of use.enabled are fini() handlers that use it to skip teardown, which they now also do after a failed init(). On a GK107 (Quadro K1100M) without video firmware, playing H.264 with mpv --hwdec=auto: without this patch the GPU channel is killed within a minute and mpv hangs; with it, VA-API decoder creation fails, mpv falls back to software decoding, and no faults are logged. Fixes: 8478cd5a740a ("drm/nouveau/nvkm: add locking to subdev/engine init paths") Cc: stable@vger.kernel.org Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20261101200428.16959-1-rosenp@gmail.com
10 daysdrm/nouveau/fifo: map Kepler video engine contexts non-privilegedRosen Penev
Since the engine context rework, gk104_ectx_ctor() maps every engine context into the channel's VMM as a privileged page. The MSVLD, MSPDEC and MSPPP falcons on Kepler fetch their context with non-privileged requests, so the first method sent to any of them faults and the channel is killed: fifo: fault 00 [READ] at 0000000001050000 engine 10 [MSVLD] client 0d [HUB/MSVLD] reason 05 [PRIV_VIOLATION] on channel 9 fifo: fault 00 [READ] at 0000000001051000 engine 14 [MSPDEC] client 0b [HUB/MSPDEC] reason 05 [PRIV_VIOLATION] on channel 10 fifo: fault 00 [READ] at 0000000001052000 engine 11 [MSPPP] client 0c [HUB/MSPPP] reason 05 [PRIV_VIOLATION] on channel 11 Before the rework, gk104_fifo_gpfifo_engine_ctor() mapped engine contexts without the privileged bit. Restore that for the three video engines, and keep the privileged mapping for everything else. Fixes: 8ab849d6dd4c ("drm/nouveau/fifo: add new engine context handling") Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20261103221529.585436-1-rosenp@gmail.com