Re: [PATCH 4/4] drm/i915/dp_mst: Allow modes requiring compression for DSC passthrough

[Imre Deak <imre.deak@intel.com>]

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 <imre.deak@intel.com>
> 
> 
> 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 <ankit.k.nautiyal@intel.com

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