summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-06-29gpu: drm: nova: depend on nova-core and use its symbolsAlexandre Courbot
Make nova-core a build dependency of nova-drm, so its crate metadata is available and up-to-date when the latter is built. This is intended to be a workaround until the build system supports Rust cross-crate dependencies natively. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260622-nova-exports-v5-4-6191773fc977@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-29gpu: nova-core: emit Rust metadata for nova-drmAlexandre Courbot
Emit nova-core's crate metadata (libnova_core.rmeta) so that nova-drm can import nova-core's types and functions at compile time. This is intended to be a workaround until the build system supports Rust cross-crate dependencies natively. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260622-nova-exports-v5-3-6191773fc977@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-29gpu: nova-core: export Rust symbols for nova-drmAlexandre Courbot
Export nova-core's Rust symbols so nova-drm can resolve references to it when loaded as a module. This is done by generating declarations and EXPORT_SYMBOL_RUST_GPL() calls for Rust symbols referenced by nova-drm, and compiling them into the module as `nova_core_exports.o`. `nova_core_exports.o` declares every Rust symbol as `extern int`. Running `gendwarfksyms` on it would compute CRCs from those placeholder types instead of the real Rust ones, so make MODVERSIONS use this shim only for the export list, and derive CRCs from `nova_core.o`. This patch is intended to be a workaround until the build system supports Rust cross-crate dependencies natively. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260622-nova-exports-v5-2-6191773fc977@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-29gpu: build nova-core and nova-drm from drivers/gpu/MakefileAlexandre Courbot
A dependency between nova-core and nova-drm is about to be introduced, which requires nova-core to be built first. As this is not easily doable from separate directories, move both build targets to the first common parent, `drivers/gpu/Makefile`. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260622-nova-exports-v5-1-6191773fc977@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-29drm/i915/hdcp: require monotonically increasing seq_num_vJani Nikula
The HDCP 2.2 specification requires the seq_num_v to be monotonically increasing, and repeated seq_num_v needs to be treated as an integrity failure. Make it so. For the first message, seq_num_v must be zero, and is already checked. We can only check for less-than-or-equal for the subsequent messages, where hdcp2_encrypted is true. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: d849178e2c9e ("drm/i915: Implement HDCP2.2 repeater authentication") Cc: stable@vger.kernel.org # v5.2+ Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260625104407.1025614-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-29drm/i915/hdcp: check streams[] bounds before overflowJani Nikula
The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: e03187e12cae ("drm/i915/hdcp: MST streams support in hdcp port_data") Cc: stable@vger.kernel.org # v5.12+ Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260625170304.1104723-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-29Revert "drm/i915/psr: Allow SCL=0 on platforms with always-on VRR TG"Ankit Nautiyal
This reverts commit 4f1cab2e4863d96ce13b8d94151f4848e38c3d5b. Allowing SCL=0 on platforms with always-on VRR timing generator is causing underruns and other issues on PTL in some cases. SCL still needs to be non-zero in certain scenarios. Revert for now until this is better understood. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260622101736.2389991-1-ankit.k.nautiyal@intel.com
2026-06-28Merge tag 'v7.2-rc1' into drm-rust-nextDanilo Krummrich
Merge v7.2-rc1 into drm-rust-next to start the next cycle. Devres now requires T: 'static, which conflicts with shmem::Object using Devres<SGTableMap<T, C>> without that bound. Resolve by adding 'static as a supertrait to DriverObject and DeviceContext, which does not restrict any current use cases since DriverObject is always implemented on owned, refcounted types and DeviceContext is a sealed marker trait with only unit-type implementors. If DriverObject (or DeviceContext) ever becomes lifetime-parameterized (e.g. via a GAT for TTM backed objects), the 'static supertrait can be relaxed at that point. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-26Merge tag 'drm-fixes-2026-06-27' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "These are just the fixes from our fixes branch, all pretty small and scattered. sysfb: - drm/sysfb truncation and alignment fixes edid: - fix edid OOB read in tile parsing - increase displayid topology id to correct size nouveau: - fix error handling paths in nouveau amdxdna: - get_bo_info fix ivpu: - fix leak when error handling in ivpu" * tag 'drm-fixes-2026-06-27' of https://gitlab.freedesktop.org/drm/kernel: drm/sysfb: Avoid truncating maximum stride drm/sysfb: Return errno code from drm_sysfb_get_visible_size() drm/sysfb: Avoid possible truncation with calculating visible size drm/sysfb: Do not page-align visible size of the framebuffer drm/edid: fix OOB read in drm_parse_tiled_block() drm/nouveau: fix reversed error cleanup order in ucopy functions drm/nouveau/acr: fix missing nvkm_done() in error path of nvkm_acr_oneinit() accel/amdxdna: Use caller client for debug BO sync drm/displayid: fix Tiled Display Topology ID size accel/ivpu: fix HWS command queue leak on registration failure
2026-06-26Merge tag 'drm-next-2026-06-27' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm merge window fixes from Dave Airlie: "This is the merge window fixes from our next tree, i915/xe and amdgpu make up all of it. I've got a separate fixes pull from our fixes branch arriving after this. i915: - Fix corrupted display output on GLK, #16209 - Add missing Spectre mitigation for parallel submit IOCTL - MTL+ fix for DP resume - clear CRTC blobs after dropping refs - fix sharpness filter on DP MST xe: - Set TTM beneficial order to 9 in Xe - Several error path cleanups - Fix TDR for unstarted jobs on kernel queues - Several TLB invalidation fixes related to suspending LR queues - Some small RAS fixes - Multi-queue suspend fix for LR queues - Revert inclusion of NVL_S firmware amdgpu: - devcoredump fixes - SMU15 fix - Various irq put/get imbalance cleanup fixes - 8K panel fix - DCN3.5 fix - lockdep fix - Cleaner shader sysfs IB overflow fix - Async flip fixes - GET_MAPPING_INFO fix - CP_GFX_SHADOW fix - Ctx pstate handling fix - GTT bo move handling fixes - Old UVD BO placement fixes - GC9 mode2 reset fix - IH6.1 version fix - Soft IH ring fix amdkfd: - Fix doorbell/mmio double unpin on free - CRIU fixes - SMI event fixes - Sysfs teardown fix - Various boundary checking fixes - Various error checking fixes - SVM fix" * tag 'drm-next-2026-06-27' of https://gitlab.freedesktop.org/drm/kernel: (52 commits) drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable drm/i915/gem: Add missing nospec on parallel submit slot drm/amdgpu: Use system unbound workqueue for soft IH ring amdgpu/ih6.1: Fix minor version drm/amdkfd: Use exclusive bounds for SVM split alignment checks drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2 drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't at 0 (v2) drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions drm/amdgpu: Fix context pstate override handling drm/amdkfd: Use memdup_array_user to copy data from/to user space at kfd ioctls drm/amdkfd: check find_first_zero_bit before __set_bit on kfd->doorbell_bitmap drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format drm/amdgpu: convert amdgpu_vm_lock_by_pasid() to drm_exec drm/amdgpu: Don't use UTS_RELEASE directly drm/amdkfd: Fix NULL deref during sysfs teardown drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO ...
2026-06-26drm/i915: Refactor generic_handle_irq_safe() error messagesJonathan Cavitt
Refactor all error messages resulting from generic_handle_irq_safe() failures in I915 for clarity. v2: - Use drm_err_ratelimited() correctly (jcavitt) v3: - Use xe_err_ratelimited() instead (Jadav) - Split into patch series (jcavitt) v4: - Use suggested phrasing (Wajdeczko) v5: - s/PTR_ERR/ERR_PTR (jcavitt) Suggested-by: Raag Jadav <raag.jadav@intel.com> Suggested-by: Michal Wajdeczko <Michal.Wajdeczko@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260623202310.1023770-1-jonathan.cavitt@intel.com
2026-06-26drm/bridge: of-display-mode-bridge: Fix missing static const for the bridge ↵Damon Ding
funcs Add static qualifier for of_display_mode_bridge_funcs to resolve the sparse warning: drivers/gpu/drm/bridge/of-display-mode-bridge.c:54:25: sparse: sparse: symbol 'of_display_mode_bridge_funcs' was not declared. Should it be static? Also mark the structure const as required by devm_drm_bridge_alloc() parameter type constraints. Fixes: ba2db93cf3d5 ("drm/bridge: Move legacy bridge driver out of imx directory for multi-platform use") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606170744.FUStcWaB-lkp@intel.com/ Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260617080755.186368-1-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-06-26drm/{i915, xe}: move intel_hpd_cancel_work() to ↵Jani Nikula
intel_display_driver_remove_noirq() intel_hpd_cancel_work() gets called before intel_display_driver_remove_noirq(). Move it there. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/6be8d033a6c8d0038dc14100d3ee6612d6204770.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/{i915, xe}: move opregion cleanup to intel_display_driver_remove_nogem()Jani Nikula
The intel_opregion_cleanup() call should really be in display. Move it at the end of intel_display_driver_probe_noirq(). For xe, this is a completely non-functional change now that the noirq/nogem cleanup calls are in the right order. For i915, this only changes the relative order of intel_opregion_cleanup() and i915_perf_fini(), which should be of no consequence. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/8ccd49a5945e0560ba22079d686db1268e8e9f7f.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/xe/display: change order of intel_display_driver_remove_{nogem, noirq}() ↵Jani Nikula
calls The display driver init and cleanup calls are slightly asymmetric. The cleanup order should be intel_display_driver_remove_noirq() and intel_display_driver_remove_nogem(), not the other way around. This is also what i915 does. Follow suit in xe. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/afb11c4e11cc4d946f0360aaad1664d004a93f41.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/{i915, xe}: move opregion/dram/bw init to intel_display_driver_probe_noirq()Jani Nikula
The intel_opregion_setup(), intel_dram_detect(), and intel_bw_init_hw() calls should really be in display. Move them at the beginning of intel_display_driver_probe_noirq(). This is a completely non-functional change for xe. For i915, the init order changes slightly: - i915_pcode_init() will happen before intel_opregion_setup(). This should be of no consequence. - The intel_gvt_init() calls will happen before the mentioned functions. There's a lot going on in intel_gvt_init(), but it does not look like this should have dependencies on them either. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/aa37d6443516ae660c2de53aba8ca42e6e6d1a5c.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/i915: remove superfluous checks for pdev->msi_enabledJani Nikula
pci_disable_msi() checks for pdev->msi_enabled internally. There's no need to peek at pdev internals in i915. Remove them. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/71f61eee227178b61af9c1211be8545828a3f3ef.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/i915: move intel_display_device_probe() call a level higherJani Nikula
Having display probe be called from i915_driver_create() is slightly misleading, and an artefact from the past. Move the intel_display_device_probe() call a level higher. Use the shared PCI disable error path while at it. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/c97a8790a5cb1f6b10061286adad8148972c5b3b.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufsMatthew Auld
Currently, xe_display_bo_framebuffer_init() unconditionally attempts to apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with -EINVAL if the BO is already VM_BINDed. However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem to make much sense since CPU caching policy is entirely controlled by the exporter. Plus there is no place to set this flag, in the first place. Also this is not rejected if not yet vm_binded, but that seems arbitrary since setting or not setting FORCE_WC should a noop either way, at this stage, and whether it is currently VM_BINDed makes no difference. Currently if we run an app and offload rendering to an external dGPU, like NV or another xe device, the dma-buf passed back to the compositor (igpu) will be an actual external import from xe pov, and it will be missing FORCE_WC, and if the compositor side did a VM_BIND before turning into it into an fb the whole thing gets rejected. So it looks like we either need to reject outright, no matter what, or this usecase is valid and we need to loosen the restriction for sg buffers. Proposing here to loosen the restriction. Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919 Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260612170501.550816-2-matthew.auld@intel.com
2026-06-26drm/xe: Return error on non-migratable faults requiring devmemMatthew Brost
Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: 4208fac3dce5 ("drm/xe: Add more SVM GT stats") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260617135101.1245574-1-matthew.brost@intel.com
2026-06-26Merge tag 'drm-misc-fixes-2026-06-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2: - drm/sysfb truncation and alignment fixes. - fix edid OOB read. - fix error handling paths in nouveau - amdxdna get_bo_info fix. - increase displayid topology id to correct size. - fix leak when error handling in ivpu. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/2d17f718-43f5-4772-9c04-a975c9ad4bc3@linux.intel.com
2026-06-26Merge tag 'drm-intel-next-fixes-2026-06-25-1' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Fix corrupted display output on GLK, #16209 (Ville) - Add missing Spectre mitigation for parallel submit IOCTL (Joonas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/ajzIhInnHnGCwMlu@jlahtine-mobl
2026-06-25drm/tyr: remove imports available from preludeGary Guo
No functional changes intended. Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260610141359.1033755-1-gary@kernel.org Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-06-25drm/i915/dp_link_caps: s/lc/lce/Michał Grzelak
lc variable took it's name as an acronym from struct intel_dp_link_config. Rename the variable into lce since the struct was renamed into intel_dp_link_config_entry. Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260623224619.1949975-30-michal.grzelak@intel.com
2026-06-25drm/i915/hdmi: Remove CNP port F leftoversVille Syrjälä
Since CNL got nuked cnp_encoder_to_ddc_pin() will never see a port F. Remove the leftovers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260623125111.6632-7-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
2026-06-25drm/i915/gmbus: Drop the platform suffixes from GMBUS pinsVille Syrjälä
The modern GMBUS pin numbers are just a sequential set of numbers, so the platform suffixes don't really buy us anything. Let's just drop them. We'll keep the _TCx suffixes for pins 9+ since that's the way they always get used. v2: Deal with gvt Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260623141117.24115-1-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
2026-06-25drm/i915/gmbus: s/gmbus_pins_skl/gmbus_pins_spt/Ville Syrjälä
The GMBUS pin pair <-> GPIO mapping is purely a property of the PCH (on the platforms where GMBUS lives in the PCH). So rename gmbus_pins_skl[] to gmbus_pins_spt[] and apply it based on the presence of the correct PCH type. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260623125111.6632-5-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
2026-06-25drm/i915/gmbus: Add gmbus_pins_lpt_lp[]Ville Syrjälä
LPT/WPT-LP don't have as many GPIO pins as the -H variants. Add proper mapping for the -LP PCHs so that we can't end up poking at non-existent GPIOs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260623125111.6632-4-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
2026-06-25drm/i915/gmbus: s/gmbus_pins_bdw/gmbus_pins_lpt/Ville Syrjälä
The GMBUS pin pair <-> GPIO mapping is purely a property of the PCH (on the platforms where GMBUS lives in the PCH). So rename gmbus_pins_bdw[] to gmbus_pins_lpt[] and extend it to cover all platforms with LPT/WPT PCHs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260623125111.6632-3-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
2026-06-25drm/i915/gmbus: Rename GPIO pinsVille Syrjälä
Replace the alphabetical GPIOA,GPIOB,... with numeric GPIO_0,GPIO_1,... This makes the naming scheme agree with BSpec. No idea why the alphabetical naming was originally chosen as BSpec never used that convention for the GPIO pins. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260623125111.6632-2-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
2026-06-24drm/i915/dp_link_caps: Pass link_caps to common rate helpersImre Deak
Pass the link_caps pointer to the common rate helpers in intel_dp_link_caps.c, as it holds the state with the relevant information. Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-29-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Pass link_caps to config update/lookup helpersImre Deak
Pass the link_caps pointer to the update/lookup helpers in intel_dp_link_caps.c, as it holds the state with the relevant information. Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-28-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Pass link_caps to static functionsImre Deak
Pass the link_caps pointer to static functions in intel_dp_link_caps.c, as it holds the state with the relevant information. Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-27-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Move max link limits to link_capsImre Deak
Now that all users access the max link limits via helpers, move tracking of these limits from struct intel_dp to the link_caps state. Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-26-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Add helper to reset link_caps stateImre Deak
Add a helper to reset the link_caps state, removing all restrictions except user-forced parameters, re-allowing all supported configurations. Currently this only resets the maximum link limits, but follow-up changes will also re-enable configurations previously disabled on a per-configuration basis by fallback or other logic. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-25-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Add helper to reset max link limitsImre Deak
Add a helper to reset the link_caps::max_limits max link limits to the maximum common supported rate and lane count. This is needed by a follow-up change in the link training fallback code, which temporarily resets max_limits before searching for a fallback configuration. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-24-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Add helpers to set max link limitsImre Deak
Add intel_dp_link_caps_set_max_limits() to set the current maximum link limits (max bound over all allowed configurations) through the link caps API instead of direct accesses. This allows tracking the state internally within the link caps module. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-23-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Add helpers to get max link limitsImre Deak
Add intel_dp_link_caps_get_max_limits() to query the current maximum link limits (max bound over all allowed configurations) through the link caps API instead of direct accesses. This allows tracking the state internally within the link caps module. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-22-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Use max common lane count from link_capsImre Deak
Convert all users of intel_dp_max_common_lane_count() to query the maximum common lane count via the link capability API, in common with the link rate queries. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-21-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Track max common lane count in link_capsImre Deak
Pass the maximum common lane count to intel_dp_link_caps_update() and track it together with the supported link rates. This prepares for converting all users of intel_dp_max_common_lane_count() to query the value from the link caps module instead. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-20-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Move tracking of common rates to link_caps structImre Deak
Now that all users access the supported link rates via helpers, move tracking of these rates from struct intel_dp to the link_caps state. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-19-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Add helper to get common rate indexImre Deak
Add intel_dp_link_caps_common_rate_idx() to look up supported link rates tracked by the link_caps module by rate. This prepares for tracking these capabilities internally within the link caps module. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-18-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Add helper to get the number of supported link ratesImre Deak
Add intel_dp_link_caps_num_common_rates() to return the number of supported link rates tracked by the link_caps module. This prepares for tracking these capabilities internally within the link caps module. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-17-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Add helper to print all supported link ratesImre Deak
Add intel_dp_link_caps_print_rates() to print all the supported link rates tracked by the link_caps module. This prepares for tracking these capabilities internally within the link caps module. Suggested-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-16-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Pass supported link rates to link caps updateImre Deak
Pass the supported link rates explicitly to intel_dp_link_caps_update(). This prepares for tracking these capabilities internally within the link caps module. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-15-imre.deak@intel.com
2026-06-24drm/i915/dp: Factor out helper to get link rate capabilitiesImre Deak
Factor out a helper to get the supported link rates. This allows to gather all the link capabilities and pass these to the link capability module from a single place. A follow-up change will extend this to gather and pass the maximum lane count capability in the same way. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-14-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Rename helper updating the link configurationsImre Deak
Rename the helper updating link configurations to intel_dp_link_caps_update() to better reflect its functionality. Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-13-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Move link config tracking to link_capsImre Deak
Move tracking of the link configurations from struct intel_dp to struct intel_dp_link_caps. Previous changes moved the helpers operating on configurations to the link caps module, so the state can now be kept internal to that module. Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-12-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Move link config helpers to link capsImre Deak
Move the helpers handling link configurations to intel_dp_link_caps.c. Their functionality is part of the link capability logic and will be updated to use the link capability state in follow-up changes. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-11-imre.deak@intel.com
2026-06-24drm/i915/dp_link_caps: Move forced link params to link_capsImre Deak
Move tracking of the forced link parameters from struct intel_dp to struct intel_dp_link_caps. Previous changes made all users access these parameters through the link caps helpers, so the state can now be kept internal to the link caps module. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260616200849.3534628-10-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-08 18:24:54 +0000