On 2/17/2026 2:29 PM, Imre Deak wrote:
On Tue, Feb 17, 2026 at 10:23:51AM +0530, Ankit K Nautiyal wrote:
On 2/16/2026 12:34 PM, Imre Deak wrote:
The DSC passthrough mode allows a compressed stream to be forwarded
to the sink instead of being decompressed at the last MST branch
device, provided that the branch device supports passthrough and
the sink supports decompression. This enables modes that would not
be possible without compression, as the bandwidth required for the
uncompressed stream exceeds what is available on the full MST path
from source to sink.
Currently, MST mode validation assumes the stream is uncompressed
and uses the corresponding uncompressed minimum link BPP for
bandwidth calculation. Use the minimum compressed link BPP instead
when DSC passthrough is available to enable the modes described
above.
The non-passthrough DSC mode, where the last MST branch device
decompresses the stream, may also allow enabling additional modes.
This would require determining the link bandwidth between the last
branch device and the sink based on the
DFP_Link_Available_Payload_Bandwidth_Number reported by the branch
device for the sink via the ENUM_PATH_RESOURCES MST message.
Supporting this is left for a follow-up for the following reasons:
1. DFP Link Available PBN reporting is not supported by any of the
available MST devices used for testing.
2. Non-passthrough mode would enable additional modes only if the link
bandwidth between the last branch device and the sink exceeded that
of the full MST path. Unless multiple MST devices are used, or link
training forces a reduced bandwidth between the source and the first
branch device, both rare cases, this is unlikely.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4332
Signed-off-by: Imre Deak <[email protected]>
Makes sense to leave the non-passthrough mode for follow up.
Perhaps our kms_linktrain_fallback can be tweaked to test DSC
non-passthrough and passthrough modes.
Yes, it's a good idea to test whether, with a reduced link rate / lane
count, modes that did not need compression with the original link
configuration continue to be enumerated/enabled correctly when switching
to DSC.
I don't think this should be part of the LT fallback test; it could
instead be a separate DSC test by just forcing a lower link rate / lane
count there.
Agreed. Can use the same debugfs and have test in kms_dsc.
Not directly related but perhaps still on the topic: currently we are not
exposing dsc related debugfs for MST connectors.
With the recent changes and checks for intel_dp->force_dsc_en in place for
MST, can we start exposing the dsc related debugfs' for MST too?
MST connectors, and in general the whole DSC debugfs interface, need
some changes. Adding a way to control the passthrough / non-passthrough
mode (probably just a disable_passthrough connector debugfs entry)
should be added as well. I have some changes for this and plan to follow
up with them.
Hmm. Alright, will check that out.
Regards,
Ankit
(Though, there are still things which cannot be tested on MST - BPC tests,
output format etc.)
In any case the changes look good to me.
Reviewed-by: Ankit Nautiyal <[email protected]
Thanks.
Regards,
Ankit
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 7ca2e2245fc70..f833f47643271 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1467,6 +1467,7 @@ mst_connector_mode_valid_ctx(struct drm_connector
*_connector,
unsigned long bw_overhead_flags =
DRM_DP_BW_OVERHEAD_MST | DRM_DP_BW_OVERHEAD_SSC_REF_CLK;
int min_link_bpp_x16 = fxp_q4_from_int(18);
+ static bool supports_dsc;
int ret;
bool dsc = false;
int target_clock = mode->clock;
@@ -1491,6 +1492,13 @@ mst_connector_mode_valid_ctx(struct drm_connector
*_connector,
return 0;
}
+ supports_dsc = intel_dp_has_dsc(connector) &&
+ drm_dp_sink_supports_fec(connector->dp.fec_capability);
+
+ if (supports_dsc && connector->mst.port->passthrough_aux)
+ min_link_bpp_x16 =
intel_dp_compute_min_compressed_bpp_x16(connector,
+
INTEL_OUTPUT_FORMAT_RGB);
+
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
@@ -1504,6 +1512,13 @@ mst_connector_mode_valid_ctx(struct drm_connector
*_connector,
/*
* TODO:
* - Also check if compression would allow for the mode
+ * in non-passthrough mode, i.e. the last branch device
+ * decompressing the stream. This makes a difference only if
+ * the BW on the link between the last branch device and the
+ * sink is higher than the BW on the whole MST path from the
+ * source to the last branch device. Relying on the extra BW
+ * this provides also requires the
+ * DFP_Link_Available_Payload_Bandwidth_Number described below.
* - Calculate the overhead using drm_dp_bw_overhead() /
* drm_dp_bw_channel_coding_efficiency(), similarly to the
* compute config code, as drm_dp_calc_pbn_mode() doesn't
@@ -1527,8 +1542,7 @@ mst_connector_mode_valid_ctx(struct drm_connector
*_connector,
for_each_joiner_candidate(connector, mode, num_joined_pipes) {
int dsc_slice_count = 0;
- if (intel_dp_has_dsc(connector) &&
- drm_dp_sink_supports_fec(connector->dp.fec_capability)) {
+ if (supports_dsc) {
/*
* TBD pass the connector BPC,
* for now U8_MAX so that max BPC on that platform
would be picked
