From: Jani Nikula <jani.nikula@linux.intel.com>
To: Xiao Lu <xiaolu.xie@intel.com>, intel-gfx@lists.freedesktop.org
Cc: joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
tvrtko.ursulin@linux.intel.com, Xiao Lu <xiaolu.xie@intel.com>
Subject: Re: [PATCH] drm/i915/dp: fix PBN in ALLOCATE_PAYLOAD request to use actual video bandwidth
Date: Tue, 22 Sep 2026 12:04:39 +0300 [thread overview]
Message-ID: <ebfe85875a9d47151426913de39e49159498be8e@intel.com> (raw)
In-Reply-To: <20260922081258.1995510-1-xiaolu.xie@intel.com>
On Tue, 22 Sep 2026, Xiao Lu <xiaolu.xie@intel.com> wrote:
> When computing the number of time slots for an MST stream,
> intel_dp_mtp_tu_compute_config() was passing the TU-aligned PBN value
> to drm_dp_atomic_find_time_slots() instead of the actual video
> bandwidth PBN.
>
> The aligned PBN is computed by rounding up the raw video bandwidth to
> the nearest TU boundary and aligning to the hardware TU granularity
> (4 / lane_count). This inflated PBN is then used as the requested PBN
> in the ALLOCATE_PAYLOAD sideband message, causing the MST core's
> bandwidth check in drm_dp_mst_atomic_check_port_bw_limit() to
> incorrectly reject configurations that should fit within the available
> link bandwidth.
>
> Per DP v2.1b Section 2.6.4.1, the PBN in an ALLOCATE_PAYLOAD request
> represents the video stream bandwidth and is independent of the source
> TX link rate. The same video stream should result in the same PBN value
> regardless of the link rate used on the source side. Passing the
> TU-aligned PBN violates this requirement, as it incorporates link-rate-
> specific TU granularity into the payload bandwidth value.
>
> This was observed in a 3-display MST daisy-chain topology (PS8650 MST
> hub → ViewSonic VP2468 × 2 → Lenovo Pro 27UD-10) where switching
> Lenovo to 4K@60Hz failed with -ENOSPC despite the actual video
> bandwidth fitting within the DFP link capacity. The inflated PBN of
> the VP2468 streams (537 instead of the correct 532 for 1920x1080@60Hz)
> consumed excess slots, leaving insufficient room for the 4K@60Hz stream.
>
> Fix this by separating raw_pbn (the actual video bandwidth used for
> payload allocation and ALLOCATE_PAYLOAD) from the aligned pbn (used
> only for TU hardware programming). Pass raw_pbn to
> drm_dp_atomic_find_time_slots() so that bandwidth accounting in the
> MST core reflects the true stream requirements.
>
> Depends-on: <20260908132844.2309047-1-xiaolu.xie@intel.com>
> ("drm/dp/mst: track allocated_pbn from ALLOCATE_PAYLOAD reply")
This is not a thing. If you have multiple patches with dependencies,
please send them together.
BR,
Jani.
>
> The companion patch above tracks the allocated_pbn returned in the
> ALLOCATE_PAYLOAD reply from the branch device. Together with this fix,
> the correct raw_pbn is used as the requested PBN in the
> ALLOCATE_PAYLOAD request, and the allocated_pbn from the reply is used
> for bandwidth limit checks. This pairing ensures that both the request
> and the check accurately reflect the actual video stream bandwidth
> and any per-hop capacity constraints along the MST path.
>
> Signed-off-by: Xiao Lu <xiaolu.xie@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 33 +++++++++++++++------
> 1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 0c362784a..31e846aad 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -350,6 +350,7 @@ int intel_dp_mtp_tu_compute_config(struct intel_dp *intel_dp,
> if (is_mst) {
> int remote_bw_overhead;
> int remote_tu;
> + int raw_pbn;
> fixed20_12 pbn;
>
> remote_bw_overhead = intel_dp_mst_bw_overhead(crtc_state,
> @@ -369,9 +370,10 @@ int intel_dp_mtp_tu_compute_config(struct intel_dp *intel_dp,
> * crtc_state->dp_m_n.tu), provided that the driver doesn't
> * enable SSC on the corresponding link.
> */
> - pbn.full = dfixed_const(intel_dp_mst_calc_pbn(adjusted_mode->crtc_clock,
> - link_bpp_x16,
> - remote_bw_overhead));
> + raw_pbn = intel_dp_mst_calc_pbn(adjusted_mode->crtc_clock,
> + link_bpp_x16,
> + remote_bw_overhead);
> + pbn.full = dfixed_const(raw_pbn);
> remote_tu = DIV_ROUND_UP(pbn.full, mst_state->pbn_div.full);
>
> /*
> @@ -384,11 +386,10 @@ int intel_dp_mtp_tu_compute_config(struct intel_dp *intel_dp,
> remote_tu = ALIGN(remote_tu, 4 / crtc_state->lane_count);
>
> /*
> - * Also align PBNs accordingly, since MST core will derive its
> - * own copy of TU from the PBN in drm_dp_atomic_find_time_slots().
> - * The above comment about the difference between the PBN
> - * allocated for the whole path and the TUs allocated for the
> - * first branch device's link also applies here.
> + * Keep the PBN corresponding to the aligned hardware TU separate
> + * from raw_pbn. The aligned value describes the TU granularity of
> + * the first downstream branch link; raw_pbn is the video bandwidth
> + * value passed to the MST payload allocator and ALLOCATE_PAYLOAD.
> */
> pbn.full = remote_tu * mst_state->pbn_div.full;
>
> @@ -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);
> +
> + 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)
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-09-22 9:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 8:12 [PATCH] drm/i915/dp: fix PBN in ALLOCATE_PAYLOAD request to use actual video bandwidth Xiao Lu
2026-09-22 8:24 ` sashiko-bot
2026-09-22 9:04 ` Jani Nikula [this message]
2026-09-22 12:15 ` ✓ i915.CI.BAT: success for " Patchwork
2026-09-22 22:10 ` ✗ i915.CI.Full: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ebfe85875a9d47151426913de39e49159498be8e@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=xiaolu.xie@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.