summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-07-10drm/xe/guc: toggle paging engine support for NVL-S+Matthew Auld
NVL-S with latest GuC should be the first platform combo to support the special GUC_PAGING_CLASS feature. v2: - Update with the final GuC version v3: - Split VF vs PF versioning. Which is recommendation from GuC side. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-22-matthew.auld@intel.com
2026-07-10drm/xe/hw_engine: document top-down paging requirementMatthew Auld
We were doing this anyway, but going forward for paging engines, agreement is to always reserve BCS instances in top down fashion. This hopefully future proofs things for VFs, where in some low-level places it might only have the physical BCS instance from the hw pov. If we stick to a consistent mapping scheme, it should make it possible to determine if this is a special paging engine, or not. v2 (Daniele) - Give a concrete example, like with page fault descriptor Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-21-matthew.auld@intel.com
2026-07-10drm/xe/vf: wire up NUM_PAGING_ENGINE_INSTANCESMatthew Auld
When host PF writes the logical configuration for the GUC PAGING engine, the VF is meant to query it, and mirror it. Size of N means we have paging logical index range [0, N-1], with N fewer normal copy engines. Agreement is that PF will only spawn PAGING engines on NVL-S+, so this should be zero on older platforms, where we should simply fall back to the old behaviour. v2 (Sashiko): - We can't call use the guc_has_paging_engine() this early in the VF code. With that just unconditionally do the query, if the GuC is new enough and take the value as-is. With that drop the -1 special case and just let the upper layers figure out the rest. v3: - Also update xe_guc_klv_key_to_string. (Michal) - Add kernel-doc for xe_gt_sriov_vf_paging_engines(), plus other tweaks. (Michal) - Update with final GuC version. v4: - Just fallback to manual reserve when vf reported paging engines is zero. Will revisit in the future. v5 (Michal): - Convert the assert to a full abort if we ever see non-zero GuC paging engine count, on pre-nvl. - Move the VF hunk in guc_has_paging_engine() here. - Some small tweaks. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260626111520.487997-20-matthew.auld@intel.com
2026-07-10drm/xe/guc: handle submit mask with paging engineMatthew Auld
We need to re-map the submit mask so that we correctly account for the logical mask of paging engines, if the GUC_PAGING_CLASS is in play. We could also have multiple instances (possible on VF), so we need to handle that also. v2 (Daniele): - Move the implementation to guc_submit.c Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-19-matthew.auld@intel.com
2026-07-10drm/xe/guc: handle guc logical instance for paging engineMatthew Auld
In the GuC backend, we need a different logical instance when referring to the reserved paging engine. Under the hood, this is still just the same physical BSC engine, however from the GuC POV this is actually re-mapped to a separate GUC_PAGING_CLASS, with the logical index starting from zero. The idea is to not leak this into the upper layers, since this is GuC version specific, so the changes here are purely on the GuC side. No functional change. v2: - Add some kernel-doc to explain the usage. - Move the implementation to guc.c Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-18-matthew.auld@intel.com
2026-07-10drm/xe: refactor the paging engine setupMatthew Auld
On newer platforms, the paging configuration is now configured by the PF via the ADS object, where VF side should ensure that everything configured as GUC_PAGING_CLASS is correctly mirrored on VF side. For example PF could in theory reserve two BCS instances, and we expect VF to mirror that. With that move towards having a logical mask of all the paging engines, and also generalise selecting those engines, based on the number of paging engines. Also cache the first designated paging engine, which will makes things a little cleaner here, and in later patches. No functional changes for existing platforms. v2 (Sashiko): - Rework the loop slightly so that we don't needlessly check for the paging engine, before we have correctly set the logical instance. - Add a proper error return, if we encounter a bogus paging config. Thinking ahead to VF where the config is defined by the PF, we should just gracefully exit the probe sequence. v3: - Move paging_engines > copy_engines engines check to VF patch. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260626111520.487997-17-matthew.auld@intel.com
2026-07-10drm/xe/hw_engine: don't open code is_usm_hwe()Matthew Auld
Prefer is_usm_hwe() here. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-16-matthew.auld@intel.com
2026-07-10drm/xe/guc: add the plumbing for GUC_PAGING_CLASSMatthew Auld
On newer platforms, the GuC has a new engine class which we need to use to refer to the dedicated/reserved KMD BCS engine. With that, add the plumbing in the GuC backend to support GUC_PAGING_CLASS and GUC_CAPTURE_LIST_CLASS_PAGING. Currently this is still turned off. v2 (Daniele) - Also add adjust the capture list for hpg, so we account for nvl-s. - Move single paging engine assert to a more natural place. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-15-matthew.auld@intel.com
2026-07-10drm/xe/guc: refactor to_guc_class() to accept hweMatthew Auld
Rather than inferring the GuC engine class from the generic hw engine class, pass in the hwe itself, which gives the complete view, like instance etc. On future GuC versions, there is dedicated PAGING class to identify the KMD reserved BCS engine, so we need more info here in order to return the correct GuC specific engine class. With this everything should now be using the new hwe based interface. No functional changes. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-14-matthew.auld@intel.com
2026-07-10drm/xe/guc: refactor ads to use guc_classMatthew Auld
Currently in the lrc init flow on the ads side, we loop through each generic engine class and convert that to the respective guc engine class. However, with some upcoming changes, it will be better to go the opposite way and loop through every guc engine class, and convert that to the generic engine class. This will be needed in an upcoming patch where we have a new guc engine class that just matches up to the existing blitter/copy class, but needs to be treated as a separate entity from the normal copy lrc, when setting up the ADS. This also reworks engine_enable_mask to operate on the guc_class, that way we can easily filter out the PAGING vs normal BSC, when applicable. As a bonus, this also gets rid of two xe_engine_class_to_guc_class() users which will be helpful for the next patch. No functional changes. v2 (Daniele): - Simplify fill_engine_enable_masks() to just loop over all guc classes. Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-13-matthew.auld@intel.com
2026-07-10nouveau/vmm: fix another SPT/LPT raceDave Airlie
We've had an unknown Turing issue for a while with page faults since large pages and compression. I've got a patch series that syncs all our L2 handling with ogkm and it made this fault happen more. After writing a bunch of debugging patches, I spotted an invalid LPT entry where there should have been a valid one. A 64K MAP succeeds on a range, but a subsequent SPT put drops SPT refs across multiple ranges, We shouldn't assume all ranges where SPTEs go away will have the same sparse/invalid/valid state, just iterate over each instead and do the right thing. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Fixes: d19512f5abb1 ("nouveau/vmm: start tracking if the LPT PTE is valid. (v6)") Link: https://patch.msgid.link/20260615044737.3419585-1-airlied@gmail.com [ Properly format commit message. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org> (cherry picked from commit d008141ed4ce924167a03d46fbce9ad1fe4efa29) Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-07-10Merge tag 'drm-xe-fixes-2026-07-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix PTE index in xe_vm_populate_pgtable for chunked binds (Matt Brost) - Wait on external BO kernel fences in exec IOCTL (Matt Brost) - Remove duplicate include (Anas Khan) - Free madvise VMA array on L2 flush failure (Guangshuo Li) - Stub notifier_lock helpers when DRM_GPUSVM=n (Shuicheng Lin) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/alASIbW318Rl-HTv@fedora
2026-07-10Merge tag 'amd-drm-fixes-7.2-2026-07-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.2-2026-07-09: amdgpu: - PSP 15.0.9 update - SMU 15.0.9 update - VCN 5.3 fix - VI ASPM fix - Userq fix - lifetime fix for amdgpu_vm_get_task_info_pasid() - Gfx10 fix - SMU 14 fix amdkfd: - CRIU bounds checking fixes - secondary context id fix - Event bounds checking fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260709212303.15913-1-alexander.deucher@amd.com
2026-07-10Merge tag 'drm-misc-fixes-2026-07-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2-rc3: - Fix uaf in amdxdna mmap failure path. - A lot of deadlocks, access races and return value fixes in amdxdna. - Fix analogix_dp bitshifts during link training. - Use direct label in drm_exec. - Fix absent indirect bo handling in v3d. - Sync on first active crtc in fb_dirty, rather than first crtc. - Rework try_harder in the buddy allocator. - Make imagination function static to solve compiler warning. - Fix imagination error checking. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/71e5b48b-307f-47f5-8fd5-b60ea43e4196@linux.intel.com
2026-07-10Merge tag 'amd-drm-next-7.3-2026-07-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.3-2026-07-09: amdgpu: - RAS updates - PSP 15.0.9 update - SMU 15.0.9 update - VCN 5.3 fix - VI ASPM fix - Userq fix - lifetime fix for amdgpu_vm_get_task_info_pasid() - Gfx10 fix - SMU 14 fix - JPEG cleanups - MES fixes and cleanups - Header cleanups - Misc gfx fixes - Gfx pipe1 support on gfx11 APUs - BUG() and BUG_ON() removals amdkfd: - Merge fix - CRIU bounds checking fixes - secondary context id fix - Event bounds checking fix - Fix CWSR buffer mapping when in VRAM - Secondary context fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260709213953.16494-1-alexander.deucher@amd.com
2026-07-09drm/xe/guc: Define GuC firmware for NVL-SJulia Filipchuk
GuC firmware 70.71.0 (UAPI 1.37.2) is the first official GuC firmware for Novalake S. Recommend this version for NVL-S platform. Signed-off-by: Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260707192547.50535-12-julia.filipchuk@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-09drm/xe: Add support for WA 16029897822Daniele Ceraolo Spurio
The WA is implemented by the GuC, so we just need to enable it via the dedicated KLV. This WA is supported starting from GuC 70.69. Note that the GuC does not enable the relevant feature on NVL-S, so this WA can't (and shouldn't) be enabled on that platform. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com> Link: https://patch.msgid.link/20260706224344.2723462-4-daniele.ceraolospurio@intel.com
2026-07-09drm/xe: Add support for WA 22022079272Daniele Ceraolo Spurio
The WA is implemented by the GuC, so we just need to enable it via the dedicated KLV. This WA is supported starting from GuC 70.62. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260706224344.2723462-3-daniele.ceraolospurio@intel.com
2026-07-09drm/xe/guc: Handle GuC local uncorrectable error notificationsZhanjun Dong
Add support for the GuC uncorrectable local error G2H notification and opt in to the feature when the submission ABI exposes it. When the notification targets a known exec queue, treat it like an engine reset request and route it through the existing timeout cleanup path. This keeps the queue teardown, pending job cancellation and error capture in one place instead of open-coding a parallel recovery flow. Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260706234353.3874355-1-zhanjun.dong@intel.com
2026-07-09drm/imagination: fix error checking of pvr_vm_context_lookup()Luigi Santivetti
Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]--- Fixes: d2d79d29bb98 ("drm/imagination: Implement context creation/destruction ioctls") Cc: stable@vger.kernel.org Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260707-staging-ddkopsrc-2435-v1-1-24e160d44476@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-09drm/imagination: make pvr_fw_trace_init_mask_ops staticBen Dooks
The pvr_fw_trace_init_mask_ops is not used outside pvr_fw_trace.c so make it static to avoid the following sparse warning: drivers/gpu/drm/imagination/pvr_fw_trace.c:74:31: warning: symbol 'pvr_fw_trace_init_mask_ops' was not declared. Should it be static? Fixes: c6978643ea1c ("drm/imagination: Validate fw trace group_mask") Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Link: https://patch.msgid.link/20260703162338.2848039-1-ben.dooks@codethink.co.uk Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-09gpu/buddy: bail out of try_harder when alignment cannot be honouredArunpravin Paneer Selvam
The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew). Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Suggested-by: Christian König <christian.koenig@amd.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Timur Kristóf <timur.kristof@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld <matthew.auld@intel.com> Tested-by: John Olender <john.olender@gmail.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260709131050.1022759-1-Arunpravin.PaneerSelvam@amd.com
2026-07-09drm/panthor: Remove redundant drm_sched_job_cleanup() from the .free_job ↵Tvrtko Ursulin
callback After calling drm_sched_job_cleanup(), the free job callback releases its reference to the job, where the act of dropping the last reference will also call the drm_sched_job_cleanup() helper. We can therefore remove the redundant call from the .free_job callback. But we have to leave the "if (job->base.s_fence)" guard in job_release(), since that one not only handles the above described double cleanup, but also deals with all job cleanup paths which happen before the point the job was armed. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Steven Price <steven.price@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260702143745.79293-2-tvrtko.ursulin@igalia.com [tursulin: fixup commit text s/it's/its/]
2026-07-09drm/gpusvm: let the drm_gpusvm core context purely MM levelHonglei Huang
The core mechanism of drm_gpusvm is HMM, which is fundamentally an MM side subsystem. A drm_device, enters the picture on the device side at DMA mapping / GPU bind. So move struct drm_device from struct drm_gpusvm in drm_gpusvm. Let drm_gpusvm keep its core neutral and leave device side decisions to the driver. Make drm_gpusvm a pure MM level object. - Move the drm_device from struct drm_gpusvm. drm_device now stored in drm_gpusvm_pages. - Drop the drm parameter from drm_gpusvm_init() - Update the xe call sites in xe_svm_init() and other callers. drm_device does not disappear from the framework, it is relocated onto each drm_gpusvm_pages where DMA actually happens. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-6-honghuan@amd.com
2026-07-09drm/gpusvm: move struct drm_gpusvm_pages out of struct drm_gpusvm_rangeHonglei Huang
Since the pages the physical pages and MM VA range has been abstractly separated. Unbinding a single form of physical page from the MM VA range, brings flexibility to the drm gpu SVM framework, transfer the way of management of MM and device physical pages to the driver layer. framework's range embedded pages object and its range level wrappers have no users left. Remove the following: - Drop pages in drm_gpusvm_range. - Drop drm_gpusvm_range_pages_valid(), drm_gpusvm_range_get_pages() and drm_gpusvm_range_unmap_pages(); drivers should use the drm_gpusvm_pages helpers (drm_gpusvm_pages_valid, drm_gpusvm_get_pages, drm_gpusvm_unmap_pages) directly on a pages object they own. - Drop the notifier_seq seeding in drm_gpusvm_range_alloc(); drivers initialise notifier_seq on their own pages object. Update the DOC: overview to match the new model: document struct drm_gpusvm_pages and the driver owned 1:1 / N:1 layouts, and rewrite the usage examples to operate on a driver embedded pages object by the drm_gpusvm_pages helpers instead of the removed range level wrappers. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-5-honghuan@amd.com
2026-07-09drm/xe: have xe_svm_range embed one drm_gpusvm_pagesHonglei Huang
With drm_gpusvm_pages now self contained, make xe stop relying on the drm_gpusvm_range pages and take responsibility for the page lifecycle on the driver side. Driver side (xe): - Embed struct drm_gpusvm_pages in xe_svm_range and route all xe accesses through it instead of range->base.pages. - Initialise the embedded pages via drm_gpusvm_init_pages(), which binds the owning &xe->drm up front, and take over the page lifecycle: xe_svm_range_get_pages() calls drm_gpusvm_get_pages() directly; the notifier event_end and xe_svm_range_free() paths drive unmap/free on the embedded pages object. - Convert the open-coded userptr pages init in xe_userptr_setup() to the same drm_gpusvm_init_pages() helper. - Switch xe_svm_range_pages_valid() to drm_gpusvm_pages_valid(). Framework side (drm_gpusvm): - Add a small inline drm_gpusvm_init_pages() helper that records the owning drm_device and initialises the per-pages state, giving drivers a single hook to extend. - Export drm_gpusvm_pages_valid() to let driver owned pages can query mapping state without going through a range. - Lifecycle change: drm_gpusvm_range_remove() no longer *triggers* unmap/free of the embedded pages. The unmap/free logic itself stays in the framework -- drm_gpusvm_free_pages() still performs the DMA unmap (as an idempotent backstop) and frees the dma_addr array -- but the driver now owns *when* it runs, since the driver owns the drm_gpusvm_pages object. Side effect / contract: a driver that owns a drm_gpusvm_pages is now responsible for its lifecycle: drm_gpusvm_init_pages() before first use, and drm_gpusvm_free_pages() when the owner goes away. Xe does the latter from its ops->range_free callback, which the framework invokes once the range refcount drops to zero in drm_gpusvm_range_remove(). The timely DMA unmap for the IOMMU security model still happens in the notifier invalidate path via drm_gpusvm_unmap_pages(); the unmap inside drm_gpusvm_free_pages() is only a backstop for pages that were never invalidated. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-4-honghuan@amd.com
2026-07-09drm/gpusvm: embed struct drm_device into drm_gpusvm_pagesHonglei Huang
drm_gpusvm_pages is the layer that actually represents physical pages/mappings it owns the dma_addr array, the dma_iova_state... With the previous patch, so drm_gpusvm_pages is now strictly about physical pages and their DMA view. Since now the drm_gpusvm_pages instance is inherently bound to one specific drm_device, make that ownership explicit by giving drm_gpusvm_pages its own drm_device handle, and drive all DMA through it instead of through the gpusvm: - Add drm to struct drm_gpusvm_pages and route all DMA in drm_gpusvm_get_pages() / __drm_gpusvm_unmap_pages() through svm_pages->drm instead of gpusvm->drm. - Bind svm_pages->drm where the pages object is initialised (drm_gpusvm_range_alloc() and the xe userptr setup) and require it to be set on entry to drm_gpusvm_get_pages(); the dma device is immutable for the lifetime of the pages instance. A later patch introduces drm_gpusvm_init_pages() to centralise this. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-3-honghuan@amd.com
2026-07-09drm/gpusvm: split MM state flags out of drm_gpusvm_pages_flagsHonglei Huang
drm_gpusvm_pages_flags currently mixes two status: - MM / virtual-address state: whether the range has been (partially) unmapped by the Linux MM, these follow the lifetime of the VMA and are a single per VA range fact. - Device mapping state: has_devmem_pages and has_dma_mapping, which describe the current page mapping status held by device itself. Keeping both on the pages object blurs the semantics of the abstraction of pages and VA range. So move the MM state flags onto the range, and keep drm_gpusvm_pages_flags strictly for mapping state. - Introduce drm_gpusvm_range_flags { migrate_devmem, unmapped, partial_unmap } on drm_gpusvm_range. - Shrink drm_gpusvm_pages_flags to just has_devmem_pages and has_dma_mapping. Side effect: drivers now need to check the unmap flags in the driver itself to avoid handling the unmapped pages. Mirror that bit onto drm_gpusvm_pages so the framework can still short circuit drm_gpusvm_get_pages() under the notifier lock, and make drm_gpusvm_range_set_unmapped() propagate it to the backing pages. This follows Matt's review fixup for the v0 series; see the Link below. Like drm_gpusvm_pages_flags, drm_gpusvm_range_flags unions its bits with a u16 __flags member. Build the new value in a local copy and publish it with a single WRITE_ONCE() on __flags, and have the lockless readers use READ_ONCE(), so concurrent bitfield access stays data-race free and KCSAN quiet. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://gitlab.freedesktop.org/mbrost/xe-kernel-driver-svn-perf-6-15-2025/-/commit/623f6a50c037d9e44f6c9fbe6859a0ba7ad50177 Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-2-honghuan@amd.com
2026-07-09drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=nShuicheng Lin
When CONFIG_DRM_GPUSVM=n (e.g. um-allyesconfig), the only caller of xe_pt_svm_userptr_notifier_lock() is compiled out, triggering: drivers/gpu/drm/xe/xe_pt.c:1418:13: warning: 'xe_pt_svm_userptr_notifier_lock' defined but not used [-Wunused-function] The helpers cannot simply be removed in this case: the matching xe_pt_svm_userptr_notifier_unlock() is also referenced from xe_pt_update_ops_run(), which lives outside any DRM_GPUSVM ifdef and is gated only at runtime by pt_update_ops->needs_svm_lock. The symbol must exist in all builds. Provide empty static inline stubs for !DRM_GPUSVM, matching the pattern used by xe_svm_notifier_lock()/_unlock() in xe_svm.h. Fixes: dca6e08c923a ("drm/xe/userptr: Hold notifier_lock for write on inject test path") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606302210.QqcLbOEN-lkp@intel.com/ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630192221.2998168-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit 3359422bf0a1140e96d783a19a397686e580a3ca) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/xe: free madvise VMA array on L2 flush failureGuangshuo Li
xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas(). After get_vmas() succeeds with at least one VMA, error paths must go through free_vmas so the array is released before the madvise details are destroyed. The L2 flush validation path added for PAT madvise rejects some SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on each failed ioctl. Jump to free_vmas instead, matching the other validation failure paths after get_vmas() has succeeded. Fixes: 4f39a194d41e ("drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimization") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260708073422.725186-1-lgs201920130244@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit c3a1c3579b1250060da73507a4acef712974c78a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/xe: remove duplicate <kunit/test-bug.h> includeAnas Khan
xe_pci.c includes <kunit/test-bug.h> twice, separated only by the <kunit/test.h> include. Drop the redundant second include; this is a non-functional cleanup flagged by scripts/checkincludes.pl. Fixes: 6cad22853cb8 ("drm/xe/kunit: Add stub to read_gmdid") Signed-off-by: Anas Khan <anxkhn28@gmail.com> Link: https://patch.msgid.link/20260702112820.34675-1-anxkhn28@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 84ed5b0a925721aaf069d36e18a99db966ff4e80) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/xe: Wait on external BO kernel fences in exec IOCTLMatthew Brost
Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260702215805.4011228-1-matthew.brost@intel.com (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked bindsMatthew Brost
xe_vm_populate_pgtable() indexed the source PTE array (update->pt_entries) by the per-call loop counter, assuming each call starts at the first entry of the update. That holds for the CPU bind path (xe_migrate_update_pgtables_cpu), which populates a whole update in a single call, but not for the GPU bind path: write_pgtable() splits an update into MAX_PTE_PER_SDI (510) sized MI_STORE_DATA_IMM chunks, invoking the populate callback once per chunk with an advancing qword_ofs but a fresh command- buffer destination pointer. As a result, every chunk after the first re-read pt_entries from index 0 instead of from its true offset, so PTEs beyond the first 510 entries of a single update were programmed with the wrong physical pages, shifting the mapping by exactly MAX_PTE_PER_SDI pages. This stayed latent because a single update only exceeds 510 qwords when a large (e.g. 2M) region is bound as individual 4K PTEs rather than a single huge-page entry, which happens when the backing store is sufficiently fragmented. It was surfaced by the BO defrag path, which deliberately rebinds such fragmented ranges via the GPU bind path, producing deterministic data corruption offset by 510 pages. Index pt_entries by the chunk's absolute offset relative to update->ofs so both the CPU and GPU paths pick the correct entries. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260702012434.3861171-1-matthew.brost@intel.com (cherry picked from commit e6f2d0b757c4fb577a513c577140109d1d292a9a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-09drm/i915/kunit: DP link: add fallback testsImre Deak
Add KUnit tests for DP link fallback selection across eDP, SST, and MST. Verify that the fallback logic properly selects the maximum allowed configuration, iterates through allowed configurations, and disables failed configs as expected. These tests include UHBR vs. non-UHBR conditions, MST vs. SST mode, and validate that subsequent fallback selections respect the updated allowed configuration mask. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-35-imre.deak@intel.com
2026-07-09drm/i915/kunit: DP link: add update config testsImre Deak
Add KUnit tests for link_caps updates shrinking or expanding the supported rates and lane counts. The tests also cover updates with disabled configurations, including random shrink and expand sequences, to verify that disabled state, allowed configurations, ordering, and max limits stay consistent across updates. v2: Remove test cases for the now unused merge update mode. v3: - Test config iteration in lane count, rate order as well. - Keep space after comma in code comment. (Michał) Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-4-imre.deak@intel.com
2026-07-09drm/i915/kunit: DP link: add baseline fixed table reference testImre Deak
Add a simple baseline test for DP link caps iteration using a fixed standard DP configuration table. This provides a minimal validity check, independent of more complex test setups, verifying the iterator returns expected configurations in ascending and descending order. v2: Unchanged. v3: Test config iteration in lane count, rate order as well. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-3-imre.deak@intel.com
2026-07-09drm/i915/kunit: Export link training and caps funcs for testingImre Deak
Export the link caps and link training helpers needed by the DP link KUnit tests. Use test ops tables instead of exporting the helpers directly, avoiding symbol name collisions between the i915 and xe builds of the shared display code. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-32-imre.deak@intel.com
2026-07-09drm/i915/kunit: Setup DP link test contextImre Deak
Initialize a reusable test context for DP link KUnit tests. Sets up minimal device, connector, encoder, and DP structures, and seeds the pseudo-random generator for deterministic test runs. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-31-imre.deak@intel.com
2026-07-09drm/xe/kunit: Build DP link display testsImre Deak
Hook the shared i915 display DP link KUnit tests into the xe display test build. Build the shared display test source from the i915 display test directory when xe display support is enabled. v2: Unchanged. v3: Add SPDX license header. (Michał) Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-2-imre.deak@intel.com
2026-07-09drm/xe/kunit: Add display test configImre Deak
Add a separate xe KUnit config for display tests. The existing xe .kunitconfig builds xe statically, which is suitable for non-display xe tests. The display code can only be enabled for xe when xe is built as a module, so add a separate display config with DRM_XE=m and DRM_XE_DISPLAY=y. This can be folded back into the main xe KUnit config once the display code becomes a separate module. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-29-imre.deak@intel.com
2026-07-09drm/i915/kunit: Add DP link test stubImre Deak
Add a Kunit stub test module for DP link test cases. v2: Add missing module license. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-28-imre.deak@intel.com
2026-07-09drm/i915/kunit: Enable KUnit testsImre Deak
Add KUnit configuration for i915 and a local .kunitconfig to run the tests. v2: Unchanged. v3: Remove kconfig options for kernel debug. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-1-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Disable failed config during fallbackImre Deak
Disable the link configuration that failed training when selecting fallback parameters. Fallback still selects the next configuration using the existing fallback order, but now also removes the failed configuration from the allowed set. Functionally, this only affects the case where an MST <-> SST mode switch occurs on the same root connector: previously, a configuration that failed training in one mode could be reused in the other mode due to the differing config iteration orders. The current fallback logic also sets a temporary maximum link limit across the allowed configurations to constrain subsequent modesets. This legacy behavior is preserved for now; it will be removed once the fallback logic relies solely on the individually disabled configurations to restrict the allowed set. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-26-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Use config iterator for fallbackImre Deak
Switch the fallback loop to use the link configuration iterator to select a fallback configuration. This also allows unexporting and removing from the link caps interface all the common link rate query helpers and the helpers that accept or return a link configuration index. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-25-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Reset the max link limits in the fallback codeImre Deak
The target maximum rate/lane count selected by the fallback logic may exceed the current link_caps max_limits' rate/lane count, the latter of which are used as a limit by the lookup functions when filtering allowed configurations. To ensure the fallback search finds all relevant candidates, temporarily reset the link_caps max_limits to the maximum common supported capabilities. After the fallback search completes, set the link_caps max_limits to the configuration selected by the fallback logic, as before, determining the allowed configurations for a subsequent modeset. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-24-imre.deak@intel.com
2026-07-09drm/i915/dp: Remove min/max link config limitsImre Deak
Remove the min/max rate and lane count fields from struct link_config_limits after all state computation is converted to use the configuration filter. A simple min/max range cannot fully describe the valid configuration set once individual configurations are disabled (for example by fallback), as it may allow combinations that are not actually valid. The configuration filter, on the other hand, always represents a consistent set of valid configurations. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-23-imre.deak@intel.com
2026-07-09drm/i915/dp_mst: Use link caps for MST DSC config selectionImre Deak
Use the link caps helper to select the maximum DP MST link configuration for DSC computation, instead of using the separate max rate and lane count limits, which may not form a valid configuration after individual configs are disabled by fallback. Also look up the maximum rate for state computation via the configuration mask when checking the DSC hblank expansion quirk. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. The state computation should likely consider all allowed configurations, as noted in the code comment; for now keep the existing DP MST DSC behavior of selecting the maximum BW configuration determined by the MST connector BW config iteration order. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-22-imre.deak@intel.com
2026-07-09drm/i915/dp_mst: Use link caps for non-DSC config selectionImre Deak
Use the link caps helper to select the maximum MST link configuration for non-DSC computation, instead of using the separate max rate and lane count limits, which may not form a valid configuration after individual configs are disabled by fallback. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. In some cases all configurations should be considered, as noted in the code comment; for now keep the existing behavior of selecting the maximum bandwidth configuration as determined by the MST connector's BW config iteration order. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-21-imre.deak@intel.com
2026-07-09drm/i915/dp: Use link caps for eDP DSC config selectionImre Deak
Use the link caps helper to select the maximum eDP link configuration for DSC computation, instead of using the separate max rate and lane count limits, which may not form a valid configuration after individual configs are disabled by fallback. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. The state computation should likely consider all allowed configurations, as noted in the code comment; for now keep the existing eDP DSC behavior of selecting the maximum configuration determined by the eDP connector rate / lane config iteration order. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-20-imre.deak@intel.com
2026-07-09drm/i915/dp: Iterate configurations via link_caps for SST DSCImre Deak
Use the link caps configuration iterator for DP SST link configuration computation for DSC mode. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. The iteration preserves the DP SST connector rate/lane ordering used by the current code. This also allows removing the now unused common rate count helper. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-19-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-08 22:46:49 +0000