summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-06-03drm/amd/display: Enable DCN42 PMO policyNicholas Kazlauskas
[Why] The MinTTU policy in DML2.1 does not guarantee that we support p-state in blank. This is a delta vs dml2 and earlier revisions as the prefetch mode override has been removed in favor of a more configurable pstate optimizer. [How] The policy has been added in a prior patch, this patch enables it based on pmo flag. Reviewed-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-03drm/amd/display: Update get_pixel_clk_frequency() for DCN4x DCCG DP DTOOvidiu Bunea
[Why & How] DCN4x ASICs have different DCCG logic for programming DP DTO. The current get_pixel_clk_frequency_100hz() function does not account for this. Rename the function to "get_dp_dto_frequency" to more accurately reflect its intended behaviour. Create a new function that correctly calculates the target pixel rate for DCN4.x DCCG design and use it. Reviewed-by: Leo Chen <leo.chen@amd.com> Signed-off-by: Ovidiu Bunea <ovidiu.bunea@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-03drm/dumb-buffer: Drop buffer-size limits for nowThomas Zimmermann
The size limits break some of the CI tests. So drop them for now. Keep the other overflow tests from commit 5ab62dd3687b ("drm: prevent integer overflows in dumb buffer creation helpers") in place. There is still a pre-existing overflow check for 32-bit type limits in drm_mode_create_dumb() that will catch the really absurd size requests. Drivers that still do not use drm_mode_size_dumb() should be updated. The helper calculates dumb-buffer geometry with overflow checks. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5ab62dd3687b ("drm: prevent integer overflows in dumb buffer creation helpers") Reported-by: Jani Nikula <jani.nikula@linux.intel.com> Closes: https://lore.kernel.org/dri-devel/ddf0233e50044059c85279f928661563ef6a55bf@intel.com/ Cc: Rajat Gupta <rajat.gupta@oss.qualcomm.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260602112842.252279-1-tzimmermann@suse.de
2026-06-03mm/slab: improve kmem_cache_alloc_bulkChristoph Hellwig
The kmem_cache_alloc_bulk return value is weird. It returns the number of allocated objects, but that must always be 0 or the requested number based on the implementations and the handling in the callers, but that assumption is not actually documented anywhere, which confuses automated review tools. Fix this by returning a bool if the allocation succeeded and adding a kerneldoc comment explaining the API. [rob.clark@oss.qualcomm.com: fixups in msm_iommu_pagetable_prealloc_allocate() ] Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> # skbuff Link: https://patch.msgid.link/20260528093437.2519248-2-hch@lst.de Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-06-03gpu: nova-core: gsp: enable FSP boot pathAlexandre Courbot
Now that all the elements are in place, enable the FSP boot path so Hopper and Blackwell can boot. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-9-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: add non-sec2 unload pathEliot Courtney
For non-sec2 it is only required to wait for GSP falcon to halt. This is because GSP does the main work of unloading on GPUs not using sec2. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> [ jhubbard: use Result instead of Result<()> in the UnloadBundle impl ] Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-8-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add GSP lockdown release pollingJohn Hubbard
On Hopper and Blackwell, FSP boots GSP with hardware lockdown enabled. After FSP Chain of Trust completes, the driver must poll for lockdown release before proceeding with GSP initialization. Add the register bit and helper functions needed for this polling. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-7-d9f3a06939e0@nvidia.com [acourbot: fix `lockdown_released` logic and add explanatory comments.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust bootJohn Hubbard
Build and send the Chain of Trust message to FSP, bundling the DMA-coherent boot parameters that FSP reads at boot time. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-6-d9f3a06939e0@nvidia.com [acourbot: rename `frts_offset` to `frts_vidmem_offset`.] [acourbot: add note about frts_sysmem_* CoT members.] Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: select FSP Chain of Trust versionJohn Hubbard
The FSP Chain of Trust handshake is versioned: Hopper speaks version 1 and Blackwell speaks version 2. Provide the version through the FSP HAL so the boot message carries the value FSP expects, and so chipsets that do not use FSP need not express a version at all. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-5-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP send/receive messagingJohn Hubbard
FSP exchanges are request/response: the driver sends an MCTP/NVDM message and must match the reply against the request before acting on it. Add the synchronous send-and-wait path that validates the response transport and message headers and confirms the reply corresponds to the request that was sent. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-4-d9f3a06939e0@nvidia.com [acourbot: make `MessageToFsp` private.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: add MCTP/NVDM protocol types for firmware communicationJohn Hubbard
Add the MCTP (Management Component Transport Protocol) and NVDM (NVIDIA Data Model) wire-format types used for communication between the kernel driver and GPU firmware processors. This includes typed MCTP transport headers, NVDM message headers, and NVDM message type identifiers. Both the FSP boot path and the upcoming GSP RPC message queue share this protocol layer. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-3-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP message infrastructureJohn Hubbard
FSP communication uses a pair of non-circular queues in the FSP falcon's EMEM, one for messages from the driver to FSP and one for replies, with the driver polling for response data. Add the queue registers and the low-level helpers used by the higher-level FSP message layer. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-2-d9f3a06939e0@nvidia.com [acourbot: align register fields names with OpenRM.] [acourbot: represent registers as arrays of 8 instances, as per OpenRM.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operationsJohn Hubbard
Add external memory (EMEM) read/write operations to the GPU's FSP falcon engine. These operations use Falcon PIO (Programmed I/O) to communicate with the FSP through indirect memory access. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-1-d9f3a06939e0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-03drm/v3d: Skip CSD when it has zeroed workgroupsMaíra Canal
A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader. Cc: stable@vger.kernel.org Fixes: d223f98f0209 ("drm/v3d: Add support for compute shader dispatch.") Suggested-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260602-v3d-fix-indirect-csd-v4-2-654309e32bc0@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-06-03drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroupsMaíra Canal
v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped. Cc: stable@vger.kernel.org Fixes: 18b8413b25b7 ("drm/v3d: Create a CPU job extension for a indirect CSD job") Suggested-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260602-v3d-fix-indirect-csd-v4-1-654309e32bc0@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-06-03drm/i915: Fix color blob reference handling in intel_plane_stateChaitanya Kumar Borah
Take proper references for hw color blobs (degamma_lut, gamma_lut, ctm, lut_3d) in intel_plane_duplicate_state() and drop them in intel_plane_destroy_state(). v2: - handle blobs in hw state clear Cc: <stable@vger.kernel.org> #v6.19+ Fixes: 3b7476e786c2 ("drm/i915/color: Add framework to program PRE/POST CSC LUT") Fixes: a78f1b6baf4d ("drm/i915/color: Add framework to program CSC") Fixes: 65db7a1f9cf7 ("drm/i915/color: Add 3D LUT to color pipeline") Reviewed-by: Pranay Samala <pranay.samala@intel.com> #v1 Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260601082953.128539-4-chaitanya.kumar.borah@intel.com (cherry picked from commit c6eea1925154b6697fe22b217faab9bb30635e6b) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-06-03thermal/of: Add cooling device ID supportDaniel Lezcano
Introduce an identifier (cdev_id) for cooling devices registered from device tree. This prepares support for a new DT binding where cooling devices are identified by a tuple (device node, ID), instead of relying on child nodes. Existing users are updated to pass a default ID of 0, preserving the current behavior. Future changes will extend the cooling map parsing to match cooling devices based on both the device node and the ID. No functional change intended. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260526140802.1059293-19-daniel.lezcano@oss.qualcomm.com
2026-06-03Merge tag 'amd-drm-next-7.2-2026-05-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.2-2026-05-29: amdgpu: - GEM_OP warning fix - GEM_OP locking fix - Userq fixes - DCN 2.1 refclk fix - SI fixes - HMM fixes - Add DC KUNIT tests - UML fixes - Switch to system_dfl_wq - Old DC power state cleanup - RAS fixes amdkfd: - svm_range_set_attr locking fix - CRIU restore fix - KFD debugger fix radeon: - Use struct drm_edid instead of struct edid Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260529214346.2328355-1-alexander.deucher@amd.com
2026-06-03Merge tag 'drm-intel-gt-next-2026-05-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Cross-subsystem Changes: - Backmerge of drm-next to pull in a commit to revert Driver Changes: - Avoid skipping already signaled fence after reset (Sebastian) - Fix potential UAF in TTM object purge (Janusz) - Fix refcount underflow in intel_engine_park_heartbeat (Sebastian) - Drop check for changed VM in EXECBUF (Joonas) - Revert the "else vma = NULL" patch for being superseded (Joonas) - Selfest improvements (Janusz, Krzysztof) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/ahlc1R5bzJvmBLlZ@jlahtine-mobl
2026-06-03Merge tag 'drm-misc-next-2026-05-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.2-rc1: UAPI Changes: - amdxdna: Revert read-only user-pointer BO mappings. - panthor: Add eviction and reclaim info to fdinfo. Cross-subsystem Changes: - Convert DMA-buf system and cma heap allocators to module. Core Changes: - Cleanup driver misuses of drm/exec. Driver Changes: - Add LG LP129WT232166, AM-1280800W8TZQW-T00H, NEC NL6448BC33-70C, Riverdi RVT70HSLNWCA0 and RVT101HVLNWC00 panels. - Add support for RZ/T2H SoC to renesas. - Add cursor plane support to verisilicon. - Support DVI outputs in ite-it66121 bridge. - Assorted bugfixes, docbook updates and improvements to ivpu, tegra, host1x, nouveau. - Add DSC quirk for ASUS DC301 USB-C dock. - Use drm client buffer for tegra framebuffer. - Add support for GA100 to nouveau. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/ef65f43c-becf-473c-a5cc-203fdfecd491@linux.intel.com
2026-06-03Merge tag 'drm-intel-next-2026-05-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Xe related: - Fix Xe oops in suspend/shutdown when display was disabled (Jani) Display in general: - More general refactor towards display separation (Jani) - Preparation for fix Adaptive-Sync SDP for PR with Link ON + Auxless-ALPM (Ankit) - PSR related fixes and improvements (Jouni) - Use polling when irqs are unavailable (Michal) - Split bandwidth params into platform- and display-IP-specific structs (Gustavo) - Revert "drm/i915/backlight: Remove try_vesa_interface" (Suraj) - Casf & scaler refactoring (Michal) - Add support for pipe background color (Maarten) - General clean-ups (Maarten) - Sanitize DP link capability change handling (Imre) - Multiple BW QGV fixes (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/ahhFE5Co5PdZQKG8@intel.com
2026-06-03Merge tag 'drm-xe-next-2026-05-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - drm/xe: Move xe_uc_fw_abi.h to abi/ (Michal Wajdeczko) - drm/xe: Restore IDLEDLY regiter on engine reset (Balasubramani Vivekanandan) - drm/xe/pm: Do early initialization in init_early() (Michal Wajdeczko) - drm/xe/pm: Don't access device in init_early() (Michal Wajdeczko) - drm/xe: Separate early xe_device initialization (Michal Wajdeczko) - drm/xe: Move xe->info.devid|revid initialization (Michal Wajdeczko) - drm/xe: Move xe->info.force_execlist initialization (Michal Wajdeczko) - drm/xe: Drop unused param from xe_device_create() (Michal Wajdeczko) - drm/xe: Use raw device ID to find sub-platform descriptor (Michal Wajdeczko) - drm/xe: Assign queue name in time for drm_sched_init (Tvrtko Ursulin) - drm/xe/rtp: Implement a structured parser for rule matching (Gustavo Sousa) - drm/xe/rtp: Fully parse the ruleset (Gustavo Sousa) - drm/xe/rtp: Extract rule_match_item() (Gustavo Sousa) - drm/xe/rtp: Do not break parsing when missing context (Gustavo Sousa) - drm/xe/rtp: Don't short-circuit to false in or-yes case (Gustavo Sousa) - drm/xe/rtp: Drop rule matching cases from rtp_to_sr_cases and rtp_cases (Gustavo Sousa) - drm/xe/rtp: Write kunit test cases specific for rule matching (Gustavo Sousa) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/ahg7tgWh8djEngjM@fedora
2026-06-02rust/drm/gem: Use DeviceContext with GEM objectsLyude Paul
Now that we have the ability to represent the context in which a DRM device is in at compile-time, we can start carrying around this context with GEM object types in order to allow a driver to safely create GEM objects before a DRM device has registered with userspace. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20260507220044.3204919-4-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-02rust/drm: Introduce DeviceContextLyude Paul
One of the tricky things about DRM bindings in Rust is the fact that initialization of a DRM device is a multi-step process. It's quite normal for a device driver to start making use of its DRM device for tasks like creating GEM objects before userspace registration happens. This is an issue in rust though, since prior to userspace registration the device is only partly initialized. This means there's a plethora of DRM device operations we can't yet expose without opening up the door to UB if the DRM device in question isn't yet registered. Additionally, this isn't something we can reliably check at runtime. And even if we could, performing an operation which requires the device be registered when the device isn't actually registered is a programmer bug, meaning there's no real way to gracefully handle such a mistake at runtime. And even if that wasn't the case, it would be horrendously annoying and noisy to have to check if a device is registered constantly throughout a driver. In order to solve this, we first take inspiration from `kernel::device::DeviceContext` and introduce `kernel::drm::DeviceContext`. This provides us with a ZST type that we can generalize over to represent contexts where a device is known to have been registered with userspace at some point in time (`Registered`), along with contexts where we can't make such a guarantee (`Uninit`). It's important to note we intentionally do not provide a `DeviceContext` which represents an unregistered device. This is because there's no reasonable way to guarantee that a device with long-living references to itself will not be registered eventually with userspace. Instead, we provide a new-type for this: `UnregisteredDevice` which can provide a guarantee that the `Device` has never been registered with userspace. To ensure this, we modify `Registration` so that creating a new `Registration` requires passing ownership of an `UnregisteredDevice`. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20260507220044.3204919-2-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-02drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked()Lyude Paul
One of the complications of trying to use the shmem helpers to create a scatterlist for shmem objects is that we need to be able to provide a guarantee that the driver cannot be unbound for the lifetime of the scatterlist. The easiest way of handling this seems to be just hooking up an unmap operation to devres the first time we create a scatterlist, which allows us to still take advantage of gem shmem facilities without breaking that guarantee. To allow for this, we extract __drm_gem_shmem_free_sgt_locked() - which allows a caller (e.g. the rust bindings) to manually unmap the sgt for a gem object as needed. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260529183702.677677-6-lyude@redhat.com
2026-06-02gpu: nova-core: Hopper/Blackwell: add FMC signature extractionJohn Hubbard
Extract the SHA-384 hash, RSA public key, and RSA signature from the FMC ELF32 firmware sections. FSP Chain of Trust verification needs these to validate the FMC image during boot. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-14-jhubbard@nvidia.com [acourbot: derive `Zeroable` on `FmcSignature` for in-place initialization] Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Hopper/Blackwell: add FSP secure boot completion waitingJohn Hubbard
Hopper and Blackwell use FSP instead of SEC2 for secure boot. The driver must wait for FSP secure boot to complete before continuing with GSP bring-up. Poll for boot success with a 5-second timeout, and return the FSP interface only on success so that later Chain of Trust operations cannot run before FSP is ready. The interface owns the FSP falcon and the FMC firmware. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-13-jhubbard@nvidia.com [acourbot: use `inspect_err` instead of `map_err` and display actual error] [acourbot: limit visibility of `fsp_hal` to `super``] Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Hopper/Blackwell: add FMC firmware imageJohn Hubbard
FSP is the Falcon that runs FMC firmware on Hopper and Blackwell. Load the FMC ELF in two forms: the image section that FSP boots from, and the full Firmware object for later signature extraction during Chain of Trust verification. Declare the FMC image in the module's firmware table so it is bundled for FSP-based chipsets. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-12-jhubbard@nvidia.com Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Hopper/Blackwell: add FSP falcon engine stubJohn Hubbard
Add the FSP (Foundation Security Processor) falcon engine type that will handle secure boot and Chain of Trust operations on Hopper and Blackwell architectures. The FSP falcon replaces SEC2's role in the boot sequence for these newer architectures. This initial stub just defines the falcon type and its base address. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-11-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: add auto-detection of 32-bit, 64-bit firmware imagesJohn Hubbard
A firmware image may be either a 32-bit or a 64-bit ELF, and callers should not have to know which. Detect the ELF class from the image header at parse time and dispatch to the matching parser, so a single entry point handles both layouts. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-10-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: add support for 32-bit firmware imagesJohn Hubbard
Some GPU firmware images are packaged as 32-bit ELF rather than 64-bit. Add a 32-bit implementation of the shared ELF section-parsing abstraction so those images can be parsed alongside the existing 64-bit path. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-9-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: don't assume 64-bit firmware imagesJohn Hubbard
Introduce a single ELF format abstraction that ties each ELF header type to its matching section-header type. This keeps the shared section parser ready for upcoming ELF32 support and avoids mixing 32-bit and 64-bit ELF layouts by mistake. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-8-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Blackwell: use correct sysmem flush registersJohn Hubbard
Blackwell GPUs moved the sysmem flush page registers away from the Ampere/Ada location. GB10x routes the flush through a pair of HSHUB0 register sets (primary and egress) that must both be programmed to the same address. GB20x routes it through FBHUB0. Define these registers relative to their HSHUB0 and FBHUB0 bases, as Open RM does, and implement the flush paths in the GB10x and GB20x framebuffer HALs. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-7-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Hopper/Blackwell: larger WPR2 (GSP) heapJohn Hubbard
The GSP-RM boot working memory portion of the WPR2 heap must be larger on Hopper and later GPUs than on Turing, Ampere, and Ada. Select the larger value for those generations. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-6-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Hopper/Blackwell: larger non-WPR heapJohn Hubbard
Hopper and Blackwell need a larger non-WPR heap than the 1 MiB that earlier architectures use. Hopper and Blackwell GB10x need 2 MiB, while Blackwell GB20x needs 2 MiB + 128 KiB. These sizes diverge by family, so give Hopper and each Blackwell family its own framebuffer HAL and select the non-WPR heap size per chipset family. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-5-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Blackwell: compute PMU-reserved framebuffer sizeJohn Hubbard
GSP boot needs to know how much framebuffer memory is reserved for the PMU. Compute it per architecture: Blackwell dGPUs reserve a non-zero amount, earlier architectures leave it at zero, matching Open RM behavior. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-4-jhubbard@nvidia.com Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Hopper/Blackwell: new location for PCI config mirrorJohn Hubbard
Hopper and Blackwell GPUs moved the PCI config space mirror from 0x088000 to 0x092000. Select the correct address per architecture when building the GSP system info command. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-3-jhubbard@nvidia.com Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: set DMA mask width based on GPU architectureJohn Hubbard
Replace the hardcoded 47-bit DMA mask with a GPU HAL method that provides the correct value for the architecture. Set the DMA mask in Gpu::new(). Gpu owns all DMA allocations for the device, so no concurrent allocations can exist while the constructor is still running. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260602032111.224790-2-jhubbard@nvidia.com Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02drm/tyr: use IoMem directly instead of DevresDanilo Krummrich
Now that IoMem is lifetime-parameterized, use it directly in probe rather than wrapping it in Devres and Arc. The I/O memory mapping is only used during probe and not stored in driver data, so device-managed revocation is unnecessary. This removes the Devres access(dev) pattern from issue_soft_reset(), GpuInfo::new(), and l2_power_on(), simplifying register access. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260529000106.2257996-3-dakr@kernel.org Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-06-02drm/tyr: separate driver type from driver dataDanilo Krummrich
Introduce TyrPlatformDriver as a unit struct for the platform::Driver trait implementation and keep TyrPlatformDriverData for the private driver data. Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260529000106.2257996-2-dakr@kernel.org Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-06-02drm/imx: Fix three kernel-doc warnings in dcss-scaler.cYicong Hui
Fix the following W=1 kerneldoc warnings by adding the missing parameter descriptions for @phase0_identity and @nn_interpolation in dcss_scaler_filter_design() and @phase0_identity in dcss_scaler_gaussian_filter() Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:173 function parameter 'phase0_identity' not described in 'dcss_scaler_gaussian_filter' Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:270 function parameter 'phase0_identity' not described in 'dcss_scaler_filter_design' Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:270 function parameter 'nn_interpolation' not described in 'dcss_scaler_filter_design' Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by: Yicong Hui <yiconghui@gmail.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patch.msgid.link/20260406180013.2442096-1-yiconghui@gmail.com Signed-off-by: Liu Ying <victor.liu@nxp.com>
2026-06-01drm/v3d: Clean caches before runtime suspendMaíra Canal
On runtime suspend, clean the V3D caches before suspending so all dirty lines are written back to memory before the power domain is shut down. Fixes several system hangs reported in [1][2][3]. Closes: https://github.com/raspberrypi/linux/issues/7381 [1] Closes: https://github.com/raspberrypi/linux/issues/7396 [2] Closes: https://github.com/raspberrypi/linux/issues/7397 [3] Fixes: 458f2a712ab4 ("drm/v3d: Introduce Runtime Power Management") Link: https://patch.msgid.link/20260530-v3d-fix-rpi4-freezes-v1-3-c2c8307da6ce@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2026-06-01drm/v3d: Flush MMU TLB and cache during runtime resumeMaíra Canal
v3d_mmu_set_page_table() ends by calling v3d_mmu_flush_all() to flush the MMU cache and clear the TLB after reprogramming V3D_MMU_PT_PA_BASE. v3d_mmu_flush_all() is gated by pm_runtime_get_if_active(), which returns 0 unless runtime_status == RPM_ACTIVE. v3d_mmu_set_page_table() is called from two paths that *know* V3D is reachable, but where the runtime PM status might be wrong: 1. v3d_power_resume(): the runtime resume callback itself, where runtime_status is RPM_RESUMING. 2. v3d_reset(): called from the DRM scheduler timeout handler with the hung job's pm_runtime reference held, so RPM_ACTIVE, but here we don't need to take an extra reference for the duration of the flush either. In the first case pm_runtime_get_if_active() returns 0, the flush is silently skipped, and V3D resumes executing with whatever MMUC/TLB state happened to survive the last reset. This can leave stale translations live across runtime PM cycles, manifesting as random GPU hangs. Split the actual flush sequence into a helper that does the writes unconditionally, and have v3d_mmu_set_page_table() call it directly. Fixes: 458f2a712ab4 ("drm/v3d: Introduce Runtime Power Management") Link: https://patch.msgid.link/20260530-v3d-fix-rpi4-freezes-v1-2-c2c8307da6ce@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2026-06-01drm/v3d: Wait for pending L2T flush before cleaning cachesMaíra Canal
v3d_clean_caches() starts the cache-clean sequence by writing V3D_L2TCACTL_TMUWCF to V3D_CTL_L2TCACTL and then polling for that bit to clear. It does not, however, check for an L2T flush (L2TFLS) that may still be in flight from a previous operation. On pre-V3D 7.1 hardware, kicking off the TMU write-combiner flush while an L2T flush is still pending can clobber bits in L2TCACTL and cause cache inconsistencies. Poll for L2TFLS to clear before writing L2TCACTL on V3D < 7.1, ensuring any pending flush has completed before a new clean is issued. Cc: stable@vger.kernel.org Fixes: d223f98f0209 ("drm/v3d: Add support for compute shader dispatch.") Link: https://patch.msgid.link/20260530-v3d-fix-rpi4-freezes-v1-1-c2c8307da6ce@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2026-06-01Revert "drm/xe/nvls: Define GuC firmware for NVL-S"Daniele Ceraolo Spurio
This reverts commit 4e88de313ff4d1c67b644b1f39f9fb4089711b71. The early GuC FW definition meant for our CI branch was accidentally merged to the drm-xe-next branch instead. This GuC FW will never be released to linux-firmware, so we do not want the definition to be available in the mainline Linux codebase. Fixes: 4e88de313ff4 ("drm/xe/nvls: Define GuC firmware for NVL-S") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Julia Filipchuk <julia.filipchuk@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org # v7.0+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260529193558.185436-11-daniele.ceraolospurio@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 65b8e0ac86e48cfc9128c04dfc53ea3395d030dd) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-05-30gpu: nova-core: gsp: run the unload bundle if Gsp::boot() failsAlexandre Courbot
If `Gsp::boot` fails, the GSP can be left in a state where boot cannot be attempted again unless it is reset first. To avoid this, we want to run the unload bundle whenever `boot` fails to try and clear the partially-initialized state. Do this by wrapping the unload bundle into a drop guard up until `boot` returns. After that, running the unload bundle becomes the responsibility of the caller. Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260529-nova-unload-v7-4-678f39209e00@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-30gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbindingAlexandre Courbot
When probing the driver, the FWSEC-FRTS firmware creates a WPR2 secure memory region to store the GSP firmware, and the Booter Loader loads and starts that firmware into the GSP, making it run in RISC-V mode. These operations need to be reverted upon unloading, particularly the WPR2 secure region creation, as its presence prevents the driver from subsequently probing. Thus, prepare the Booter Unloader and FWSEC-SB firmware images when booting the GSP, so they can be executed at unbind time to put the GPU into a state where it can be probed again. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Co-developed-by: Eliot Courtney <ecourtney@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260529-nova-unload-v7-3-678f39209e00@nvidia.com [acourbot: `Result<()>` -> `Result`] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-30gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command upon unloadingAlexandre Courbot
Currently, the GSP is left running after the driver is unbound. This is not great for several reasons, notably that it can still access shared memory areas that the kernel will now reclaim (especially problematic on setups without an IOMMU). Fix this by sending the `UNLOADING_GUEST_DRIVER` GSP command when the `Gpu` is dropped. This stops the GSP and lets us proceed with the rest of the unbind sequence in a later patch. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Co-developed-by: Eliot Courtney <ecourtney@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260529-nova-unload-v7-2-678f39209e00@nvidia.com [acourbot: `Result<()>` -> `Result`] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-30gpu: nova-core: gsp: move chipset-specific parts of the boot process into a HALAlexandre Courbot
Booting the GSP is done differently depending on the architecture. Move the parts that are chipset-specific under a HAL. This does not change much at the moment, since the differences between Turing and Ampere are rather benign, but will become critical to properly support the FSP boot process used by Hopper and Blackwell. The Hopper/Blackwell support is not merged yet, so their HAL is a stub for now. This patch is intended to be a mechanical code extraction with no behavioral changes. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260529-nova-unload-v7-1-678f39209e00@nvidia.com [acourbot: `Result<()>` -> `Result`] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-30drm/gem: fix race between change_handle and handle_deleteZhenghang Xiao
drm_gem_change_handle_ioctl leaves the old handle live in the IDR during the window between spin_unlock(table_lock) and the final spin_lock(table_lock). A concurrent drm_gem_handle_delete on the old handle succeeds in this window, decrements handle_count to 0, and frees the GEM object while the new handle's IDR entry still references it. NULL the old handle's IDR entry before dropping table_lock so that any concurrent GEM_CLOSE on the old handle sees NULL and returns -EINVAL. Restore the old entry on the prime-bookkeeping error path. Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Signed-off-by: Zhenghang Xiao <kipreyyy@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260526085313.26791-1-kipreyyy@gmail.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-11 15:14:31 +0000