summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-10-20drm/i915/panic: fix panic structure allocation memory leakJani Nikula
Separating the panic allocation from framebuffer allocation in commit 729c5f7ffa83 ("drm/{i915,xe}/panic: move framebuffer allocation where it belongs") failed to deallocate the panic structure anywhere. The fix is two-fold. First, free the panic structure in intel_user_framebuffer_destroy() in the general case. Second, move the panic allocation later to intel_framebuffer_init() to not leak the panic structure in error paths (if any, now or later) between intel_framebuffer_alloc() and intel_framebuffer_init(). v2: Rebase Fixes: 729c5f7ffa83 ("drm/{i915,xe}/panic: move framebuffer allocation where it belongs") Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Reported-by: Michał Grzelak <michal.grzelak@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Michał Grzelak <michal.grzelak@intel.com> # v1 Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251015095135.2183415-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 8f8ef09fcf6a3b00369bfc704e8f68d7474eca94) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-20drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02Dnyaneshwar Bhadane
Load the DMC for Xe3_LPD version 30.02. Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://lore.kernel.org/r/20251016131517.2032684-1-dnyaneshwar.bhadane@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-10-20drm/panfrost: Rename panfrost_job functions to reflect real roleAdrián Larumbe
panfrost_job_* prefixed functions in panfrost_job.c deal with both panfrost_job objects and also the more general JM (Job Manager) side of the device itself. This is confusing. Reprefix functions that program the JM to panfrosot_jm_* instead. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-12-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Remove unused device propertyAdrián Larumbe
The as_in_use_mask device state variable is no longer in use. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-11-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Add forward declaration and types headerAdrián Larumbe
This is to make LLVM syntactic analysers happy. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-10-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Make re-enabling job interrupts at device reset optionalAdrián Larumbe
Rather than remasking interrupts after a device reset in the main reset path, allow selecting whether to do this with an additional bool parameter. To this end, split reenabling job interrupts into two functions, one that clears the interrupts and another one which unmasks them conditionally. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-9-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Don't rework job IRQ enable mask in the enable pathAdrián Larumbe
Up until now, panfrost_job_enable_interrupts() would always recalculate the same job IRQ enablement mask, which is effectively a constant. Replace it with a compile-time constant value, and also in another couple places where an equivalent expression was being used. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-8-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle page mapping failureAdrián Larumbe
When mapping the pages of a BO, either a heap type at page fault time or else a non-heap BO at object creation time, if the ARM page table mapping function fails, we unmap what had been mapped so far and bail out. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-7-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Check sgt to know whether pages are already mappedAdrián Larumbe
In the MMU's page fault ISR for a heap object, determine whether the faulting address belongs to a 2MiB block that was already mapped by checking its corresponding sgt in the Panfrost BO. This is done in preparation for a future commit in which the MMU mapping helper might fail, but the page array is left populated, so this cannot be used as a check for an early bail-out. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-6-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle error when allocating AS numberAdrián Larumbe
If we reach the beginning of the LRU AS list, then return an error. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-5-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle job HW submit errorsAdrián Larumbe
Avoid waiting for the DRM scheduler job timedout handler, and instead, let the DRM scheduler core signal the error fence immediately when HW job submission fails. That means we must also decrement the runtime-PM refcnt for the device, because the job will never be enqueued or inflight. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-4-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle inexistent GPU during probeAdrián Larumbe
Just in case we're dealing with a yet not recognised device. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-3-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Replace DRM driver allocation method with newer oneAdrián Larumbe
Drop the deprecated DRM driver allocation method in favour of devm_drm_dev_alloc(). Overall just make it the same as in Panthor. Also discard now superfluous generic and platform device pointers inside the main panfrost device structure. Some ancient checkpatch issues unearthed as a result of these changes were also fixed, like lines too long or double assignment in one line. Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-2-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/rockchip: Use temporary variablesDaniel Stone
Brevity is good. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-6-daniels@collabora.com
2025-10-20drm/rockchip: Rename variables for clarityDaniel Stone
actual_w and actual_h were the clipped source width, so rename them to fit the use. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-5-daniels@collabora.com
2025-10-20drm/rockchip: Return error code for errorsDaniel Stone
Instead of silently disabling small planes, refuse to create them at all. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-4-daniels@collabora.com
2025-10-20drm/rockchip: Declare framebuffer width/height boundsDaniel Stone
The VOP2 has limitations on its input and output sizes. The clipped display region must be at least 4px in each dimension for both framebuffer source and plane destination, and the clipped source region must be no greater than a per-version limit. It is never valid for VOP2 to have a framebuffer which is less than four pixels in either dimension, so declare that as our min width/height, enforced by AddFB failing if the user tries. It can theoretically be valid to have a single large framebuffer of which only certain clipped regions are shown, but this is a very uncommon case. Declaring to userspace that the framebuffer's maximum width and height is the maximum source clip helps it make better decisions as to which mode to use, instead of trying unsupported sizes and having to fall back. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-3-daniels@collabora.com
2025-10-20drm/rockchip: Demote normal drm_err to debugDaniel Stone
A plane check failing is a normal and expected condition, as userspace isn't aware of the specific constraints and will try any and every combination until one succeeds. Push this down to a debug message, so users can see it if they want to, but make sure we don't spam the log during normal operation. Fixes: 604be85547ce4 ("drm/rockchip: Add VOP2 driver") Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-2-daniels@collabora.com
2025-10-20Merge tag 'v6.18-rc2' into 'drm-rust-next'Alice Ryhl
When pushing commits to drm-rust-next, we need to verify that the patches pass rustfmt. Thus, pull in v6.18-rc2 for its rustfmt fix. Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-10-20panthor: use drm_gpuva_unlink_defer()Alice Ryhl
Instead of manually deferring cleanup of vm_bos, use the new GPUVM infrastructure for doing so. To avoid manual management of vm_bo refcounts, the panthor_vma_link() and panthor_vma_unlink() methods are changed to get and put a vm_bo refcount on the vm_bo. This simplifies the code a lot. I preserved the behavior where panthor_gpuva_sm_step_map() drops the refcount right away rather than letting panthor_vm_cleanup_op_ctx() do it later. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/r/20251006-vmbo-defer-v4-2-30cbd2c05adb@google.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-10-20drm/gpuvm: add deferred vm_bo cleanupAlice Ryhl
When using GPUVM in immediate mode, it is necessary to call drm_gpuvm_unlink() from the fence signalling critical path. However, unlink may call drm_gpuvm_bo_put(), which causes some challenges: 1. drm_gpuvm_bo_put() often requires you to take resv locks, which you can't do from the fence signalling critical path. 2. drm_gpuvm_bo_put() calls drm_gem_object_put(), which is often going to be unsafe to call from the fence signalling critical path. To solve these issues, add a deferred version of drm_gpuvm_unlink() that adds the vm_bo to a deferred cleanup list, and then clean it up later. The new methods take the GEMs GPUVA lock internally rather than letting the caller do it because it also needs to perform an operation after releasing the mutex again. This is to prevent freeing the GEM while holding the mutex (more info as comments in the patch). This means that the new methods can only be used with DRM_GPUVM_IMMEDIATE_MODE. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20251006-vmbo-defer-v4-1-30cbd2c05adb@google.com [aliceryhl: fix formatting of vm_bo = llist_entry(...) line] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-10-18drm/xe/xe3p: Add xe3p EU stall data formatHarish Chegondi
Starting with Xe3p, IP address in EU stall data increases to 61 bits. While at it, re-order the if-else ladder so the officially supported platforms come before PVC. Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-24-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/xe3p_xpc: Setup PAT tableMatt Roper
Xe3p_XPC IP requires a new PAT table; note that this table has one fewer column than the Xe2/Xe3 tables since compression is not supported. There's also no "WT" entry (which we wouldn't have used on a platform without display anyway). Bspec: 71582 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-23-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/xe3p_xpc: Skip compression tuning on platforms without flatccsMatt Roper
The compression overfetch tuning settings only apply to platforms that support FlatCCS. In Xe3p_XPC (and any future IPs that also lack compression) some of the registers being adjusted by this tuning will not exist or may have been repurposed for something else, so we should take care not to try to program them. Note that our xe_rtp_match_has_flatccs() function will also return false on platforms that do have FlatCCS in the hardware design, but have compression manually disabled in the BIOS. On such platforms the registers still exist (and it would be fine to continue programming them), but they would have no effect, so skipping that tuning is also safe. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-22-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/xe3p_xpc: Add support for compute walker for non-MSIxLucas De Marchi
Current implementation of compute walker has dependency on GPU/SW Stack which requires SW/UMD to wait for event from KMD to indicate PIPE_CONTROL interrupt was done. This created latency on SW stack. This feature adds support to generate completion interrupt from GPGPU walker which does not support MSIx and avoid software using Pipe control drain/idle latency. The only thing needed for the kernel driver to do here is to wakeup the thread waiting on the ufence, which is already handled by the irq handler. Before waiting on this event, the userspace side can opt-in to this interrupt being generated by the HW by selecting the flag in the POST_SYNC_DATA_2 substructure's dw0[3] of COMPUTE_WALKER_2 instruction. Bspec: 62346, 74334 Suggested-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: S A Muqthyar Ahmed <syed.abdul.muqthyar.ahmed@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-21-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/irq: Check fuse mask for media enginesLucas De Marchi
Just like the other engines, check xe_hw_engine_mask_per_class() for VCS and VECS to account for architectural availability of those registers. With that, all the possibly available media engines can have their interrupts enabled. Bspec: 54030 Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-20-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/irq: Rename bits used with all enginesLucas De Marchi
Two bit fields have similar functionality across the interrupt vectors but are named "RENDER". Rename them to follow the bspec more closely and clear any confusion when using them for other engines. Bspec: 62353, 62354, 62355, 62346, 62345, 63341 Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-19-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/irq: Split irq mask per engine classLucas De Marchi
Each engine class has a different bitfield structure in the hw. We've been just using a common mask for all of them, but this means that we could inadvertently set a wrong bit in one class while enabling something in another. Split them to make it more future proof. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-18-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/irq: Rename fuse mask variablesLucas De Marchi
It's confusing to refer to some masks as the interrupt masks and others as the fuse masks. Rename the fuse one to make it clearer. Note that the most important role they play here is that the call to xe_hw_engine_mask_per_class() will not only limit the engines according to the fuses, but also by what is available in the specific architecture - the latter is more important information to know what interrupts should be enabled. Add a comment about that. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-17-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/xe3p_xpc: Add MCR steeringMatt Roper
Xe3p_XPC's steering has a few changes from Xe3. Aside from minor changes to the XeCore (the new name for what used to be "DSS") and INSTANCE0 tables, different rules apply to different subranges of type "GAM." Certain GAM subranges require steering to grp/instance (0,0) (and thus use the INSTANCE0 table), while others require special steering to (1,0) instead. Similarly, there are multiple classes of "PSMI" steering, with some requiring steering to (0,0) while others require (19,0). There are some ranges in Bspec missing the termination. Add a TODO comment so they can eventually be updated. Bspec: 74418 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-16-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/xe3p_xpc: Add L3 bank maskFei Yang
Expose L3 bank mask through topology query interface. In Xe3p_XPC, MIRROR_L3BANK_ENABLE represents the full L3 bank mask (not just a per-node mask), and each bit represents a single bank. With that there's no extra complexity to calculate the L3 bank mask like there was in previous platforms. Bspec: 73439 Signed-off-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-15-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/xe3p_xpc: Add Xe3p_XPC IP definitionBalasubramani Vivekanandan
Add support for graphics IP Xe3p_XPC having IP version 35.11. Bspec: 77979, 77975 Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-14-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/xe/nvls: Attach MOCS table for NVL-SDnyaneshwar Bhadane
The MOCS table for NVL-S is the same as that of Xe2. Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-13-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/client: Remove holds_console_lock parameter from suspend/resumeThomas Zimmermann
No caller of the client resume/suspend helpers holds the console lock. The last such cases were removed from radeon in the patch series at [1]. Now remove the related parameter and the TODO items. v2: - update placeholders for CONFIG_DRM_CLIENT=n Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/series/151624/ # [1] Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251001143709.419736-1-tzimmermann@suse.de
2025-10-17drm/xe/nvl: Define NVL-S platformMatt Roper
Provide the basic platform definitions and PCI IDs for NVL-S. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-11-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-18drm/i915/vrr: Use optimized guardband whenever VRR TG is activeAnkit Nautiyal
Currently the guardband is optimized only for platforms where the VRR timing generator is always ON. Extend the usage of optimized guardband to all VRR supporting platforms. v2: Drop check for `crtc_state->vrr.enable` and just return true unconditionally from intel_vrr_use_optimized_guardband(). (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-6-ankit.k.nautiyal@intel.com
2025-10-18drm/i915/vrr: Use the min static optimized guardbandAnkit Nautiyal
In the current VRR implementation, vrr.vmin and vrr.guardband are set such that they do not need to change when switching from fixed refresh rate to variable refresh rate. Specifically, vrr.guardband is always set to match the vblank length. This approach works for most cases, but not for LRR, where the guardband would need to change while the VRR timing generator is still active. With the VRR TG always active, live updates to guardband are unsafe and not recommended. To ensure hardware safety, guardband was moved out of the !fastset block, meaning any change now requires a full modeset. This breaks seamless LRR switching, which was previously supported. Since the problem arises from guardband being matched to the vblank length, solution is to use a minimal, sufficient static value, instead. So we use a static guardband defined during mode-set that fits within the smallest expected vblank and remains unchanged in case of features like LRR where vtotal changes. To compute this minimum guardband we take into account latencies/delays due to different features as mentioned in the Bspec. Introduce a helper to compute the minimal sufficient guardband. On platforms where the VRR timing generator is always ON, we optimize the guardband regardless of whether the display is operating in fixed or variable refresh rate mode. v2: - Use max of sagv latency and skl_wm_latency(1) for PM delay computation. (Ville) - Avoid guardband optimization for HDMI for now. (Ville) - Allow guardband optimization only for platforms with intel_vrr_always_use_vrr_tg = true. (Ville) - Add comments for PM delay and a #TODO note for HDMI. v3: Drop the variable prefill_min_guardband. (Ville) Bspec: 70151 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-5-ankit.k.nautiyal@intel.com
2025-10-18drm/i915/dp: Check if guardband can accommodate sdp latenciesAnkit Nautiyal
Check if guardband is sufficient for all DP SDP latencies. If its not, fail .compute_config_late(). Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-4-ankit.k.nautiyal@intel.com
2025-10-18drm/i915/dp: Add helper to get min sdp guardbandAnkit Nautiyal
Add a helper to compute vblank time needed for transmitting specific DisplayPort SDPs like PPS, GAMUT_METADATA, and VSC_EXT. Latency is based on line count per packet type. This will be used to ensure adequate guardband when features like DSC/HDR are enabled. v2: Correct the lines required for PPS SDP. (Jouni) Bspec: 70151 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-3-ankit.k.nautiyal@intel.com
2025-10-18drm/i915/psr: Add helper to get min psr guardbandAnkit Nautiyal
Introduce a helper to compute the max link wake latency when using Auxless/Aux wake mechanism for PSR/Panel Replay/LOBF features. This will be used to compute the minimum guardband so that the link wake latencies are accounted and these features work smoothly for higher refresh rate panels. v2: - Account for flag `req_psr2_sdp_prior_scanline` and scl lines while computing min guardband. (Jouni) - Use wake lines only for eDP with panel_replay and sel_update flags set. (Jouni) Bspec: 70151, 71477 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251017123504.2247954-2-ankit.k.nautiyal@intel.com
2025-10-17drm/xe/xe3p: Dump CSMQDEBUG registerWang Xin
The CSMQDEBUG is useful for the development of MQ feature. Start dumping the debug register. Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Wang Xin <x.wang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-10-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe: Dump CURRENT_LRCA registerWang Xin
Add CURRENT_LRCA to register dump to help debugging. Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Wang Xin <x.wang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-9-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p: Determine service copy availability from fuseMatt Roper
Xe3p introduces a dedicated SERVICE_COPY_ENABLE fuse register to reflect the availability of the service copy engines (BCS1-BCS8). Bspec: 74624 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-8-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p: Stop programming RCU_MODE's fixed slice mode settingMatt Roper
Since the hardware load balancing is no longer supported, the programming in RCU_MODE is no longer necessary. Bspec: 60382 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-7-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p_lpm: Handle MCR steeringMatt Roper
Xe3p_LPM's MCR steering has the same ranges and behavior as Xe3_LPM. However one register range that was reserved on Xe3_LPM has now become a unicast range (0x384200-0x38427F), so we need to stop consolidating the adjacent MCR ranges into a single table entry in the table. With this change to the Xe3_LPM table, we can continue to use the same table for both IP families. While we're touching this table, take the opportunity to fix a whitespace mistake and clarify that one of the other consolidated range entries includes a reserved range. Bspec: 76445 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-6-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p_lpm: Skip disabling NOA on unsupported IPsBalasubramani Vivekanandan
IP version 35 has removed "NOA Enable Signal" bit from RPM_CONFIG1 register. Skip clearing that bit on unsupported IPs. Bspec: 62391 Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-5-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe: Add GT_VER() to check version specific to gt typeLucas De Marchi
In some situations we will need to check the version of the specific gt being passed as argument, not if the device has a certain graphics/media version. This is extracted from a patch by Balasubramani Vivekanandan that may need some rework, but this helper is still useful for other enabling parts of Xe3p. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-4-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe: Drop CTC_MODE register readBalasubramani Vivekanandan
The warning was added for a condition that never triggered even for platforms prior to Xe2. It's not supported in Xe2 and in Xe3p the register is removed from the main GT. Just drop the entire function as it doesn't bring any benefit. Bspec: 62395 Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> [ Drop the entire check for CTC_MODE ] Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-3-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3p: Add support for media IP versions 35.00 & 35.03Shekhar Chauhan
Xe3p_LPM/Xe3p_HPM are very similar to Xe3_LPM on the kmd interface, so it can use the same descriptor structure. Add both 35.00 and 35.03 IP versions. BSpec: 74201, 74202, 77977, 77979 Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-2-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-17drm/xe/xe3: Add support for graphics IP versions 30.04 & 30.05Shekhar Chauhan
Add graphics IP versions 30.04 & 30.05 and initial workarounds for these IP versions. BSpec: 74201 Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-1-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-15 04:57:03 +0000