summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
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>
2025-10-17drm/i915/dp: Fix panel replay when DSC is enabledImre Deak
Prevent enabling panel replay if the sink doesn't support this due to DSC being enabled. Panel replay has two modes, updating full frames or only selected regions of the frame. If the sink doesn't support Panel Replay in full frame update mode with DSC prevent Panel Replay completely if DSC is enabled. If the sink doesn't support Panel Replay only in the selective update mode while DSC is enabled, it will still support Panel Replay in the full frame update mode, so only prevent selective updates in this case. v2: - Use Panel Replay instead of PR in debug prints. (Jouni) - Rebase on change tracking the link DSC state in the crtc state. Cc: Jouni Högander <jouni.hogander@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14869 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-8-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the linkImre Deak
The state of all the CRTCs on an MST link must be recomputed, if DSC gets enabled on any of the CRTCs on the link. For instance an MST docking station's Panel Replay capability may depend on whether DSC is enabled on any of the dock's streams (aka CRTCs). To assist the Panel Replay state computation for a CRTC based on the above, track in the CRTC state if DSC is enabled on any CRTC on an MST link. The intel_link_bw_limits::force_fec_pipes mask is used for a reason similar to the above: enable FEC on all CRTCs of a non-UHBR (8b10b) MST link if DSC is enabled on any of the link's CRTCs. The FEC enabled state for a CRTC doesn't indicate if DSC is enabled on a UHBR MST link (FEC is always enabled by the HW for UHBR, hence it's not tracked by the intel_crtc_state::fec_enable flag for such links, where this flag is always false). Based on the above, to be able to determine the DSC state on both non-UHBR and UHBR MST links, track the more generic DSC-enabled-on-link state (instead of the FEC-enabled-on-link state) for each CRTC in intel_link_bw_limits. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-7-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Track DSC enabled status on the MST linkImre Deak
Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI) this will always match the CRTC's DSC state, those links having only a single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will be as follows: CRTC#0: - compression_enable = true - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b CRTC#1: - compression_enable = false - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b This patch only sets compression_enabled_on_link for CRTC#0 above and enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b MST link. A follow-up change will make sure that the state of all the CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on any CRTC, setting compression_enabled_on_link and fec_enable for these. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-6-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC configImre Deak
Reuse the DP-SST helper to compute the state for the FEC enabled state for DP-MST as well. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-5-imre.deak@intel.com
2025-10-17drm/i915/dp: Export helper to determine if FEC on non-UHBR links is requiredImre Deak
Export the helper function to determine if FEC is required on a non-UHBR (8b10b) SST or MST link. A follow up change will take this into use for MST as well. While at it determine the output type from the CRTC state, which allows dropping the intel_dp argument. Also make the function return the required FEC state, instead of setting this in the CRTC state, which allows only querying this requirement, without changing the state. Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that the function determines if FEC is required on an 8b10b link (on 128b132b links FEC is always enabled by the HW implicitly, so the function will return false for that case). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-4-imre.deak@intel.com
2025-10-17drm/i915/dp: Ensure the FEC state stays disabled for UHBR linksImre Deak
Atm, in the DP SST case the FEC state is computed before intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr() will always return false and the FEC state will be always computed assuming a non-UHBR link. This happens to work, since the FEC state is recomputed later in intel_dp_mtp_tu_compute_config(), where port_clock will be set already, so intel_crtc_state::fec_enable will be reset as expected for UHBR. This also depends on link rates being tried in an increasing order (i.e. from non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus intel_crtc_state::fec_enable being set for the non-UHBR rates and getting reset for the first UHBR rate as expected. A follow-up change will reuse intel_dp_fec_compute_config() for the DP MST state computation, prepare for that here, making sure that the function determines the correct intel_crtc_state::fec_enable=false state for UHBR link rates based on the above. The DP SST and MST state computation should be further unified to avoid computing/setting the intel_crtc_state::fec_enable state multiple times, but that's left for a follow-up change. For now add only code comments about this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-3-imre.deak@intel.com
2025-10-17drm/i915/dsc: Add helper to enable the DSC configuration for a CRTCImre Deak
Add a helper to enable the DSC compression configuration for a CRTC. Follow-up changes will introduce tracking for the same DSC state on the whole link, which will need to be set whenever DSC is enabled for the CRTC. Also, according to the above, when querying the DSC state on the link, both the CRTC's and the link's DSC state must be considered. Setting the DSC configuration for a CRTC and querying the DSC configuration for the link (added by follow-up changes) is better done via helper functions based on the above, prepare for that here. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-2-imre.deak@intel.com
2025-10-17drm/xe/pf: Allow to restore auto-provisioning modeMichal Wajdeczko
After doing tweaks to the VFs provisioning we may want to restore back the auto-provisioning mode. Allow that unless VFs are still enabled. This can be also used to release all VFs resources. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-5-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Disable auto-provisioning if changed using debugfsMichal Wajdeczko
When we attempt to tweak VFs configurations using debugfs, stop assuming that VFs need auto-(un)provisioning. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-4-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Automatically provision VFs only in auto-modeMichal Wajdeczko
We shouldn't attempt to auto-provision VFs once we allow other provisioning methods. Make the code aware of the new condition. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-3-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Promote VFs provisioning helpersMichal Wajdeczko
As we plan to add more VFs provisioning methods, start moving related code into single place. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-2-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Always expose VRAM provisioning data on discrete GPUsLukasz Laguna
Currently, VRAM provisioning data is only exposed if the device supports LMTT. While it should not be possible to modify VRAM provisioning on platforms without LMTT, it is still useful to be able to read the VRAM provisioning data on all discrete GPU platforms. Expose the VRAM debugfs attributes whenever running on dGFX, adjusting file permissions to read only when LMTT is not available. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251016122233.3789-1-lukasz.laguna@intel.com
2025-10-17drm/panthor: Fix kernel panic on partial unmap of a GPU VA regionAkash Goel
This commit address a kernel panic issue that can happen if Userspace tries to partially unmap a GPU virtual region (aka drm_gpuva). The VM_BIND interface allows partial unmapping of a BO. Panthor driver pre-allocates memory for the new drm_gpuva structures that would be needed for the map/unmap operation, done using drm_gpuvm layer. It expected that only one new drm_gpuva would be needed on umap but a partial unmap can require 2 new drm_gpuva and that's why it ended up doing a NULL pointer dereference causing a kernel panic. Following dump was seen when partial unmap was exercised. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078 Mem abort info: ESR = 0x0000000096000046 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000 [000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000 Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP <snip> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor] lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor] sp : ffff800085d43970 x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000 x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000 x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010 x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58 x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7 x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001 x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078 Call trace: panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor] op_remap_cb.isra.22+0x50/0x80 __drm_gpuvm_sm_unmap+0x10c/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xb4/0x3d0 [panthor] panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor] panthor_ioctl_vm_bind+0x160/0x4a0 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x240/0x500 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 Signed-off-by: Akash Goel <akash.goel@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20251017102922.670084-1-akash.goel@arm.com
2025-10-17drm/xe/uapi: Hide the madvise autoreset behind a VM_BIND flagThomas Hellström
The madvise implementation currently resets the SVM madvise if the underlying CPU map is unmapped. This is in an attempt to mimic the CPU madvise behaviour. However, it's not clear that this is a desired behaviour since if the end app user relies on it for malloc()ed objects or stack objects, it may not work as intended. Instead of having the autoreset functionality being a direct application-facing implicit UAPI, make the UMD explicitly choose this behaviour if it wants to expose it by introducing DRM_XE_VM_BIND_FLAG_MADVISE_AUTORESET, and add a semantics description. v2: - Kerneldoc fixes. Fix a commit log message. Fixes: a2eb8aec3ebe ("drm/xe: Reset VMA attributes to default in SVM garbage collector") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: "Falkowski, John" <john.falkowski@intel.com> Cc: "Mrozek, Michal" <michal.mrozek@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251015170726.178685-2-thomas.hellstrom@linux.intel.com
2025-10-17drm/xe: Retain vma flags when recreating and splitting vmas for madviseThomas Hellström
When splitting and restoring vmas for madvise, we only copied the XE_VMA_SYSTEM_ALLOCATOR flag. That meant we lost flags for read_only, dumpable and sparse (in case anyone would call madvise for the latter). Instead, define a mask of relevant flags and ensure all are replicated, To simplify this and make the code a bit less fragile, remove the conversion to VMA_CREATE flags and instead just pass around the gpuva flags after initial conversion from user-space. Fixes: a2eb8aec3ebe ("drm/xe: Reset VMA attributes to default in SVM garbage collector") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251015170726.178685-1-thomas.hellstrom@linux.intel.com
2025-10-17drm/gpusvm, drm/xe: Allow mixed mappings for userptrMatthew Brost
Compute kernels often issue memory copies immediately after completion. If the memory being copied is an SVM pointer that was faulted into the device and then bound via userptr, it is undesirable to move that memory. Worse, if userptr is mixed between system and device memory, the bind operation may be rejected. Xe already has the necessary plumbing to support userptr with mixed mappings. This update modifies GPUSVM's get_pages to correctly locate pages in such mixed mapping scenarios. v2: - Rebase (Thomas Hellström) v3: - Remove Fixes tag. v4: - Break out from series since the other patch was merged. - Update patch subject, ensure dri-devel and Maarten are CC'd. Cc: Maarten Lankhorst <maarten.lankhorst@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251015120320.176338-1-thomas.hellstrom@linux.intel.com Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-10-17Merge tag 'drm-xe-fixes-2025-10-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Increase global invalidation timeout to handle some workloads (Kenneth Graunke) - Fix NPD while evicting BOs in an array of VM binds (Matthew Brost) - Fix resizable BAR to account for possibly needing to move BARs other than the LMEMBAR (Lucas De Marchi) - Fix error handling in xe_migrate_init() (Thomas Hellström) - Fix atomic fault handling with mixed mappings or if the page is already in VRAM (Matthew Brost) - Enable media samplers power gating for platforms before Xe2 (Vinay Belgaumkar) - Fix de-registering exec queue from GuC when unbinding (Matthew Brost) - Ensure data migration to system if indicated by madvise with SVM (Thomas Hellström) - Fix kerneldoc for kunit change (Matt Roper) - Always account for cacheline alignment on migration (Matthew Auld) - Drop bogus assertion on eviction (Matthew Auld) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/rch735eqkmprfyutk3ux2fsqa3e5ve4p77w7a5j66qdpgyquxr@ao3wzcqtpn6s
2025-10-17Merge tag 'drm-misc-fixes-2025-10-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: ast: - Fix display output after reboot bridge: - lt9211: Fix version check core: - draw: Avoid color truncation - gpuvm: Avoid kernel-doc warning - sched: Avoid double free panthor: - Fix MCU suspend qaic: - Init bootlog in correct order - Treat remaining == 0 as error in find_and_map_user_pages() - Lock access to DBC request queue rockchip: - vop2: Fix destination size in atomic check Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251016141607.GA73919@linux.fritz.box
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-25 16:36:12 +0000