Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: <intel-gfx@lists.freedesktop.org>, <intel-xe@lists.freedesktop.org>
Subject: [PATCH 4/4] drm/i915/dp_mst: Allow modes requiring compression for DSC passthrough
Date: Mon, 16 Feb 2026 09:04:21 +0200	[thread overview]
Message-ID: <20260216070421.714884-5-imre.deak@intel.com> (raw)
In-Reply-To: <20260216070421.714884-1-imre.deak@intel.com>

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>
---
 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
-- 
2.49.1


  parent reply	other threads:[~2026-02-16  7:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-16  7:04 [PATCH 0/4] drm/i915/dp_mst: Allow DSC passthrough modes during validation Imre Deak
2026-02-16  7:04 ` [PATCH 1/4] drm/i915/dp: Add missing slice count check during mode validation Imre Deak
2026-02-17  4:22   ` Nautiyal, Ankit K
2026-02-16  7:04 ` [PATCH 2/4] drm/i915/dp: Export intel_dp_compute_min_compressed_bpp_x16() Imre Deak
2026-02-17  4:23   ` Nautiyal, Ankit K
2026-02-16  7:04 ` [PATCH 3/4] drm/i915/dp_mst: Track min link BPP as x16 fixed-point during mode validation Imre Deak
2026-02-17  4:24   ` Nautiyal, Ankit K
2026-02-16  7:04 ` Imre Deak [this message]
2026-02-17  4:53   ` [PATCH 4/4] drm/i915/dp_mst: Allow modes requiring compression for DSC passthrough Nautiyal, Ankit K
2026-02-17  8:59     ` Imre Deak
2026-02-17 12:27       ` Nautiyal, Ankit K
2026-02-16  7:11 ` ✓ CI.KUnit: success for drm/i915/dp_mst: Allow DSC passthrough modes during validation Patchwork
2026-02-16  7:27 ` ✗ CI.checksparse: warning " Patchwork
2026-02-16  7:47 ` ✓ Xe.CI.BAT: success " Patchwork
2026-02-16  8:59 ` ✗ Xe.CI.FULL: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260216070421.714884-5-imre.deak@intel.com \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox