Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Arun R Murthy <arun.r.murthy@intel.com>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Subject: Re: [PATCH] drm/i915/mst: let the branch-sink check uncompressed with 18bpp
Date: Mon, 19 Oct 2026 15:06:53 +0300	[thread overview]
Message-ID: <e533815b60c86e9a49aabd9f59096d282707e3d9@intel.com> (raw)
In-Reply-To: <20260804094450.125307-1-arun.r.murthy@intel.com>

On Tue, 04 Aug 2026, Arun R Murthy <arun.r.murthy@intel.com> wrote:
> 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);

I don't understand what "src link" and "sink link" are supposed to mean
here.

You have a source and its constraints. You have a sink and its
constraints. And you have a link between the source and the sink, with
the constraints of both.

BR,
Jani.

>  	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;
>  	}

-- 
Jani Nikula, Intel

  parent reply	other threads:[~2026-10-19 12:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04  9:44 [PATCH] drm/i915/mst: let the branch-sink check uncompressed with 18bpp Arun R Murthy
2026-08-05 13:11 ` ✓ CI.KUnit: success for drm/i915/mst: let the branch-sink check uncompressed with 18bpp (rev2) Patchwork
2026-08-05 13:47 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-08-06  0:27 ` ✗ Xe.CI.FULL: " Patchwork
2026-10-07  7:37 ` [PATCH] drm/i915/mst: let the branch-sink check uncompressed with 18bpp Murthy, Arun R
2026-10-19  6:36 ` Ioann Komarov
2026-10-19 12:06 ` Jani Nikula [this message]
2026-10-21 13:38   ` Murthy, Arun R

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=e533815b60c86e9a49aabd9f59096d282707e3d9@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=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