As explained in the previous patch, the MST link BW reported by branch
devices during topology probing/path resources enumeration depends on
the link parameters programmed to DPCD to be up-to-date. After a sink is
plugged this is not ensured, as those DPCD values start out zeroed. The
target link parameters (for a subsequent modeset) are the maximum that
is supported, so make sure these maximum values are programmed before the
topology probing.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-14-imre.deak@intel.com
The MST link BW reported by branch devices via the ENUM_PATH_RESOURCES
message depends on the channel coding and link rate/lane count
parameters programmed to DPCD. This is the case at least for some branch
devices, while for others the reported BW is independent of the link
parameters. In any case the DP standard requires the branch device to
adjust the returned value to both account for the different way the BW
for FEC is accounted for (included in the returned value for non-UHBR
and not included for UHBR rates) and to limit the returned value to the
(trained) link BW between the source and first downstream branch
device, see DP v2.0/v2.1 Figure 2-94, DP v2.1 5.9.7. Presumedly this is
also the reason why the standard requires the DPCD link rate/lane count
values being up-to-date before sending the ENUM_PATH_RESOURCES message,
see DP v2.1 2.14.9.4.
Based on the above reprobe the MST topology after the link is retrained
with new link parameters to make sure that the MST link BW tracked in
the MST topology state (via each topology port's full_pbn value) is
up-to-date.
The next patch will make sure that the MST link BW is also kept
up-to-date if the link is disabled.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-13-imre.deak@intel.com
On MST links - at least for some MST branch devices - the list of modes
returned to users on an enabled link depends on the current link
rate/lane count parameters (besides the DPRX link capabilities, any MST
branch BW limit and the maximum link parameters reduced after LT
failures). In particular the MST branch BW limit may depend on the link
rate/lane count parameters programmed to DPCD. After an LT failure and
limiting the maximum link parameters accordingly, users should see a
mode list reflecting these new limits. However with the current fallback
order this isn't ensured, as the new limit could allow for modes
requiring a higher link BW, but these modes will be filtered out due to
the enabled link's lower link BW.
Ensure that the mode list changes in a consistent way after a link
training failure and reducing the link parameters by changing the
fallback order on MST links to happen in BW order.
v2:
- s/INTEL_DP_MAX_SUPPORTED_LANE_COUNTS/INTEL_DP_MAX_SUPPORTED_LANE_CONFIGS
and s/num_common_lane_counts/num_common_lane_configs to make the
difference wrt. max lane counts clearer. (Suraj)
- Add a TODO comment to make the SST fallback logic work the same way as
MST. (Arun)
- Use sort_r()'s default swap function instead of a custom one.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240729144458.2763667-1-imre.deak@intel.com
There are multiple failure cases a modeset-retry uevent can be sent for
a link (TBT tunnel BW allocation failure, unrecoverable link training
failure), a follow-up patch adding the handling for a new case where the
DP MST payload allocation fails. The uevent is the same in all cases,
sent to all the connectors on the link, so in case of multiple failures
there is no point in sending a separate uevent for each failure; prevent
this, sending only a single modeset-retry uevent for a commit.
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-7-imre.deak@intel.com
Initialize the DP link parameters during HW readout. These need to be
up-to-date at least for the MST topology probing, which depends on the
link rate and lane count programmed in DPCD. A follow-up patch will
program the DPCD values to reflect the maximum link parameters before
the first MST topology probing, but should do so only if the link is
disabled (link_trained==false).
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-6-imre.deak@intel.com
Clear VSC SDP if intel_dp_set_infoframes is called from post ddi disable
routine i.e with the variable of enable as false. This is to avoid
an infoframes.enable mismatch issue which is caused when pipe is
connected to eDp which has psr then connected to DPMST. In this case
eDp's post ddi disable routine does not clear infoframes.enable VSC
for the given pipe and DPMST does not recompute VSC SDP and write
infoframes.enable which causes a mismatch.
--v2
-Make the comment match the code [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240724163743.3668407-1-suraj.kandpal@intel.com
After a bad link state is detected, the sink capabilities with which the
link was originally trained could have changed: for instance another
sink got connected or the retraining was forced after the rate/lane count
got decreased (as a fallback). In these cases the retraining modeset
fails as expected also printing a debug message, so don't WARN on it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240712135724.660399-3-imre.deak@intel.com
Instead of direct calls of the link training functions, use a modeset
commit to retrain a DP link in SST mode, similarly to how this is done
in DP-MST mode. Originally the current way was chosen presumedly,
because there wasn't a well-established way in place for the driver to
do an internal (vs. userspace/kernel client) commit. Since then such
internal commits became a common place (initial-, HDMI/TC link reset
commit), so there is no reason to handle the DP-SST link-retraining case
differently.
At the end of the current sequence the HW reported a FIFO underrun -
without other issues visible to users - because during retraining the
link's encoder/port was disabled/re-enabled without also
disabling/re-enabling the corresponding pipe/transcoder (as required by
the spec); the corresponding underrun error message was suppressed as a
known issue. Based on Ankit's test on DG2 the underrun error was still
reported as it got detected with some (vblank) delay wrt. other
platforms. Switching to a modeset commit resolves these underrun related
issues.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240712135724.660399-1-imre.deak@intel.com
Add connector debugfs entries to force the link rate/lane count to be
used by a link training afterwards. These settings will be clamped to
the supported, i.e. the source's and sink's common rate/lane count.
After forcing the link rate/lane count reset the link training
parameters and for a non-auto setting disable reducing the link
parameters via the fallback logic. The former one can be used after
testing link training failure scenarios - via debugfs entries added
later - to reset the reduced link parameters after the test.
v2:
- Add the entries from intel_dp_link_training.c (Jani)
- Rename the entries to i915_dp_set_link_rate/lane_count.
v3: (Ville)
- Rename the entries/struct fields to force_link_rate/lane_count.
- Lock connection_mutex only for the required intel_dp state.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240610164933.2947366-18-imre.deak@intel.com
After a link training failure if the link parameters can't be further
reduced, there is no point in trying to retrain the link in the driver.
This avoids excessive retrain attempts after detecting a bad link, for
instance while handling MST HPD IRQs, which is likely redundant as the
link training failed already twice with the same minimum link
parameters. Userspace can still try to retrain the link with these
parameters via a modeset.
While at it make the error message more accurate.
v2: Move converting the error to a debug message to the relevant
follow-up patch. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240610164933.2947366-15-imre.deak@intel.com
The next patch adds sending a modeset-retry uevent after a link training
failure to all MST connectors on link. This requires the atomic state,
so pass it to intel_dp_start_link_train(). In case of SST where
retraining still happens by calling this function directly instead of a
modeset commit the atomic state is not available and NULL is passed
instead. This is ok, since in this case the encoder's only DP connector
is available from intel_dp->attached_connector not requiring the atomic
state.
v2: Add NOTE that the atomic state may not be valid for SST links and
assert that it's valid for MST links. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240610164933.2947366-10-imre.deak@intel.com
Recheck the link state after a passing link training, with a 2 sec delay
to account for cases where the link goes bad following the link training
and the sink doesn't report this via an HPD IRQ.
The delayed work added here will be also used by a later patch after a
failed link training to try to retrain the link with unchanged link
params before reducing the link params.
v2: Don't flush an uninitialized delayed work (on HDMI-only DDI ports).
v3:
- Move the helpers to a new intel_encoder.c file, rename them
accordingly. (Ville)
- Add the work to intel_encoder instead of intel_digital_port.
- Call the encoder specific link check function via an encoder hook.
- Flush the link check work during encoder destroy from
intel_dp_encoder_flush_work().
- Flush the link check work during encoder suspend as well.
v4: Call intel_encoder_link_check_init() with a valid encoder pointer.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240610181428.2955658-1-imre.deak@intel.com
Instead of direct calls to the link train functions, retrain the link
via a commit modeset. The direct call means that the output port will be
disabled/re-enabled while the rest of the pipeline (transcoder) is
active, which doesn't seem to work on MST at least. It leads to
underruns and black screen, presumedly because the transcoder is not
disabled/re-enabled along the port.
Leave switching to a commit modeset on SST for a later patchset, as that
seems to work ok currently (though better to using a commit there too,
due to the suppressed underruns).
v2: Keep reverse line length order for local variables. (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240610164933.2947366-7-imre.deak@intel.com
Link Off Between Active Frames, is a new feature for eDP
that allows the panel to go to lower power state after
transmission of data. This is a feature on top of ALPM, AS SDP.
Add compute config during atomic-check phase.
v1: RFC version.
v2: Add separate flag for auxless-alpm. [Jani]
v3:
- intel_dp->lobf_supported replaced with crtc_state->has_lobf. [Jouni]
- Add DISPLAY_VER() check. [Jouni]
- Modify function name of get_aux_less_status. [Jani]
v4: Add enum alpm_mode to hold the aux-wake/less capability.
v5: Add alpm_dpcd to intel_dp and use aux_wake_supported()/
aux_less_wake_supported() instead of enum alpm_mode. [Jouni]
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529200742.1694401-5-animesh.manna@intel.com
Fix the calculation of the DSC line buffer depth. This is limited both
by the source's and sink's maximum line buffer depth, but the former one
was not taken into account. On all Intel platform's the source's maximum
buffer depth is 13, so the overall limit is simply the minimum of the
source/sink's limit, regardless of the DSC version.
This leaves the DSI DSC line buffer depth calculation as-is, trusting
VBT.
On DSC version 1.2 for sinks reporting a maximum line buffer depth of 16
the line buffer depth was incorrectly programmed as 0, leading to a
corruption in color gradients / lines on the decompressed screen image.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-2-imre.deak@intel.com
