On Wed, Nov 15, 2023 at 03:41:08PM +0200, Murthy, Arun R wrote:
>
>
> > -----Original Message-----
> > From: Intel-gfx <intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Imre
> > Deak
> > Sent: Wednesday, November 15, 2023 7:08 PM
> > To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > Subject: Re: [PATCH 3/4] drm/i915/dp_mst: Fix PBN / MTP_TU size
> > calculation for UHBR rates
> >
> > On Mon, Nov 13, 2023 at 10:11:09PM +0200, Imre Deak wrote:
> > > Atm the allocated MST PBN value is calculated from the TU size (number
> > > of allocated MTP slots) as
> > >
> > > PBN = TU * pbn_div
> > >
> > > pbn_div being the link BW for each MTP slot. For DP 1.4 link rates
> > > this worked, as pbn_div there is guraranteed to be an integer number,
> > > however on UHBR this isn't the case. To get a PBN, TU pair where TU is
> > > a properly rounded-up value covering all the BW corresponding to PBN,
> > > calculate first PBN and from PBN the TU value.
> > >
> > > Signed-off-by: Imre Deak <imre.deak@xxxxxxxxx>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++++++++--
> > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index b943dbf394a22..a32ab0b4fc9d7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -170,6 +170,7 @@ static int
> > > intel_dp_mst_find_vcpi_slots_for_bpp(struct intel_encoder *encoder,
> > >
> > > for (bpp = max_bpp; bpp >= min_bpp; bpp -= step) {
> > > struct intel_link_m_n remote_m_n;
> > > + int alloc_tu;
> > > int link_bpp;
> > >
> > > drm_dbg_kms(&i915->drm, "Trying bpp %d\n", bpp); @@ -
> > 200,9 +201,14
> > > @@ static int intel_dp_mst_find_vcpi_slots_for_bpp(struct intel_encoder
> > *encoder,
> > > * crtc_state->dp_m_n.tu), provided that the driver doesn't
> > > * enable SSC on the corresponding link.
> > > */
> > > + crtc_state->pbn =
> > DIV_ROUND_UP_ULL(mul_u32_u32(mst_state->pbn_div * 64,
> > > +
> > remote_m_n.data_m),
> > > + remote_m_n.data_n);
> >
> > I realized this may allocate fewer PBNs than required, since the actual pbn_div
> > value is not an integer. Also PBN can be calculated in a more direct way from
> > the effective pixel data rate, so I'd like to do that instead.
> >
> > I'll send a new version with the above changes.
> >
> Also spec says about a constant value of 64 for TU size.
I suppose you refer to WA 14013163432 (Bspec / 54369), yes we considered
this with Ville. For that one data M/N needs to be configured for full
BW utilization, that is M=TU-size N=64. It's for the case where FEC is
enabled and applies to ADLP A0-C0 only (need to check other platforms).
The corresponding issue is supposed to be fixed on ADLP D0 (which
requires enabling some HW workarounds), so not sure if/how we should
enable this SW WA.
> Thanks and Regards,
> Arun R Murthy
> -------------------
> > > +
> > > + alloc_tu = DIV_ROUND_UP_ULL(crtc_state->pbn, mst_state-
> > >pbn_div);
> >
> >
> > > + drm_WARN_ON(&i915->drm, alloc_tu < remote_m_n.tu);
> > > drm_WARN_ON(&i915->drm, remote_m_n.tu < crtc_state-
> > >dp_m_n.tu);
> > > - crtc_state->dp_m_n.tu = remote_m_n.tu;
> > > - crtc_state->pbn = remote_m_n.tu * mst_state->pbn_div;
> > > + crtc_state->dp_m_n.tu = alloc_tu;
> > >
> > > slots = drm_dp_atomic_find_time_slots(state, &intel_dp-
> > >mst_mgr,
> > > connector->port,
> > > --
> > > 2.39.2
> > >
