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 <[email protected]> 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/[email protected]?part=1
