Pull the "is the BIOS FB OK?" checks to a helper function. We'll
add other relevant checks there later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-3-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Properly turn off the plane if it is enabled but
.get_initial_plane_config() failed for whatever reason.
The hardware does (or at least did) perform some kind of automagic
plane disable when the pipe gets disabled, but we don't rely on that
anywhere else either. Also the GGTT/actual memory may get clobbered
afterwards, so leaving the plane enabled here could result in visual
corruption/GTT faults/etc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-2-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Commit 16df4cc63c ("drm/i915/display: Use ceiling division for NV12
UV surface offset calculation") computes the UV (chroma) surface
start/size as ceiling(half of Y plane start/size) directly from the
U16.16 fixed-point source rectangle:
x = fp_16_16_to_int_ceil(fp_16_16_div2(src.x1));
For a single pipe the source coordinates are integers, so this is
correct.
(UV start = ceiling(half of Y plane start)).
With bigjoiner + a plane scaler the picture changes. The pipe boundary
is a fixed integer destination pixel, but the plane's position and the
scaler ratio are arbitrary, so drm_rect_clip_scaled() maps the seam back
to a *fractional* per-pipe source. For a 1280->2407 upscaled NV12 plane
crossing the seam:
master src: width = 1204 * 1280/2407 = 640.265899, x1 = 0
joiner src: width = 1203 * 1280/2407 = 639.734115, x1 = 640.265884
The luma path floors this to an integer (src.x1 >> 16 = 640), but the
UV path takes ceiling(640.265884 / 2) = ceil(320.13) = 321. The Y plane
then starts at column 640 while the UV plane starts at 321*2 = 642,
pushing the chroma read one column past the 640-wide chroma surface on
the joiner secondary:
[CRTC:382:pipe C] PLANE ATS fault
[CRTC:382:pipe C][PLANE:267:plane 1C] fault (CTL=0x81009400, ...)
The spec "Y plane start" is the integer pixel the luma surface actually
programs (640), not the pre-floor fixed-point value (640.27). Convert
the Y plane start/size to integer first - matching skl_check_main_surface()
- and then apply the ceiling. This is a no-op for the integer (non-joiner)
case and yields the correct, in-bounds chroma offset for the fractional
joiner seam:
before fix after fix
master 1B: x=0 w=321 x=0 w=320 -> [0, 320)
slave 1C: x=321 w=320 x=320 w=320 -> [320, 640)
The two halves now tile the 640-wide chroma plane exactly and the ATS
fault is gone.
Assisted-by: GitHub-Copilot:Claude-Opus-4.8
Fixes: 16df4cc63c ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation")
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260618181837.687302-1-vidya.srinivas@intel.com
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
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
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
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
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
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
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
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 a helper to query the link configuration among the currently allowed
configurations with the maximum link BW.
This will be used by follow-up changes to unify the max BW link config
query during mode validation and TBT BW calculation.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-14-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
Add a debugfs entry showing the currently allowed link configurations
in the connector's 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-12-imre.deak@intel.com
There is no need to update any maximum link information when updating
the max link limits, so drop the related noupdate postfix from the
helpers setting the max link limits.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-11-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
Re-enable link configurations after the link is reset via a call
to intel_dp_link_caps_reset(), allowing a subsequent modeset to
use all the link configurations of a sink newly connected or an already
connected sink changing its capabilities.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-9-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 helper to select the link configuration iteration order for a
connector during state computation and fallback selection. This keeps
the connector-specific ordering policy in the link caps module.
v2: Add helper to get the order for fallback selection as well.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-6-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
Factor out a helper that looks up a link configuration by index.
This provides the link configuration directly, avoiding the
indirect conversion via the packed config entry.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-3-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>
Add new high-level functions intel_display_driver_runtime_pm_enable()
and intel_display_driver_runtime_pm_disable() to abstract the low-level
functions intel_display_power_enable() and
intel_display_power_disable(), respectively.
The asymmetry in the "runtime pm enable/disable" and "pm runtime
suspend/etc" naming is intentional, with the latter intended to be
called from the PM hooks.
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/c95cb644a35ede7d4d456fd1654ce0b42b6eea33.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>
According to Bspec we only need to write SSC Enable PLL A bit
and leave PLL B bit alone in PORT_CLOCK_CTL register.
Bspec: 74667, 74492
Fixes: 3383ba2479 ("drm/i915/ltphy: Enable SSC during port clock programming")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260701091503.1302226-3-suraj.kandpal@intel.com
We need to readout the ssc_enabled param for LT PHY pll state too.
Create a function that does that, we only need to read SSC Enable PLL A
bit since that is the only one we write Xe3p onwards. While at it
improve the dump using str_yes_or_no.
Bspec: 74667
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260701091503.1302226-2-suraj.kandpal@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
While the panel_type from LFP Data Block is range checked, panel_type2
is not. Add a few helpers for range checking, and use them to not only
check panel_type2, but also improve clarity and correctness in the panel
type selection.
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
v2:
- Fix commit message typo (Michał)
- Add is_panel_type_pnp() (Ville)
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: 6434cf6300 ("drm/i915/bios: calculate panel type as per child device index in VBT")
Cc: stable@vger.kernel.org # v6.0+
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260626140155.1389655-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit c9ebe5d2f2)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Ensure the EDID provided min/max vfreq are valid. Most scenarios are
already covered (by coincidence) through the checks in
intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit
about it. At worst, a zero min_vfreq could lead to a division by zero in
intel_vrr_compute_vmax().
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: 117cd09ba5 ("drm/i915/display/dp: Compute VRR state in atomic_check")
Cc: stable@vger.kernel.org # v5.12+
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260625131040.1051272-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 1765cf59f5)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
While the panel_type from LFP Data Block is range checked, panel_type2
is not. Add a few helpers for range checking, and use them to not only
check panel_type2, but also improve clarity and correctness in the panel
type selection.
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
v2:
- Fix commit message typo (Michał)
- Add is_panel_type_pnp() (Ville)
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: 6434cf6300 ("drm/i915/bios: calculate panel type as per child device index in VBT")
Cc: stable@vger.kernel.org # v6.0+
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260626140155.1389655-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ensure the EDID provided min/max vfreq are valid. Most scenarios are
already covered (by coincidence) through the checks in
intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit
about it. At worst, a zero min_vfreq could lead to a division by zero in
intel_vrr_compute_vmax().
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: 117cd09ba5 ("drm/i915/display/dp: Compute VRR state in atomic_check")
Cc: stable@vger.kernel.org # v5.12+
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260625131040.1051272-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@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>
(cherry picked from commit 58a224375c)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
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: e03187e12c ("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>
(cherry picked from commit 9284ab3b6e)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.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>
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: e03187e12c ("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>
This reverts commit 4f1cab2e48.
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
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmo+6lsACgkQDHTzWXnE
hr6P5hAAgw0yMgrclEMiPTNjqW61gDag53Spw0za4RdpNbwc9EqYIcnWZ28nMqTB
bT/ZY0q+gARV0gtYvlvAJ66sKiBzypUIYf7rgSOSFsQ0KDICS2gM8zNu0XFc4cWw
5jDHJkbzjYYaP5bAb6SEKVu8gWex2VbVqPws4sPxq58YqJH0jJRalcNi54g0WQXm
8pztzJzKzRUntanJQ43mOMDDXz8nEDPV4Vw6ZrOX7muxTDFjlrXiOsDttKcLtXxn
MmRb1L38mIQUYNhMX6cPa+V36NTl4B2t/by7ORydt4VRG6BLUdzlJWreHraCYioA
UjDQOJQfDsEX9yBMeag5g2X3pZJh/aUS0UN45I96RuB9a2QgThb3poY4BqpTf+oX
OANRV7iQFLk50tLyM6XPc5p4ijvedLdOTBpQTNeWh0deexr/pCTmqKOV6R6hOw7Q
cB3HobYAtJXhxnfXolidSxO3jxFjl7oOjIeBAy9FCWhfn5KW6ygssJJH1RIz0sc+
gHWqoywxRj2esVmC1m1Qem2GvIImWb2iGfCSJu1iNMPrHl/7uBK+LConEPYT4oR5
BURE60FoObIkAT77J512uCVE0+btZdk3aOBqBGx/OXvbYzP03S8xUnZeZU+PBviY
kDfiNJvdnx4bd6+QV/xTT0mBGOJjAJOSyq9rRHIdTLOj5HBNIcI=
=qcB5
-----END PGP SIGNATURE-----
Merge tag 'drm-next-2026-06-27' of https://gitlab.freedesktop.org/drm/kernel
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
...
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>
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>
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
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>
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>
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>
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>
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>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Use intel_dp_link_caps_get_forced_params() in the link training fallback
code instead of directly accessing the state. This allows the link caps
module to track changes to forced parameters internally.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-9-imre.deak@intel.com
Move the debugfs entries for the forced and max DP link parameters to
intel_dp_link_caps. 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-8-imre.deak@intel.com
Simplify querying the forced link rate and lane count by
performing the zero checks inside the helpers, allowing callers
to use the returned values directly.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-7-imre.deak@intel.com
Move the helpers handling forced link parameters 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.
Return the forced link rate and lane count through a
struct intel_dp_link_config, which is the canonical way the rest of the
link capability API will also accept and return link configurations.
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-6-imre.deak@intel.com
Move the helpers handling common link rates 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: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-5-imre.deak@intel.com
Start isolating the DP link capability logic from the generic DP code by
adding a separate intel_dp_link_caps module and a corresponding state
object.
Allocate the state so it can remain opaque within its module.
Follow-up changes will move link capability helpers and state from
intel_dp.c and intel_dp_link_training.c to the new module and state.
v2: Remove unnecessary function documentation. (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-4-imre.deak@intel.com
Add a struct representing the public unpacked format of a link
configuration. This will be used by the DP link capability API added
as a follow-up, and by DP code in general that needs to track a link
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-3-imre.deak@intel.com
Rename intel_dp_link_config to intel_dp_link_config_entry to prepare
for tracking a link configuration in both an internal packed and a
public unpacked format. A follow-up change will add
struct intel_dp_link_config representing the public unpacked format.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-2-imre.deak@intel.com
Adjust the panel fixed mode selection algorithm to only consider
fixed modes that are "VRR compatible" with the old fixed mode
when userspace doesn't want to allow full modesets. This will
allow a VRR based refresh rate changes (ie. just a change in
the vblank length) via the fastset path.
When full modesets are allowed, we still use the original algorithm
as that may pick a fixed mode with a more optimal dotclock, potentially
leading to reduced power consumption.
This approach works as long as userspace does the initial
allow_modeset=true commit using the highest refresh rate it will
want to use. Subsequent commits with allow_modeset=false can then
switch between lower refresh rates without blinks.
One remaining hurdle we may need to solve is the guardband length.
Assuming the highest refresh rate vblank is too short for
intel_vrr_compute_optimized_guardband() the intitial guardband will
match the highest refresh rate vblank. A subsequent switch to a lower
refresh rate will then recompute the guardband and select a value
that is higher (since the vblank will be longer). The mismatch in
guardband lengths will prevent the fastset. We may either have to
preserve the original (sub-optimal) guardband, or we'll have to
revisit the idea of changing the guardband without a full modeset.
Note that I'm not 100% happy with this solution because
intel_panel_fixed_mode() is no longer fully idempotent, but I wasn't
able to come up with anything truly better either :/ The simple
solution would be just to always pick the fixed mode with the highest
dotclock, but that could lead to increased power consumption even
when high refresh rates are never used.
Perhaps the proper solution would be to just deprecate this
idea of taking in random modes for internal panels and then
cooking up a compatible fixed modes. Life would be easier if
userspace was required to provide the desired fixed mode directly.
But in order to do that we'd need to introduce new uapi properties
to control the pfit aspect of this, and we'd probably need a new
client cap to select between the old and new userspace behaviour.
Something to consider in the future...
v2: Rebase due to earlier changes to VRR fixed mode selection
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260622213602.7244-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Pass the full atomic state to intel_panel_compute_config(). We'll
need this for some upcoming VRR fastset tricks. And to accompany
full state we'll also need the crtc (or its state) as well.
v2: Rebase
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623114130.7333-1-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
