Let intel_set_transcoder_timings() take the target transcoder as an
explicit argument instead of always using crtc_state->cpu_transcoder.
This makes the helper reusable for callers that need to program timings
for a transcoder other than the CRTC's CPU transcoder.
Update all existing callers to pass crtc_state->cpu_transcoder so there
is no functional change.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260615200339.885190-5-animesh.manna@intel.com
As all cmtg registers offset from base cmtg register is similar to
normal transcoder register, so follow existing way of defining
transcoder register for cmtg as well. Add base CMTG offset in
struct _display_device_info which will be used to derive the actual
register address for platform supporting CMTG.
Bspec: 68989
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260615200339.885190-4-animesh.manna@intel.com
Program the CMTG Clock Select register based on the transcoder used.
v2:
- Correct mask for PHY B. [Jani]
- Use REG_FIELD_PREP() for enable value. [Dibin]
- Extend cmtg clock select for xe3plpd. [Dibin]
v3:
- CMTG support removed for old platform.
v4:
- Optimize further with else-if. [Uma]
- Correct CMTG_CLK_SEL_B_MASK. [Uma]
v5:
- Add transcoder-port compatibility check. [Dibin]
Bspec: 69103
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Link: https://patch.msgid.link/20260615200339.885190-3-animesh.manna@intel.com
CMTG is supported on transcoder A and transcoder B with EDP,
so add a separate helper intel_cmtg_is_allowed() to check the
prerequisites for enabling CMTG. CMTG will be enabled only in
specific use cases such as PSR2, PR-ALPM, and LOBF, and will be
used in conjunction with the DC3CO feature. DC3co will be enabled
in a separate patch.
Note: Use-case-specific checks and transcoder-port compatibility
validation will be handled part of DC3co feature implementation.
v2:
- Remove separate flag for DC3co from crtc_state. [Uma, Dibin]
v3:
- Do not access power domain members directly. [Jani]
v4:
- Remove check for DC3co state now. if needed add Dc3co allow check
later once Dc3co patches are merged. [Uma]
Bspec: 68915
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260615200339.885190-2-animesh.manna@intel.com
Headers under include/ aren't supposed to try to include headers from
driver directories, such as i915_reg_defs.h. Remove it.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260615152837.1898991-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Enabling PPS after a display port's PLL is enabled leads to PLL / DDI
BUF timeouts during system resuming after a long (> 45 mins) suspended
state, at least on some ARL and MTL laptops, either all or some of them
also containing an Nvidia GPU. Enabling PPS first and then the PLL fixes
the problem for all the reporters.
A similar issue is seen when enabling an external DP output on PHY B
(vs. PHY A in the above eDP cases), where this change will not have any
effect (since no PPS is used in that case). There isn't any direct
connection between PPS and PLL, so the fix for eDP works by some
side-effect only. However Bspec does seem to require enabling PPS first,
so let's do that. Further investigation continues on the actual root
cause and a cure for external panels.
Fixes: 1a7fad2aea ("drm/i915/cx0: Enable dpll framework for MTL+")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16098
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16064
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16042
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: stable@vger.kernel.org # v7.0+
Tested-by: Jouni Högander <jouni.hogander@intel.com>
Tested-by: Marco Nenciarini <mnencia@kcore.it>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260612172617.3427027-1-imre.deak@intel.com
intel_crtc_put_color_blobs() drops the CRTC color blob references, but
leaves the corresponding pointers unchanged.
This can matter in intel_crtc_prepare_cleared_state(), which frees the
old CRTC hw state before calling intel_dp_tunnel_atomic_clear_stream_bw().
The latter can fail while looking up the DP tunnel group state, for
example with -EDEADLK.
If that happens, the function returns without completing the cleared
state preparation. The failed atomic state will then be cleared by the
atomic core and intel_crtc_free_hw_state() can be called again for the
same state, dropping the same blob references again.
Clear the blob pointers after dropping the references so repeated cleanup
of the same CRTC hw state is safe.
Fixes: fb69d0076e ("drm/i915/dp_tunnel: Fix error handling when clearing stream BW in atomic state")
Suggested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260612035310.3013066-1-lgs201920130244@gmail.com
As we increase the vtotal to accommodate lower resfresh rate for fixed
modes, adjust the vtotal-vsync distance also.
v2: Rename vsync_*_diff to vsync_*_offset for clarity. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260609025325.1128543-3-ankit.k.nautiyal@intel.com
LRR already updates crtc_vtotal/crtc_vblank_end seamlessly.
Extend the same handling to crtc_vsync_start/crtc_vsync_end so
VSYNC timing changes are programmed and accepted via the LRR path instead
of forcing a full modeset.
v2: Add comment explaining why TRANS_VSYNC update is safe for DP LRR.
(Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260609025325.1128543-2-ankit.k.nautiyal@intel.com
HDMI 2.0 section 6.1.3.1 specifies that after enabling
Scrambling_Enable and starting scrambled video transmission, the source
should poll Scrambling_Status until it reads 1 or until a timeout of
200 ms expires.
Add a polling step after enabling the HDMI port to check the scrambling
status when HDMI scrambling is enabled.
On some HDMI 2.0 sinks, omitting this check can result in 4K@60Hz
(594 MHz) failing to come up correctly because the sink has not yet
finished its scrambling setup. In practice, waiting for the scrambling
status here fixes such sinks.
While this synchronous polling is not itself explicitly required for
correct modeset sequencing, HDMI 2.0 section 6.1.3.1 does recommend it
as the way for the source to verify that the TMDS link is functioning
correctly with scrambling enabled.
v3:
- Add explicit HDMI 2.0 section reference in code comment
- Clarify commit message around the observed sink fix
v2:
- Poll TMDS_Scrambler_Status for up to 200 ms instead of using a fixed
delay
Reported-by: Jerome Tollet <jtollet@cisco.com>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6868
Link: https://lore.kernel.org/dri-devel/20251230091037.5603-1-jerome.tollet@gmail.com/
Signed-off-by: Jerome Tollet <jerome.tollet@gmail.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patch.msgid.link/20260520022544.3097252-1-ankit.k.nautiyal@intel.com
Use single for loops instead of two. Especially switching from a
for-loop to a do-while-loop with the same loop index is confusing, and
it's hard to figure out the end index. Define the end in terms of
lut_size; there's three more entries after the first 32.
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://patch.msgid.link/011336e9d57bba57e15d1aa64ae53a20c461ed62.1780499355.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use single for loops instead of two. Especially switching from a
for-loop to a do-while-loop with the same loop index is confusing, and
it's hard to figure out the end index. Define the end in terms of
lut_size; there's three more entries after the first 128.
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://patch.msgid.link/6d4f8bb713a998c199606c079bed924458f04f54.1780499355.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
For some reason we're tracking the best max_data_rate
as the difference between the required data_rate and
max_data_rate. That's pointlessly complicated as we're
just looking for the minimum max_data_rate that is
greater or equal to data_rate.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260528103458.18069-12-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
While DG2 is using hardcoded numbers for the memory bandwidth
stuff, let's still print them to aid in debugging as there are
two different SKUs to consider with different bandwidth numbers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260528103458.18069-10-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
The peak bandwidth doesn't depend on the number of planes,
so there is no need to repeat the same information for each
plane group.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260528103458.18069-9-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
The PSF bandwidth doesn't depend on the number of planes, so there
is no need to repeat the same information for each plane group.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260528103458.18069-8-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
We only have a single num_{qgv,psf}_points value, there is no
need to replicate it in each plane group.
And drop the somewhat misplaced comments about pcode behaviour
from {icl,tgl}_max_bw_index() while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260528103458.18069-7-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Rename 'num_points' to 'num_qgv_points' to make it a bit
more specific. We already have the 'num_psf_points' counterpart.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260528103458.18069-6-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
The way the TGL+ bw algorithm works is that 'num_planes'
is really a maximum number of allowed planes (whereas in
the ICL version it was more of a minimum), and the
assumption is that the first plane group (max[0]) can be
used with any number of planes (tgl_max_bw_index() always
returns 0 at the end).
To make things a bit less weird let's just set the first
plane group's num_planes to some big number to indicate it
has no real limit on the number of planes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260528103458.18069-4-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Make dg2_get_bw_info() look a bit more like xe2_hpd_get_bw_info()
so that we don't have so many different ways of writing the same
stuff (namely the "set all plane groups to the same value" part).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260528103458.18069-3-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Currently any "slow" wait will first try a "fast" wait
with a 2 usec timeout, and then fall back to whatever
timeout was specified originally. The "slow" wait will
anyway start off with a mere 10 usec polling interval,
so basically we can only save 8 usec with the "fast" wait
(maybe a bit more given hrtimer setup costs etc.).
I don't think we really do any operations in the display
code where that kinds of 8 usec saving would be meaningful.
So just get rid of the whole "fast" wait complication and
go straight for the "slow" wait.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260529161147.17573-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add kernel-doc documentation describing the Intel DP link training
recovery state machine and the sequence of automatic retraining,
fallback selection, and userspace notification.
v2:
- Rebase on dedicated intel-display documentation change.
- Remove unnecessary indent in section bodies. (Jani)
- Add recovery flowcharts. (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/20260601093836.3057345-23-imre.deak@intel.com
intel_dp_check_link_state() and intel_dp_link_params_valid() perform
only a coarse validation of the link configuration used by the active
mode against the available configurations (as constrained by the link
training fallback code after a previous LT failure). Even if these
coarse checks find a seemingly usable configuration, the modeset check,
which performs full verification, may still fail.
Disallow further autoretrain attempts if an autoretrain modeset fails.
Further attempts would just reuse the same modeset parameters and fail
in the same way. Autoretrain will be reallowed unconditionally when the
sink reports a change in its capabilities. This allows an autoretrain to
proceed once both the link validation and modeset checks confirm a
usable configuration.
Also clarify in intel_dp_check_link_state() and
intel_dp_link_params_valid() that these checks are coarse and that a
full validation is only performed by the subsequent atomic modeset
check.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-21-imre.deak@intel.com
Allocate a local atomic state for the autoretrain modeset. This
prepares for a follow-up change that needs to access the state after
the modeset for sending userspace notifications.
v2: Rebase on upstream drm_atomic_state -> drm_atomic_commit rename.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-20-imre.deak@intel.com
Simplify accessing the DRM atomic state via the intel atomic state
in intel_modeset_commit_pipes_for_atomic_state(), which also allows
dropping the cached DRM state pointer. Also streamline the success/error
return flows.
v2: Rebase on upstream drm_atomic_state -> drm_atomic_commit rename.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-19-imre.deak@intel.com
Factor out a helper modesetting a pipe that accepts an existing atomic
state. This prepares for a follow-up change that needs to allocate its
own atomic state.
v2: Rebase on upstream drm_atomic_state -> drm_atomic_commit rename.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-18-imre.deak@intel.com
Replace the misnamed retrain_disabled flag with a dedicated link
recovery state indicating that no fallback link configurations remain.
This clarifies the meaning of the state: it has always represented the
situation where no further fallback link configurations are available.
While at it, add a TODO comment to the debugfs entry, to expose this
state via a more appropriately named entry.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-17-imre.deak@intel.com
Replace the sequential link training failure counter with an explicit
link recovery state enum.
This makes the recovery states and transitions clearer: idle, automatic
retraining pending, and automatic retraining disabled.
A follow-up change will also move the retrain_disabled flag into this
enum.
v2: (Jani)
- Convert enum intel_dp_link_recovery_state's documentation to be a
non kernel-doc comment.
- Compare against / set enum values explicitly.
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/20260601093836.3057345-16-imre.deak@intel.com
Add link_recovery_reset() to make it explicit when link recovery is no
longer needed and the recovery state can be cleared.
This also prepares for replacing the sequential link training failure
counter with an enum in a follow-up change.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-15-imre.deak@intel.com
Add link_recovery_mark_train_failure() to record the failure and make
the link recovery state transition explicit after a link training
failure: recovery can continue with an autoretrain, or must be handed
over to userspace after fallback selection.
This also prepares for replacing the sequential link training failure
counter with an enum in a follow-up change.
v2: (Jani)
- Convert link_recovery_mark_train_failure()'s documentation to be a
non kernel-doc comment.
- Rename can_autoretrain flag to autoretrain_allowed.
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/20260601093836.3057345-14-imre.deak@intel.com
Add link_recovery_autoretrain_allowed() to make it clearer what the
condition is about at its callers: queuing work for and starting an
autoretrain is allowed.
This also prepares for replacing the sequential link training failure
counter with an enum in a follow-up change.
v2: Convert link_recovery_autoretrain_allowed()'s documentation to be a
non kernel-doc comment and detail what an allowed autoretrain is.
(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/20260601093836.3057345-13-imre.deak@intel.com
Add link_recovery_autoretrain_pending() to make it clearer what the
condition is about at its callers: an autoretrain work has been queued.
This also prepares for replacing the sequential link training failure
counter with an enum in a follow-up change.
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/20260601093836.3057345-12-imre.deak@intel.com
Check explicitly for a pending autoretrain by matching
seq_train_failures == 1.
This makes the actual condition clear, since at the point where the
counter is checked it is also below MAX_SEQ_TRAIN_FAILURES.
This also prepares for replacing the counter with an enum in a follow-up
change.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-11-imre.deak@intel.com
Clamp link_training->seq_train_failures to MAX_SEQ_TRAIN_FAILURES to
avoid - an unlikely - overflow. This is ok, because the code only makes
a distinction between the cases where the counter is below or at the
limit.
This also prepares for replacing the counter with an enum in a follow-up
change.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-10-imre.deak@intel.com
After a regular modeset link training failure, the driver attempts to
recover the link via an autoretrain using the same link parameters as
the modeset.
If the autoretrain fails as well, the set of allowed link configurations
is reduced via a fallback mechanism. For further link training, the
modeset parameters will likely need to change. This lowers the required
link bandwidth and allows selecting a link configuration from the
fallback-reduced set. Only userspace can perform such a modeset change.
Therefore, the driver notifies userspace to take over link recovery.
Userspace is expected to continue with the recovery attempt via a
modeset with updated parameters. The driver must not interfere with
these modesets.
link_training->seq_train_failures is set to MAX_SEQ_TRAIN_FAILURES after
the autoretrain fails. If a fallback selection also fails after this,
as no link configurations remain, retrain_disabled is set as well.
retrain_disabled is therefore somewhat misnamed: it indicates that no
fallback is available, not that autoretraining is disabled. This will be
addressed in a follow-up change by renaming the flag. For now, prevent
further autoretrain attempts based on the correct condition:
seq_train_failures == MAX_SEQ_TRAIN_FAILURES.
This also prepares for replacing the counter with an enum in a follow-up
change.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-9-imre.deak@intel.com
Move all state related to link recovery and link training debugging from
struct intel_dp to struct intel_dp_link_training.
This moves towards grouping all link training and recovery state and
logic in a single place and prepares for follow-up changes in the link
recovery state handling.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-8-imre.deak@intel.com
Add helpers to get and set the force retrain state in preparation for
moving the state from the DP struct to the link training state.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-7-imre.deak@intel.com
Retrieve the link_training pointer from the connector and derive the DP
pointer from it in debugfs entries.
This prepares for a follow-up change where values exposed via debugfs
entries will be retrieved from the link training state.
v2: Join unnecessarily wrapped lines. (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/20260601093836.3057345-6-imre.deak@intel.com
Flush pending connector commits before accessing the link training state
from debugfs. Access to connector state - like the link training state -
that may be updated from an asynchronous commit tail must hold the
connection mutex and wait for the tail to complete. The commit tail
cannot hold the connection mutex, so all other accessors must wait for
it explicitly.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260601093836.3057345-4-imre.deak@intel.com
