summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-10-21drm/amd/display: add dccg dfs mask defCharlene Liu1-0/+8
[why] add some register masks for DCCG Reviewed-by: Yihan Zhu <yihan.zhu@amd.com> Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amd/display: Remove unused field in DMLAlvin Lee1-1/+0
Remove unused fields. Reviewed-by: Austin Zheng <austin.zheng@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amd/display: Fix NULL pointer dereferenceMeenakshikumar Somasundaram1-1/+2
[Why] On a mst branch with multi display setup, dc context is obselete after updating the first stream. Referencing the same dc context for the next stream update to fetch dc pointer leads to NULL pointer dereference. [How] Get the dc pointer from the link rather than context. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amd/display: add dispclk ramping to dcn35.Charlene Liu1-0/+12
[why] this is a required logic based on HW programming guide. tested/ported on dcn401. Reviewed-by: Yihan Zhu <yihan.zhu@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amd/display: Add debug option to override EASF scaler tapsSamson Tam3-0/+18
[Why & How] Add new option override_easf to use in_taps instead of internal taps policy for debugging Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Samson Tam <Samson.Tam@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amd/display: fix duplicate aux command with AMD aux backlightHarry VanZyllDeJong1-1/+2
when using AMD aux backlight control, we avoid sending backlight update commands to DMUB firmware because it is controlled by aux commands in driver. Reviewed-by: Iswara Nagulendran <iswara.nagulendran@amd.com> Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Harry VanZyllDeJong <hvanzyll@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amdgpu: Add ras module eeprom safety watermark checkYiPeng Chai1-0/+4
Add ras module eeprom safety watermark check. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amdgpu: Avoid hive seqno increment in legacy rasYiPeng Chai1-0/+3
The hive->event_mgr variable is used by both ras module and legacy ras. To ensure the continuity of hive seqno growth, after enabling ras module, it is forbidden to operate the event_mgr variable in legacy ras. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amdgpu: Add poison consumption sequence numbers for gfx and sdmaYiPeng Chai1-1/+6
Add poison consumption sequence numbers for gfx and sdma. V3: Use RAS_EVENT_LOG to print ras log info. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amdgpu: Avoid loading bad pages into legacy rasYiPeng Chai1-0/+3
When ras module is enabled, the bad pages will be loaded by ras module. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amdgpu: add ras module rma checkYiPeng Chai1-0/+3
Add ras module rma check. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amdgpu: Improve ras fatal error handling functionYiPeng Chai3-9/+14
In multi-gpu case, a fatal error will generate several fatal error interrupts. After improving this function, the ras module can reuse this function to only handle the first interrupt. V3: Initialize event_id using RAS_EVENT_INVALID_ID. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-21drm/amdgpu: Intercept ras interrupts to ras moduleYiPeng Chai4-4/+35
Intercept ras interrupts to ras module. V2: Change function names in ras module. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-20drm/i915/panic: fix panic structure allocation memory leakJani Nikula1-12/+13
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 Bhadane1-3/+7
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 Larumbe4-41/+41
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 Larumbe2-2/+0
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 Larumbe1-0/+1
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 Larumbe4-13/+16
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 Larumbe2-15/+8
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 Larumbe1-5/+44
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 Larumbe1-5/+6
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 Larumbe4-6/+17
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 Larumbe1-6/+18
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 Larumbe1-2/+13
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 Larumbe11-157/+146
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 Stone1-9/+15
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 Stone1-19/+19
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 Stone1-2/+1
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 Stone1-0/+6
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 Stone1-9/+9
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 Ryhl53-197/+335
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 Ryhl1-91/+19
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 Ryhl1-0/+190
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-19drm/xe/xe3p: Add xe3p EU stall data formatHarish Chegondi1-2/+26
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-19drm/xe/xe3p_xpc: Setup PAT tableMatt Roper1-1/+95
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-19drm/xe/xe3p_xpc: Skip compression tuning on platforms without flatccsMatt Roper3-3/+25
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-19drm/xe/xe3p_xpc: Add support for compute walker for non-MSIxLucas De Marchi2-0/+7
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-19drm/xe/irq: Check fuse mask for media enginesLucas De Marchi2-3/+17
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-19drm/xe/irq: Rename bits used with all enginesLucas De Marchi4-8/+8
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-19drm/xe/irq: Split irq mask per engine classLucas De Marchi1-26/+47
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-19drm/xe/irq: Rename fuse mask variablesLucas De Marchi1-12/+18
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-19drm/xe/xe3p_xpc: Add MCR steeringMatt Roper2-2/+75
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-19drm/xe/xe3p_xpc: Add L3 bank maskFei Yang1-1/+5
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-19drm/xe/xe3p_xpc: Add Xe3p_XPC IP definitionBalasubramani Vivekanandan1-0/+8
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-19drm/xe/nvls: Attach MOCS table for NVL-SDnyaneshwar Bhadane1-0/+1
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 Zimmermann9-37/+31
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-18drm/xe/nvl: Define NVL-S platformMatt Roper2-0/+13
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 Nautiyal1-3/+1
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 Nautiyal1-2/+56
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
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-05 06:10:29 +0300