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. > 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. > (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
