Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arun R Murthy <arun.r.murthy@intel.com>
To: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Subject: [PATCH] drm/i915/mst: let the branch-sink check uncompressed with 18bpp
Date: Tue,  4 Aug 2026 15:14:50 +0530	[thread overview]
Message-ID: <20260804094450.125307-1-arun.r.murthy@intel.com> (raw)

mst_connector_mode_valid_ctx() uses a single 18bpp floor for both
the source-link BW check and the last-branch→sink PBN check, and
only drops it to the DSC-compressed minimum when the branch is in
DSC pass-through mode. This rejects modes on topologies where the
branch decodes DSC locally — the source→branch segment is actually
compressed and should not be gated by the 18bpp floor, while only
the last-branch→sink segment needs to remain at 18bpp.

The source-to-first-branch MST link carries DSC-compressed data
whenever any device along the path (a DSC pass-through branch, an
intermediate decoder-in-branch, or the endpoint sink) is able to
decode DSC. In all those cases the source can emit the stream
compressed and the check against the source link BW should use the
minimum compressed bpp, not the uncompressed 18bpp floor.

The last-branch-to-sink segment however is only compressed when the
path is true DSC pass-through; if the branch decodes locally and
re-transmits uncompressed, that segment must still fit at the
uncompressed 18bpp floor. That case is handled via port->full_pbn
below.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16640
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 23 +++++++++------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 3be1643f8d03..2e8f4c31e07f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1519,7 +1519,8 @@ mst_connector_mode_valid_ctx(struct drm_connector *_connector,
 	int max_rate, mode_rate, max_lanes, max_link_clock;
 	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);
+	int src_min_link_bpp_x16 = fxp_q4_from_int(18);
+	int sink_min_link_bpp_x16 = fxp_q4_from_int(18);
 	struct intel_dp_link_config max_bw_config;
 	static bool supports_dsc;
 	int ret;
@@ -1549,9 +1550,13 @@ mst_connector_mode_valid_ctx(struct drm_connector *_connector,
 	supports_dsc = intel_dp_has_dsc(connector) &&
 		       drm_dp_sink_supports_fec(connector->dp.fec_capability);
 
+	if (supports_dsc && connector->dp.dsc_decompression_aux)
+		src_min_link_bpp_x16 =
+			intel_dp_compute_min_compressed_bpp_x16(connector,
+								INTEL_OUTPUT_FORMAT_RGB);
+
 	if (supports_dsc && connector->mst.port->passthrough_aux)
-		min_link_bpp_x16 = intel_dp_compute_min_compressed_bpp_x16(connector,
-									   INTEL_OUTPUT_FORMAT_RGB);
+		sink_min_link_bpp_x16 = src_min_link_bpp_x16;
 
 	intel_dp_link_caps_get_max_bw_config(intel_dp->link.caps, &max_bw_config);
 	max_link_clock = max_bw_config.rate;
@@ -1561,19 +1566,11 @@ mst_connector_mode_valid_ctx(struct drm_connector *_connector,
 					       max_link_clock, max_lanes);
 	mode_rate = intel_dp_link_required(max_link_clock, max_lanes,
 					   mode->clock, mode->hdisplay,
-					   min_link_bpp_x16,
+					   src_min_link_bpp_x16,
 					   bw_overhead_flags);
 
 	/*
 	 * 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
@@ -1588,7 +1585,7 @@ mst_connector_mode_valid_ctx(struct drm_connector *_connector,
 		return ret;
 
 	if (mode_rate > max_rate ||
-	    drm_dp_calc_pbn_mode(mode->clock, min_link_bpp_x16) > port->full_pbn) {
+	    drm_dp_calc_pbn_mode(mode->clock, sink_min_link_bpp_x16) > port->full_pbn) {
 		*status = MODE_CLOCK_HIGH;
 		return 0;
 	}
-- 
2.25.1


                 reply	other threads:[~2026-08-04  9:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260804094450.125307-1-arun.r.murthy@intel.com \
    --to=arun.r.murthy@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