Re: [PATCH v5 2/2] drm/i915/dp: enable DSC passthrough for HDMI 2.1 PCON devices

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Mode validation unconditionally rejects all DSC modes for passthrough PCONs because it derives limits from an all-zero DPCD.
- [Low] Compilation error: `intel_hdmi_dsc_get_num_slices` is called with 6 arguments but defined with 5.
--

commit 3c5cccb0470ef014fba8e2a861fd6cfffd5b223d
Author: Xiao Lu <xiaolu.xie@intel.com>

drm/i915/dp: enable DSC passthrough for HDMI 2.1 PCON devices

This patch adds explicit driver control of PCON DSC passthrough. It detects
passthrough capability at connect time and treats the PCON as DSC-capable.
DSC parameters are now derived from the downstream HDMI sink's EDID DSC
capabilities rather than the PCON encoder DPCD.

> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 113d767e62e9c..53d4d884f726b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c

[ ... ]

> @@ -2534,10 +2573,20 @@ bool intel_dp_mode_valid_with_dsc(struct intel_connector *connector,
>  							 num_joined_pipes,
>  							 output_format,
>  							 pipe_bpp, INT_MAX);
> -	int dsc_slice_count = intel_dp_dsc_get_slice_count(connector,
> -							   mode_clock,
> -							   mode_hdisplay,
> -							   num_joined_pipes);
> +	int dsc_slice_count;
> +
> +	if (connector->dp.pcon_dsc_passthrough) {
> +		const struct drm_display_info *info = &connector->base.display_info;
> +
> +		dsc_slice_count = min_t(int, info->hdmi.dsc_cap.max_slices,
> +					drm_dp_dsc_sink_max_slice_count(connector->dp.dsc_dpcd,
> +									false));

[Severity: High]
Does this logic unintentionally reject all DSC modes for passthrough PCONs?

Because connector->dp.dsc_dpcd is all-zero for passthrough PCONs, calling
drm_dp_dsc_sink_max_slice_count() on it will return 0. This results in
dsc_slice_count being capped at 0, which will cause the mode validation to
fail and reject high-bandwidth modes.

Additionally, could a similar issue occur in intel_dp_mode_valid_format()
where it computes pipe_bpp via intel_dp_dsc_compute_max_bpp()? That function
also relies on the all-zero dsc_dpcd array for passthrough PCONs, returning 0
and causing a cascading failure that rejects the mode.

> +	} else {
> +		dsc_slice_count = intel_dp_dsc_get_slice_count(connector,
> +							       mode_clock,
> +							       mode_hdisplay,
> +							       num_joined_pipes);
> +	}

[ ... ]

> @@ -4297,6 +4386,116 @@ void intel_dp_check_frl_training(struct intel_dp *intel_dp)

[ ... ]

> +	/*
> +	 * src_max_slice_width: pass INT_MAX so the HDMI spec limit of 2720px
> +	 * applies; the source VDSC HW limit (5120px) is higher so it is not
> +	 * the binding constraint here.
> +	 * src_max_slices: use hdmi_max_slices as the binding upper limit since
> +	 * the PCON passthrough capability bit (already checked) is the gate;
> +	 * the for-loop below further constrains to what the Intel VDSC HW can
> +	 * actually produce.
> +	 */
> +	target_slices = intel_hdmi_dsc_get_num_slices(&crtc_state->hw.adjusted_mode,
> +						      crtc_state->output_format,
> +						      hdmi_max_slices, INT_MAX,
> +						      hdmi_max_slices,
> +						      hdmi_throughput);

[Severity: Low]
Does this code introduce a build failure?

The function intel_hdmi_dsc_get_num_slices() is called here with 6 arguments,
but its definition only accepts 5 arguments.

> +	if (!target_slices)
> +		return false;

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