Re: [PATCH] drm/i915/dp: Avoid YCbCr420 on HDMI2.1 PCONs due to the TMDS CLK limit

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] drm/i915/dp: intel_dp_frl_bw_valid() overestimates FRL bw by
  applying 18/16 to blanking
--

commit 7a66c4150ea1de9c9395550f545e6f8a16fa6852
Author: Xiao Lu <xiaolu.xie@intel.com>

drm/i915/dp: Avoid YCbCr420 on HDMI2.1 PCONs due to the TMDS CLK limit

This commit checks HDMI 2.1 FRL bandwidth limits instead of TMDS clock limits
in intel_dp_hdmi_compute_bpc() and intel_dp_mode_valid_downstream() when a
DP-to-HDMI PCON drives an HDMI 2.1 sink using FRL.

> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 47741957935ae..0836398c086ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1146,6 +1146,40 @@ static int intel_dp_max_tmds_clock(struct intel_dp *intel_dp)
>  	return max_tmds_clock;
>  }
>  
> +static bool intel_dp_is_hdmi_2_1_sink(struct intel_dp *intel_dp);
> +static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp);
> +
> +static int frl_required_bw(int clock, int bpc,
> +			   enum intel_output_format sink_format)
> +{
> +	if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> +		clock /= 2;
> +
> +	return clock * bpc * 3;
> +}
> +
> +/* Max HDMI FRL rate in Gbps if the PCON will use FRL to the sink, 0 for TMDS */
> +static int intel_dp_hdmi_frl_max_bw(struct intel_dp *intel_dp)
> +{
> +	if (!(intel_dp->downstream_ports[2] & DP_PCON_SOURCE_CTL_MODE) ||
> +	    !intel_dp_is_hdmi_2_1_sink(intel_dp))
> +		return 0;
> +
> +	return min(intel_dp->dfp.pcon_max_frl_bw,
> +		   intel_dp_hdmi_sink_max_frl(intel_dp));
> +}
> +
> +/* Check the pixel data fits the FRL link, including the 16b/18b encoding overhead */
> +static enum drm_mode_status
> +intel_dp_frl_bw_valid(int max_frl_bw, int clock, int bpc,
> +		      enum intel_output_format sink_format)
> +{
> +	u64 required_bw = (u64)frl_required_bw(clock, bpc, sink_format) * 18;
> +	u64 available_bw = (u64)max_frl_bw * 1000000 * 16;
> +
> +	return required_bw > available_bw ? MODE_CLOCK_HIGH : MODE_OK;
> +}

[Severity: High]
Does multiplying frl_required_bw() by 18/16 overestimate the required FRL
bandwidth and cause a regression for standard HDMI 2.1 modes?

frl_required_bw() uses the total pixel clock (including horizontal and
vertical blanking) as if the entire frame were 3-channel active video, whereas
HDMI 2.1 FRL encodes horizontal blanking with 1-byte TBlank characters and
Repeat Count compression.  Scaling the full pixel clock by 18/16 pushes
standard modes past the FRL link rates designed to carry them: for example,
4K120 (1188000 kHz) 8bpc RGB requires 1188000 * 24 * 18 = 513216000 vs
32 * 1000000 * 16 = 512000000 on a 32 Gbps FRL link, and 10bpc and 12bpc RGB
similarly fail at 40 Gbps and 48 Gbps, causing intel_dp_mode_valid_downstream()
and intel_dp_hdmi_compute_bpc() to reject them with MODE_CLOCK_HIGH.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111040636.3932240-1-xiaolu.xie@intel.com?part=1