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
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>
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
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
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_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
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
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
Start isolating the link training state from the generic DP code by
introducing a separate intel_dp_link_training state struct.
Allocate the state so it can remain opaque within its own module.
Follow-up changes will move link training fields from the DP struct to
the link training 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/20260601093836.3057345-2-imre.deak@intel.com
The calls leading up to __intel_display_driver_pm_suspend() are
surrounded by near identical display calls. Move the calls inside
__intel_display_driver_pm_suspend() to clean up and deduplicate.
There's a slight functional change in that
intel_display_driver_pm_suspend() returns early for
!HAS_DISPLAY(). Assume this is what we want, and there are no cases
where display engine is present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/fdca3720537b6b79a754a83811d07b97d47e0db0.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Replace direct intel_display_driver_pm_suspend() and additional calls
with intel_display_driver_shutdown(). This switches to use
drm_atomic_helper_shutdown() instead of drm_atomic_helper_suspend(),
which is the more appropriate thing to do anyway.
Not calling intel_display_driver_pm_suspend() from the xe shutdown path
unblocks further follow-up changes.
There's a slight functional change in that
intel_display_driver_shutdown() returns early for !HAS_DISPLAY(). Assume
this is what we want, and there are no cases where display engine is
present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/e6783c063f8c0d4a2b413e550165896a3d977585.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add intel_display_driver_shutdown() to be called from the struct
pci_driver .shutdown path. Initially, only migrate i915, as there are
some subtle differences with xe that will be addressed later.
Pick up as much as we can at this point without making major functional
changes.
There's a slight functional change in that
intel_display_driver_shutdown() returns early for !HAS_DISPLAY(). Assume
this is what we want, and there are no cases where display engine is
present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/b6a3ed62d11b4b4999611e9b34c0bd1c531c1069.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
