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
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
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
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
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
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
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
Use the link caps configuration iterator for DP SST link configuration
computation for non-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-18-imre.deak@intel.com
Use the link caps configuration mask when applying DP compliance test
link parameters during state computation.
Preserve the legacy behavior of falling back to all configurations with
the requested lane count if the requested rate and lane count pair is
not allowed.
In case no valid configuration is found fail the modeset.
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-17-imre.deak@intel.com
Query the maximum link BW configuration via the link caps interface to
compute the available TBT bandwidth. Unlike the max common link params
used so far for this, the max BW config also accounts for any forced
link parameters.
This makes the max BW link config query uniform across mode validation
and TBT BW calculation, and allows unexporting the
intel_dp_link_caps_max_common_lane_count() helper.
v2: Use the max BW link configuration, instead of the max link limits.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-16-imre.deak@intel.com
Query the maximum link BW configuration during mode validation and MST
link probing directly from intel_dp_link_caps_get_max_bw_config(),
instead of using the intel_dp_max_link_rate() and
intel_dp_max_lane_count() helpers.
This makes the max BW link config query uniform across mode validation
and TBT BW calculation, and allows unexporting the
intel_dp_max_link_rate()/intel_dp_max_lane_count() helpers.
v2: Use the max BW link configuration, instead of the max link limits.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-15-imre.deak@intel.com
Add link_config_filter to link_config_limits to track the set of valid
link configurations during modeset state computation. Keep the existing
min/max rate and lane count limits for now, until all users are
converted to use the configuration filter.
Add the helpers required to select the maximum configuration from the
currently allowed configuration set. This will be used by follow-up
changes as well to query the maximum link configuration without having
to iterate the configurations.
v2:
- Rebase on changes using a filter object instead of a mask of
configuration indices.
- Rebase on changes using an iteration object.
v3:
- Add TODO: label to code comment about min/max link config limit
removal. (Luca)
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-13-imre.deak@intel.com
Re-enable link configurations after sink capabilities change or the link
got reset before updating the link capabilities (due to an RX_CAP_CHANGED
HPD IRQ for the currently connected sink, or a new sink getting
connected).
This makes resetting the link explicitly by calling
intel_dp_link_caps_reset() subsequently redundant; keep the existing
behavior wrt. this for now, adding only a TODO: to remove the explicit
reset.
While at it add documentation for intel_dp_link_caps_update().
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-10-imre.deak@intel.com
Add a filter for enabled link configurations to the link capability
state.
This allows fallback code to disable only the configuration that failed
link training, instead of constraining later modesets via maximum link
rate or lane count. The code only needs to exclude the failed
configuration from the allowed set; all other supported configurations
remain available.
Use the filter when computing the allowed configuration set and when
validating maximum link limits.
Follow-up changes will switch the fallback code to disable individual
configurations through this filter.
v2:
- Rebase on changes using a filter object instead of a mask of
configuration indices.
- Track the enabled configurations instead of the disabled ones.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-8-imre.deak@intel.com
Add validation in intel_dp_link_caps_set_max_limits() to ensure that
the new maximum rate and lane count leave at least one allowed
configuration.
The validation takes disabled configurations and active forced
parameters into account. Disabled configurations are not supported yet,
so that part has no effect for now.
At the moment this validation is also performed by the link training
fallback code, but that will be removed later, leaving only the link
caps module to perform the validation added in this patch.
v2: Rebase on changes using a filter object instead of a mask of
configuration indices.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-7-imre.deak@intel.com
Add helpers to iterate over the allowed and optionally filtered set of
link configurations in a given order.
Taking into account disabled configurations will be added later when
adding support for disabling configurations.
Use the BW order in descending direction by default.
v2:
- Keep the iteration state in an iteration object. (Jani)
- Use a filter object instead of exposing configuration indices. (Jani)
- Move changes adding helpers required to setup the iteration object to
this patch.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-5-imre.deak@intel.com
Add support for iterating configurations in either link rate/lane count
or lane count/link rate order. Both orders are required for DP SST
connector types: the former for computing the connector state during a
modeset, and the latter for selecting a fallback configuration after a
link training failure.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-4-imre.deak@intel.com
Both DP MST and UHBR SST require the audio component to use a real
cpu_transcoder (>= 0) value to identify the audio stream on a port.
For DP MST this was already handled; for UHBR SST it was not, causing
pin_eld_notify() to signal cpu_transcoder = -1 (the legacy SST sentinel)
and find_audio_state() to skip the per-transcoder entry for the UHBR
stream.
After suspend/resume or replug, the ELD lookup fails and audio goes
silent. Fix by detecting UHBR SST alongside DP MST when deciding
whether a real cpu_transcoder value must be used for audio state
addressing, in both the pin_eld_notify() signalling and the
find_audio_state() lookup paths.
--v2:
- Commit message and comment update. (Suraj)
- Change function name has_mst_transcoder. (Suraj)
- Avoid Live crtc access in find_audio_state. (Suraj)
--v3:
- Minor comment changes to avoid MST over 128b/132b confusion. (Suraj)
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260708113558.1863316-1-mitulkumar.ajitkumar.golani@intel.com
On Nova Lake A/B steppings the GOP breaks DP-Alt / native DP output
when TRANS_VTOTAL.Vtotal is programmed with a non-zero value, and the
initial hardware readout of that field on such systems ends up in
adjusted_mode.crtc_vtotal = 1 -- tripping the DSB scanline WARN in
assert_dsl_ok() during intel_initial_commit.
Keep TRANS_VTOTAL.Vtotal at 0 on Nova Lake pre-C0 (A0..B3) in both
transcoder timing paths, and restore adjusted_mode.crtc_vtotal from
TRANS_VRR_VMIN in intel_vrr_get_config() so downstream state stays
consistent.
Fixes: f26a8df8df ("drm/i915/display: Program TRANS_VTOTAL from mode vtotal")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260703032653.2122784-1-suraj.kandpal@intel.com
On Xe3P, when PSR2 is enabled on a panel that does not support
Early Transport, DC3CO can be entered in the middle of an
active frame. This prevents the pipe from completing the frame
and leaves it in a bad state that does not recover well,
causing visible corruption on screen.
Set CHICKEN_DCPR_4 bit 24 in the PSR2 enable path when Early Transport
is not in use, to notify DMC to prevent DC3CO entry.
v2:
- Remove display from commit header (Suraj Kandpal).
- Add HSD number to intel_display_wa framework (Suraj Kandpal).
- Change register prefix from XE3LPD_ to XE3P_ (Suraj Kandpal).
BSpec: 71483, 75253
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260701100650.1689665-2-dibin.moolakadan.subrahmanian@intel.com
The loop in intel_dp_check_mst_status() keeps servicing interrupts
originating from the sink without bound. Add an upper bound to the new
interrupts occurring during interrupt processing to not get stuck on
potentially stuck sink devices. Use arbitrary 32 tries to clear incoming
interrupts in one go.
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
Note: The condition likely pre-dates the commit in the Fixes: tag, but
this is about as far back as a backport has any chance of
succeeding. Before that, the retry had a goto.
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: 3c0ec2c2d5 ("drm/i915: Flatten intel_dp_check_mst_status() a bit")
Cc: stable@vger.kernel.org # v5.8+
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260625142204.1078287-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With the special d3cold handling in xe runtime suspend/resume separated,
unify the non-d3cold paths with i915. There are multiple changes here at
once that probably wouldn't make much sense to split out further.
Add the call to intel_display_driver_pm_runtime_suspend(), which, for
the time being, is a no-op. The intel_hpd_poll_enable() is called later.
Add the call to intel_display_driver_pm_runtime_suspend_late(), which
starts calling intel_display_power_runtime_suspend() and
intel_opregion_notify_adapter(). Deep down, the former should take care
of intel_dmc_wl_flush_release_work(), allowing us to drop the extra call
in xe_display_pm_runtime_suspend_late(). The intel_hpd_poll_enable()
call is also done here, postponed from the previous location in
xe_display_pm_runtime_suspend().
Add the call to intel_display_driver_pm_runtime_resume_early(), which
contains the intel_display_power_runtime_resume() and
intel_opregion_notify_adapter() counterparts to the calls in
intel_display_power_runtime_suspend_late().
Finally, intel_display_driver_pm_runtime_resume() replaces the direct
calls to intel_hpd_init(), intel_hpd_poll_disable(), and
skl_watermark_ipc_update(). (The hotplug poll enable/disable calls are
asymmetric.)
v2:
- Rebase, move placement of the calls
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/16205a1ee08e83f6e2f4dd30ed98fc043684a73e.1782913901.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add new functions intel_display_driver_pm_runtime_suspend(),
intel_display_driver_pm_runtime_suspend_late(),
intel_display_driver_pm_runtime_resume_early(), and
intel_display_driver_pm_runtime_resume(). The IRQ suspend/resume is
meant to happen between the corresponding calls. For now,
intel_display_driver_pm_runtime_suspend() is empty, but is included for
completeness as a placeholder.
Initially, only migrate i915, as there are some differences with xe that
will be addressed later.
There's a functional change, which should be benign:
i915_pm_runtime_resume() moves intel_opregion_notify_adapter() call
slightly later.
In the interest of not introducing more severe functional changes, the
calls become slightly asymmetric. We might want to address this later.
v2:
- Rebase, move placement of suspend calls
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/81e29bd9bee6c023d079ab076af7dc4b7e8985ca.1782913901.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
intel_cmtg_disable() indexes the per-transcoder register array using the
CMTG transcoder returned by to_cmtg_transcoder(), which is only valid for
TRANSCODER_A/B. The callers are now gated by intel_cmtg_is_allowed(), so
reaching this function with an invalid CMTG transcoder should never
happen.
Add a drm_WARN_ON() that bails out early in that case, both to document
the invariant and to guard against the out-of-bounds register access
(trans_offsets[-1]) should a future caller get it wrong.
v2:
- Add an in-function INVALID_TRANSCODER drm_WARN_ON check. (Suraj)
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260629180236.1353704-3-animesh.manna@intel.com
intel_cmtg_disable() maps crtc_state->cpu_transcoder to a CMTG transcoder
via to_cmtg_transcoder(), which only returns a valid transcoder for
TRANSCODER_A/B. The disable call sites in hsw_crtc_disable() and the
fastset/VRR path only check the sticky crtc->cmtg.enabled flag, so during
a big-joiner reconfiguration that moves the eDP across pipes
intel_cmtg_disable() can be reached with a crtc_state whose cpu_transcoder
does not map to a CMTG transcoder. That results in a negative
register-array index (trans_offsets[-1]) and a UBSAN
array-index-out-of-bounds splat:
UBSAN: array-index-out-of-bounds in .../display/intel_cmtg.c:187:24
intel_cmtg_disable+0x395/0x3d0 [xe]
intel_old_crtc_state_disables+0xfb/0x1f0 [xe]
intel_atomic_commit_tail+0xca6/0x2040 [xe]
Gate both call sites with intel_cmtg_is_allowed() so that
intel_cmtg_disable() is only invoked for configurations that actually map
to a CMTG transcoder.
v2:
- Guard the intel_cmtg_disable() call sites with intel_cmtg_is_allowed()
instead of a silent return (Suraj).
Fixes: 3bb44e8d42 ("drm/i915/cmtg: Modify existing hook to disable CMTG")
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260629180236.1353704-2-animesh.manna@intel.com
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: d849178e2c ("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>
Pull NTB updates from Jon Mason:
"An EPF bug fix to prevent an invalid unmap during device removal,
along with documentation fixes and minor AMD driver cleanups"
* tag 'ntb-7.2' of https://github.com/jonmason/ntb:
ntb: amd: Use named initializer for pci_device_id::driver_data
NTB: fix kernel-doc warnings in ntb.h
NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR
ntb_hw_amd: Fix incorrect debug message in link disable path
