summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-07-16drm/amdgpu: give different sizes for each SA pool typeChristian König
The IMMEDIATE (page fault) and DIRECT (reset) pool should be used only very rarely and by a single thread. Saves roughly 1.25MiB of memory and GART space for each amdgpu device. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-16drm/amdgpu: properly account for resets with user queuesAlex Deucher
We need to increment the reset counter, force fence completion, and set the wedged event when a user queue is reset, but only for the guilty queue. We don't want additional events for collateral damage. Only increment the reset counter and set the wedged event in the top level userq reset callers (both KGD and KFD). This aligns with how this is managed for kernel queue resets. v2: fix task info refcount handling, align with kfd error reporting. v3: check for has_reset_queue in KFD path (Prike) Cc: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Cc: Prike Liang <Prike.Liang@amd.com> Cc: Sunil Khatri <sunil.khatri@amd.com> Cc: Lazar, Lijo <lijo.lazar@amd.com> Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Prike Liang <Prike.Liang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-16drm/amdgpu/gfx9.4.3: Fix MEC rollback loop in EOP IRQ setupSrinivasan Shanmugam
Fix the error cleanup path in gfx_v9_4_3_set_userq_eop_interrupts() by using the correct loop condition. This ensures all previously enabled EOP IRQs are released if setup fails. Fixes: 832f0aa050ff ("drm/amdgpu/gfx9.4.3: add support for disabling kernel queues") Reported-by: Dan Carpenter <error27@gmail.com> Cc: Kent Russell <kent.russell@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-16drm/amdgpu : update mmhub eco sec lvl for vcn5_3Suresh Guttula
This patch requests PSP to set the sec lvl for vcn and jpeg. Signed-off-by: Suresh Guttula <suresh.guttula@amd.com> Reviewed-by: McRae Geoffrey<Geoffrey.McRae@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-16drm/msm: Only fini scheduler after successful initRuoyu Wang
msm_ringbuffer_new() destroys a partially initialized ring through msm_ringbuffer_destroy() when an allocation or scheduler setup step fails. If drm_sched_init() fails before it finishes initializing the scheduler, the failure path still calls drm_sched_fini(). That teardown path assumes the scheduler work items, lists, and workqueue state were initialized. Track successful scheduler initialization and call drm_sched_fini() only after drm_sched_init() returned 0. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler") Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/738905/ Message-ID: <20260709062309.4168362-1-ruoyuw560@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm: Fix task_struct reference leak in recover_workerJie Zhang
get_pid_task() increments the task reference count, but the corresponding put_task_struct() was missing in the else branch, leaking a reference on every GPU hang recovery. Fixes: 25654a1756a4 ("drm/msm: Update global fault counter when faulty process has already ended") Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/730662/ Message-ID: <20260605-assorted-fixes-june-v1-6-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm/a6xx: Fix IRQ storm during msm_recovery testJie Zhang
Once a hang is triggered by the msm_recovery test, the gpu error irq remains asserted and triggers an interrupt storm. In the worst case, this IRQ storm lands on the CPU core where the hangcheck timer is scheduled, blocking it from running. This eventually leads to CPU watchdog timeouts. To fix this, mask the gpu error irqs during msm_recovery test and enable them back during the recovery. Fixes: 5edf2750d998 ("drm/msm: Add debugfs to disable hw err handling") Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/730660/ Message-ID: <20260605-assorted-fixes-june-v1-5-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm/a6xx: Fix A621 GPUCC register list for state captureJie Zhang
A621 uses an incorrect GPUCC register list during state capture. The existing list matches A623/A663. Rename it accordingly and add a dedicated A621 GPUCC register list. Fixes: 11cdb81b3c1b ("drm/msm/a6xx: Fix gpucc register block for A621") Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/730659/ Message-ID: <20260605-assorted-fixes-june-v1-4-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm/a6xx: Fix A663 GPUCC register list for state captureJie Zhang
The GPUCC register list for A663 is incorrect, which can cause out-of-bounds register access during GPU state capture. Update it to use the correct register ranges. Fixes: 5773cce8615c ("drm/msm/a6xx: Add support for A663") Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/730656/ Message-ID: <20260605-assorted-fixes-june-v1-3-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm: Recover HW before retire hung submitJie Zhang
During recovery, it is not safe to retire the hung submit before we recover the GPU. Retiring the submit triggers BO free and that can result in GPU pagefaults since the GPU may be actively accessing those BOs. To fix this, retire the submits after gpu recovery is complete in recover_worker(). Fixes: 1a370be9ac51 ("drm/msm: restart queued submits after hang") Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/730655/ Message-ID: <20260605-assorted-fixes-june-v1-2-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm/a6xx: Fix stale rpmh votes after suspendShivam Rawat
There are stale RPMH votes (BCM votes) observed after GMU suspend. This is because the rpmh stop sequences are skipped during gmu suspend. Fix this and also move GMU to reset state to avoid any further activity. Fixes: f248d5d5159a ("drm/msm/a6xx: Fix PDC sleep sequence") Signed-off-by: Shivam Rawat <shivrawa@qti.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/730652/ Message-ID: <20260605-assorted-fixes-june-v1-1-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm/a3xx: Drain VBIF before GPU suspendAlexandre MINETTE
A3xx hangs after every runtime suspend on the Samsung Galaxy S4 GT-I9505. Even simple GPU workloads, such as drawing a single triangle, hang reliably once the GPU has been suspended by runtime PM. The generic MSM GPU suspend path disables clocks/power, but A3xx also needs to ensure that pending VBIF transactions are drained before that happens. Add an A3xx-specific pm_suspend callback. Wait for the GPU to become idle, halt all VBIF XIN clients, wait for the corresponding acknowledgment, and only then enter the generic MSM GPU suspend path. This fixes reliable A3xx GPU hangs observed after runtime PM on the Samsung Galaxy S4 GT-I9505, codename jflte. The failure is reported as: mdp4 5100000.display-controller: [drm:hangcheck_handler] *ERROR* 3.2.0.2: hangcheck detected gpu lockup rb 0! mdp4 5100000.display-controller: [drm:hangcheck_handler] *ERROR* 3.2.0.2: completed fence: 4294967041 mdp4 5100000.display-controller: [drm:hangcheck_handler] *ERROR* 3.2.0.2: submitted fence: 4294967049 mdp4 5100000.display-controller: [drm:recover_worker] *ERROR* 3.2.0.2: hangcheck recover! Link: https://github.com/freedreno-zz/freedreno/issues/12 Signed-off-by: Alexandre MINETTE <contact@alex-min.fr> Patchwork: https://patchwork.freedesktop.org/patch/731919/ Message-ID: <20260610-mainline-fix-a3xx-gpu-hang-sending-v1-1-9282182840b5@alex-min.fr> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm/adreno: fix use after free on error path in a6xx_gpu_init()Dan Carpenter
The a6xx_destroy() function frees "a6xx_gpu" and so "adreno_gpu" points to freed memory. Preserve the error code before freeing the memory to avoid a use after free. Fixes: d158886cba08 ("drm/msm/adreno: Trust the SSoT UBWC config") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/732275/ Message-ID: <aiqNktNfXiaPhje3@stanley.mountain> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/tegra: vic: Add Tegra264 supportMikko Perttunen
Add support for VIC on Tegra264. The Tegra264 VIC uses a RISC-V based Falcon microcontroller instead of the traditional Falcon previously, and has the TRANSCFG register in a different place. The .version field is set to 0x264 rather than 0x26 to allow distinguishing between different VIC capabilities between minor version variations of some chips. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> [treding@nvidia.com: fix checkpatch warnings] Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260622-t264-host1x-v2-6-ff7364d9ff7b@nvidia.com
2026-07-16drm/tegra: falcon: Add support for RISC-V external bootMikko Perttunen
Add support for loading and booting RISC-V firmwares on Falcons with RISC-V hardware. The flow is mostly the same as for traditional Falcons, with a few different registers and different firmware layout. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260622-t264-host1x-v2-5-ff7364d9ff7b@nvidia.com
2026-07-16gpu: host1x: Add Tegra264 supportSantosh BS
Add device data and chip headers for Tegra264. Signed-off-by: Santosh BS <santoshb@nvidia.com> Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260622-t264-host1x-v2-4-ff7364d9ff7b@nvidia.com
2026-07-16gpu: host1x: Correctly parse linear ranges of context devicesMikko Perttunen
The previous parsing of the iommu-map property assumed each context device has its own one-length entry in the device tree. This has worked fine so far, but on Tegra264 larger numbers of context devices are usable, so it's better to support linear ranges as well. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260622-t264-host1x-v2-3-ff7364d9ff7b@nvidia.com
2026-07-16gpu: host1x: Annotate intentional syncpoint wrap-aroundMikko Perttunen
Host1x syncpoints are 32-bit counters that roll over by design. To make that explicit in the code, use wrapping_* functions whenever arithmetic is done on syncpoint values. Atomic operations cannot be updated but a comment is added. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-6-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Change pin_job() return type to intMikko Perttunen
pin_job() returns negative errno values on error paths (-EINVAL, -ENOMEM, PTR_ERR() of mapping) but was declared as unsigned int. The caller would immediately cast back to int, so there was no functional issue, but it still warrants fixing. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-5-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Avoid stack over-read in debug output helpersMikko Perttunen
host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written. Fixes: 6236451d83a7 ("gpu: host1x: Add debug support") Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-4-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Fix offset calculation in trace_write_gatherMikko Perttunen
When a gather longer than 2*TRACE_MAX_LENGTH (256) words is traced through host1x_cdma_push_gather, the reported BO offset drifts from the third iteration onward. Fix the calculation by properly calculating the value on each loop rather than accumulating. In reality, gathers tend to be pretty short so this is unlikely to ever have been observed. Fixes: b40d02bf96e0 ("gpu: host1x: Use struct host1x_bo pointers in traces") Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-3-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Avoid double device_add when clients already presentMikko Perttunen
host1x_device_add looks through the idle clients list to populate subdevs, and any matches entries are moved from the subdevs list to the active list. If all subdevs are populated, device_add will be called on the device. The secondary "subdevs list empty" check will then incorrectly again call device_add. However, this would require a convoluted scenario since clients don't typically end up on the idle clients list. Fix by checking whether the device was already added before adding again. Fixes: fab823d82ee5 ("gpu: host1x: Allow loading tegra-drm without enabled engines") Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-2-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Wait for timeout worker completion on channel freeMikko Perttunen
cdma_timeout_destroy() used cancel_delayed_work() to cancel pending timeout work when destroying the CDMA. Usually this is fine, but there is a narrow race condition where the timeout handler has started execution but has not taken cdma->lock; the channel is freed causing cdma_stop to take cdma->lock and flush the channel; host1x_cdma_deinit then proceeds with deinitializing cdma while the handler is waiting to take cdma->lock. Therefore change cdma_timeout_destroy to use cancel_delayed_work_sync instead to ensure any pending timeout work completes before proceeding. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-1-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappingsMikko Perttunen
__host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead. Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/linux-tegra/ah6ErK6f4kVudVIA@stanley.mountain/T/#u Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260603-host1x-bocache-leak-fix-v1-1-494101dbfd30@nvidia.com
2026-07-16drm/i915/selftests: Fix GT PM sort comparatorsEmre Cecanpunar
Compare the sampled clock values instead of their addresses. Comparing addresses leaves the samples unsorted, preventing the code from discarding the minimum and maximum samples. Fixes: 1a5392479207 ("drm/i915/selftests: Measure CS_TIMESTAMP") Signed-off-by: Emre Cecanpunar <emreleno@gmail.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260714220430.238433-1-emreleno@gmail.com (cherry picked from commit 682ea2d28d18bb06f9fc663cb5ab7e80dc0e606a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-16drm/i915/wm: clear the plane ddb_y entries on plane disableVinod Govindapillai
The UV/Y plane DDB entriess are never cleared on sk_wm_plane_disable_noatomic() and can leave stale DDB state for NV12 planes on pre-Gen11 devices Fixes: d34b59d5ba41 ("drm/i915: Add skl_wm_plane_disable_noatomic()") Assisted-by: Copilot:claude-sonnet-4.6 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-2-vinod.govindapillai@intel.com (cherry picked from commit 60f68a6ba298fd1e971a2d91576304bee89a16fc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-16drm/xe/pf: Disable display in admin only PF modeSatyanarayana K V P
Admin-only PF mode does not expose media or 3D execution capabilities to userspace, so display pipelines cannot receive rendered content. Fixes: d88c4bac8c2a ("drm/xe/pf: Restrict device query responses in admin-only PF mode") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260714053259.504308-2-satyanarayana.k.v.p@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 7ef55ae582eba2b0a7a7441bd3b9aefd38a26bb9) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe/guc: Hold device ref until queue teardown completesArvind Yadav
GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. Fixes: 2d2be279f1ca ("drm/xe: fix UAF around queue destruction") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patch.msgid.link/20260716062624.211396-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe/guc: Keep scheduler timeline name aliveArvind Yadav
The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. Fixes: 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe access rules") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260714064402.2457257-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe/pt: Reset current_op in xe_pt_update_ops_init()Zongyao Bai
xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org Fixes: e8babb280b5e ("drm/xe: Convert multiple bind ops into single job") Suggested-by: Matthew Auld <matthew.auld@intel.com> Cc: stable@vger.kernel.org Assisted-by: GitHub-Copilot:claude-sonnet-4.6 Signed-off-by: Zongyao Bai <zongyao.bai@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260714232433.2737533-1-zongyao.bai@intel.com (cherry picked from commit 046045543e530605c441063535e7dca0075369a6) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe/wopcm: fix WOPCM size for LNL+Daniele Ceraolo Spurio
Starting on LNL the WOPCM size is 8MB instead of 4, so we need to avoid using the [0, 8MB) range of the GGTT as that can be unaccessible from the microcontrollers. Note that the proper long-term fix here is to read the WOPCM size from the HW, but that is a more serious rework that would be difficult to backport, so we can do that as a follow-up. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260713221758.3285744-2-daniele.ceraolospurio@intel.com (cherry picked from commit 3033b0b24ed0e2f5e56bdd4d9c183417c365a45b) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO movesMatthew Brost
xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260714062440.3421225-1-matthew.brost@intel.com (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe/nvm: fix writable override for CRIAlexander Usyskin
The witable override should be set when FDO_MODE bit is enabled. Fix the comparison to distingush this case from legacy systems where bit should be disabled to have override. Cc: stable@vger.kernel.org Fixes: 9dde74fd9e65 ("drm/xe/nvm: enable cri platform") Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260714-cri_nvm_fdo_flip-v2-1-14580e71b58e@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 2007be18d2318a59748da5da1b8968042213d5f1) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe: Hold a dma-buf reference for imported BOsNitin Gote
An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8023 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Cc: Christian Konig <christian.koenig@amd.com> Cc: Matthew Auld <matthew.auld@intel.com> Suggested-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260710191027.260160-2-nitin.r.gote@intel.com (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOCHimal Prasad Ghimiray
When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: c1bb69a2e8e2 ("drm/xe/svm: Consult madvise preferred location in prefetch") Cc: Matthew Brost <matthew.brost@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260624174943.2808767-2-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-16drm/xe/guc: Hold device ref until queue teardown completesArvind Yadav
GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. Fixes: 2d2be279f1ca ("drm/xe: fix UAF around queue destruction") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patch.msgid.link/20260716062624.211396-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-07-16drm/solomon: remove unneeded variables in blit functionsIker Pedrosa
Remove unneeded 'ret' variables in ssd130x_fb_blit_rect(), ssd132x_fb_blit_rect(), and ssd133x_fb_blit_rect() functions. These functions initialize ret to 0 and return it unchanged, so return 0 directly instead. Fixes: 2258f03989af ("drm/solomon: Move calls to drm_gem_fb_end_cpu*()") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606301409.I0ctsf41-lkp@intel.com/ Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260709-fix-ssd130x-v1-1-1272cb3dc85e@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-07-16drm/xe/guc: Keep scheduler timeline name aliveArvind Yadav
The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. Fixes: 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe access rules") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260714064402.2457257-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-07-15drm/xe/multi_queue: wait for secondary's own suspend in suspend_waitNiranjana Vishwanathapura
For a multi-queue group secondary, guc_exec_queue_suspend_wait() (and its blocking variant) only waited on the primary's suspend, on the assumption that the secondary's suspend is synchronous. It is not: the secondary's suspend rides the sched-message worker (short-circuited, no GuC round-trip) and completes asynchronously. When the primary was already suspended the forward is a refcount-only transition that queues no new primary SUSPEND and leaves the primary's suspend_pending clear, so the wait returned immediately while the secondary's own suspend was still in flight. A subsequent resume() then tripped the secondary's !suspend_pending assert. Wait for the secondary's own suspend to complete before waiting on the primary. On a timeout, ban the queue (which tears down the group) rather than leave it with suspend_pending set - otherwise the preempt-fence and hw-engine-group resume paths would resume it and hit the assert. Factor the per-queue wait into guc_exec_queue_wait_suspend_done() and share the orchestration between suspend_wait() and suspend_wait_blocking() via guc_exec_queue_suspend_wait_common(). Assisted-by: Github-Copilot:Claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260716045815.2315470-2-niranjana.vishwanathapura@intel.com
2026-07-16drm/xe: Consolidate debugfs fault injection functionsMallesh Koujalagi
The fault injection code was scattered: the GT reset hook lived in xe_gt.h as an inline function with its own global variable, the CSC hook had a separate global in xe_hw_error.c with an extern declaration, and each was individually registered in xe_debugfs.c. Adding a new error type meant editing many files and copy-pasting the same boilerplate. Debugfs interface (under /sys/kernel/debug/dri/0/): - fail_gt_reset - GT reset failure - inject_csc_hw_error - CSC firmware error Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260715085159.424040-2-mallesh.koujalagi@intel.com Signed-off-by: Riana Tauro <riana.tauro@intel.com>
2026-07-15gpu: nova-core: store Fsp instance in GpuAlexandre Courbot
The `Fsp` instance was only used in the Hopper+ boot path, and consequently built locally (and immediately dropped) in it. This worked well as a temporary measure, but the FSP is a GPU sub-device, so its lifetime should match the GPU rather than a single boot invocation. It will also be needed in other parts of the driver, for instance vGPU. Thus, create the `Fsp` instance in the `Gpu` constructor and store it there, passing it to the GSP boot as a mutable reference using `GspBootContext`. This makes the `Fsp` available even after the GSP is booted. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-13-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContextAlexandre Courbot
`Falcon` instances retain references tied to the lifetime of the bound GPU. `GspBootContext` currently uses that same lifetime for its own borrows of the `Falcon` instances and other references. But these lifetimes are independent: the references captured by a `Falcon` remain valid for the GPU lifetime, while the context only borrows the `Falcon` for the duration of a boot or unload operation. This distinction is hidden for shared references by covariance, but cannot be ignored anymore if the context carries mutable references to GPU subdevices, as will happen for the `Fsp` and the `Falcon`s. Thus, give `GspBootContext` separate lifetimes for its subdevice borrows and the GPU resources captured by those subdevices, and update its users accordingly. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-12-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: gsp: pass GspBootContext mutablyAlexandre Courbot
We want to move the `Fsp` instance into `Gpu`, which will require passing it as a mutable reference in `GspBootContext`, since `Fsp::boot_fmc` is a mutable method. In order to use the mutable references it contains, `GspBootContext` must also be mutable. We will also follow up by making some methods of the `Falcon`s mutable, which also requires passing them as mutable references. Thus, make the `GspBootContext` passed to `Gsp::boot` and `Gsp::unload` mutable, and pass mutable references to it to the GSP boot HAL methods. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-11-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: avoid repeated calls to pci::Device::as_refAlexandre Courbot
Add a local `Device` reference created from the `pci::Device` in the `Gpu` constructor to avoid repeatedly calling `as_ref`. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-10-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: move GSP firmware files decision to GSP HALEliot Courtney
The files to give the `ModInfoBuilder` depend on the chipset; this is HAL information, so move it there. Doing so lets us remove the `uses_fsp` and `needs_fwsec_bootloader` ad-hoc methods of `Chipset`. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-9-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HALAlexandre Courbot
By being in the TU102 HAL, we already know that the GSP boot method is the SEC2 Booter, so the only variable is whether the FWSEC bootloader is used or not. Since `Chipset` also includes the variants that boot FSP, querying it for that information introduces a potential code path (a chipset that boots via FSP) that the current code doesn't handle. Turn the use of the FWSEC bootloader into a property of the `Tu102` HAL, and give GA102+ chipsets their own instance with that property set to `false`. This removes the invalid code path and the only use of `Chipset` is now to load the correct firmware files. This also removes some uses of the `Chipset::needs_fwsec_bootloader` method and prepares the ground for removing it. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-8-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: gsp: turn FWSEC execution into HAL methodAlexandre Courbot
Turn the `run_fwsec_frts` function into a method of `Tu102`. A following patch will turn the "use FWSEC bootloader" property into a flag of the TU102 HAL itself, and making this a method will allow the code to access it instead of querying `Chipset`. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-7-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: gsp: fold TU102 unload bundle construction into HAL methodAlexandre Courbot
The construction of the unload bundle is currently a bit convoluted and could be done in one function instead of two. Additionally, turn that function into a method of `Tu102`. A following patch will turn the "use FWSEC bootloader" property into a flag of the TU102 HAL itself, and making this a method will allow the code to access it instead of querying `Chipset`. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-6-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: gsp: centralize missing unload bundle warningsAlexandre Courbot
The warning emitted when the unload bundle cannot be constructed is valid regardless of the boot method, but it was local to `Tu102`. Move it to `Gsp::boot` so it applies to all boot methods. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-5-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-15gpu: nova-core: gsp: pass GspBootContext to unload methodsAlexandre Courbot
`GspBootContext` contains the resources required to boot the GSP. As it turns out, this is also the context required for unloading it. Reflect that fact by replacing the arguments of `Gsp::unload` and `UnloadBundle::run` with the `GspBootContext`. This symmetry between `Gsp::boot` and `Gsp::unload` will also be convenient when we want to make these methods generic over the boot context corresponding to the boot method used. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-4-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-08 00:14:59 +0000