Re: [PATCH v2 1/2] drm/i915/dp: fix PBN in ALLOCATE_PAYLOAD request to use actual video bandwidth

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/i915/dp: Timeslot accounting mismatch and WARN_ON due to unaligned slots
--

commit 42ac7363ce1083ef4680462acc3e4eec1ddf8e96
Author: Xiao Lu <xiaolu.xie@intel.com>
Subject: drm/i915/dp: fix PBN in ALLOCATE_PAYLOAD request to use actual video bandwidth

This commit modifies intel_dp_mtp_tu_compute_config() to separate the actual
video bandwidth (raw_pbn) from the aligned PBN used for hardware TU
programming. It passes raw_pbn to drm_dp_atomic_find_time_slots() so that the
MST core allocates payload bandwidth reflecting true stream requirements rather
than incorporating link-rate-specific TU granularity.

> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 0c362784afe4a..31e846aadcf6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
[ ... ]
> @@ -397,7 +398,21 @@ int intel_dp_mtp_tu_compute_config(struct intel_dp *intel_dp,
>  
>  			slots = drm_dp_atomic_find_time_slots(state, &intel_dp->mst.mgr,
>  							      connector->mst.port,
> -							      dfixed_trunc(pbn));
> +							      raw_pbn);

[Severity: High]
Does this cause a timeslot accounting mismatch and a kernel warning?

By passing raw_pbn to drm_dp_atomic_find_time_slots() in
intel_dp_mtp_tu_compute_config(), the function calculates and returns an
unaligned VCPI timeslot allocation. However, the Intel TX hardware requires
timeslots to be aligned (e.g., to a 4-slot boundary for a 1-lane link).

Because the returned slots is unaligned, it diverges from the hardware-aligned
dp_m_n.tu. This leads to two issues:

1. The boundary check immediately following this call:

    if (slots > mst_state->total_avail_slots)
        slots = -EINVAL;

incorrectly uses the unaligned slots value rather than checking the final
aligned remote_tu that is actually programmed into the hardware. This might
bypass the availability check for streams that exceed link capacity when
aligned.

2. The assertion further down in the function:

    drm_WARN_ON(display->drm, slots != crtc_state->dp_m_n.tu);

will falsely and reliably trigger a kernel stack trace on any successful
modeset where alignment padding was applied (like on a 1-lane or 2-lane link
where 4 / lane_count alignment changes the raw TU count).

Additionally, this mismatch between the downstream branch device's DPCD
payload table (receiving the unaligned VCPI slot count) and the Intel TX
(transmitting the padded TU count) violates Bspec synchronization requirements
and risks payload corruption.

> +
> +			drm_dbg_kms(display->drm,
> +				    "MST TU %s pipe %c: clock=%d lanes=%d bpp=%d link_bpp=%d fec=%d\n",
> +				    connector->base.name,
> +				    pipe_name(to_intel_crtc(crtc_state->uapi.crtc)->pipe),
> +				    crtc_state->port_clock, crtc_state->lane_count,
> +				    fxp_q4_to_int(bpp_x16), fxp_q4_to_int(link_bpp_x16),
> +				    crtc_state->fec_enable);
> +			drm_dbg_kms(display->drm,
> +				    "MST TU %s: overhead=%d raw_pbn=%d pbn=%d pbn_div=%d tu=%d slots=%d full_pbn=%d\n",
> +				    connector->base.name,
> +				    remote_bw_overhead, raw_pbn,
> +				    dfixed_trunc(pbn), dfixed_trunc(mst_state->pbn_div),
> +				    remote_tu, slots, connector->mst.port->full_pbn);
>  
>  			/* TODO: Check this already in drm_dp_atomic_find_time_slots(). */
>  			if (slots > mst_state->total_avail_slots)

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