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] Slice count calculation for passthrough-only PCONs evaluates to 0, unconditionally rejecting valid DSC modes.
- [Low] Call to intel_hdmi_dsc_get_num_slices uses an incorrect function signature, causing a build failure and potential out-of-bounds read if coerced.
--

commit 143c11b20062c81b5ac2377b90407f1c60975424
Author: Xiao Lu <xiaolu.xie@intel.com>
drm/i915/dp: enable DSC passthrough for HDMI 2.1 PCON devices

This commit adds explicit driver control for PCON DSC passthrough
capabilities, allowing HDMI 2.1 PCON devices to forward compressed streams
to a downstream HDMI sink for decompression. It detects passthrough support,
overrides DSC configuration paths to use the HDMI sink's capabilities, and
writes appropriate registers to enable passthrough instead of relying on
autonomous fallbacks.

> 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 regression artificially cap the slice count to zero for passthrough
PCONs?

As noted in the commit message, the PCON encoder DPCD fields are all-zero for
passthrough-only devices. Because connector->dp.dsc_dpcd is zeroed out,
calling drm_dp_dsc_sink_max_slice_count() will evaluate to 0.

Since this is passed into min_t(), wouldn't dsc_slice_count evaluate to 0
and unconditionally reject valid DSC modes downstream in this function?

>  	} else {
>  		dsc_slice_count = intel_dp_dsc_get_slice_count(connector,
[ ... ]
> @@ -4297,6 +4386,116 @@ void intel_dp_check_frl_training(struct intel_dp *intel_dp)
>  	}
>  }
>  
> +/*
> + * intel_dp_pcon_set_dsc_passthrough_cap - cache PCON DSC passthrough capability
[ ... ]
> +static bool
> +intel_dp_pcon_passthrough_dsc_slice_config(struct intel_dp *intel_dp,
> +					   const struct intel_crtc_state *crtc_state,
> +					   struct intel_dsc_slice_config *config_ret)
> +{
[ ... ]
> +	/*
> +	 * 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]
Can this regression cause a build failure or memory issues?

The call to intel_hdmi_dsc_get_num_slices() passes 6 arguments, and the first
argument is passed as &crtc_state->hw.adjusted_mode.

Looking at the actual definition of intel_hdmi_dsc_get_num_slices() in
drivers/gpu/drm/i915/display/intel_hdmi.c:

int intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
                                  int src_max_slices, int src_max_slice_width,
                                  int hdmi_max_slices, int hdmi_throughput)

It still expects 5 arguments, with the first being a const struct
intel_crtc_state *. Could this result in an out-of-bounds read if the
compiler coerces the smaller drm_display_mode struct into an
intel_crtc_state?

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

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