> -----Original Message----- > From: Nikula, Jani <jani.nikula@xxxxxxxxx> > Sent: Tuesday, January 9, 2024 2:58 PM > To: Murthy, Arun R <arun.r.murthy@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; > Deak, Imre <imre.deak@xxxxxxxxx> > Subject: RE: [PATCH] drm/i915/display/dp: 128/132b DP-capable with SST > > On Tue, 09 Jan 2024, "Murthy, Arun R" <arun.r.murthy@xxxxxxxxx> wrote: > >> -----Original Message----- > >> From: Nikula, Jani <jani.nikula@xxxxxxxxx> > >> Sent: Monday, January 8, 2024 7:01 PM > >> To: Murthy, Arun R <arun.r.murthy@xxxxxxxxx>; > >> intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Deak, Imre <imre.deak@xxxxxxxxx> > >> Cc: Murthy, Arun R <arun.r.murthy@xxxxxxxxx> > >> Subject: Re: [PATCH] drm/i915/display/dp: 128/132b DP-capable with > >> SST > >> > >> On Wed, 03 Jan 2024, Arun R Murthy <arun.r.murthy@xxxxxxxxx> wrote: > >> > With a value of '0' read from MSTM_CAP register MST to be enabled. > >> > DP2.1 SCR updates the spec for 128/132b DP capable supporting only > >> > one stream and not supporting single stream sideband MSG. > >> > The underlying protocol will be MST to enable use of MTP. > >> > > >> > Signed-off-by: Arun R Murthy <arun.r.murthy@xxxxxxxxx> > >> > --- > >> > drivers/gpu/drm/i915/display/intel_dp.c | 9 +++++++-- > >> > 1 file changed, 7 insertions(+), 2 deletions(-) > >> > > >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > >> > b/drivers/gpu/drm/i915/display/intel_dp.c > >> > index 9ff0cbd9c0df..40d3280f8d98 100644 > >> > --- a/drivers/gpu/drm/i915/display/intel_dp.c > >> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > >> > @@ -4038,8 +4038,13 @@ intel_dp_configure_mst(struct intel_dp > *intel_dp) > >> > if (!intel_dp_mst_source_support(intel_dp)) > >> > return; > >> > > >> > - intel_dp->is_mst = sink_can_mst && > >> > - i915->display.params.enable_dp_mst; > >> > + /* > >> > + * Even if dpcd reg MSTM_CAP is 0, if the sink supports UHBR > >> > + rates > >> then > >> > + * DP2.1 can be enabled with underlying protocol using MST for MTP > >> > + */ > >> > + intel_dp->is_mst = (sink_can_mst || > >> > + > >> drm_dp_is_uhbr_rate(intel_dp_max_common_rate(intel_dp))) > >> > + && i915->display.params.enable_dp_mst; > >> > >> We use drm_dp_is_uhbr_rate() in intel_dp_is_uhbr() to determine > >> whether the link rate in the *crtc state* is uhbr, and by proxy > >> whether the link in the *crtc > >> state* is 128b/132b. > >> > > Yes! If the link rate in crtc_state is not uhbr then we dont enable 128/132b. > Also the return from drm_dp_read_mst_cap() return 0 or 1 and if not mst then > 128/132b is not enabled. We need to deviate here and a value of bit[0]=0, > bit[1]=0 in MSTM_CAP register is 128/132b with SST. Hence this hack is added > to see if the return from MSTM_CAP is 0x00 and if uhbr rates are supported > then enable 128/132b. > > Per spec it depends on intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & > DP_CAP_ANSI_128B132B, why not use that here too? > Done! Thanks and Regards, Arun R Murthy ------------------- > > > >> There, we've already decided to use uhbr and 128b/132b. > >> > >> This one here is different, and I think it's taking us to the wrong > >> direction. For example, it should be possible to downgrade the link > >> from uhbr to non-uhbr on link failures. We don't have that yet. But > >> this makes untangling that even harder. > > > > Yes upon having the fallback, I think we will have to handle fallback in this > case separately. Change might be required in drm core, > drm_dp_read_mst_cap() should consider the DP2.1 changes to accommodate > this 0x00 value. > > > > Will be floating the fallback patches very soon. > > > > Thanks and Regards, > > Arun R Murthy > > -------------------- > >> > >> > >> BR, > >> Jani. > >> > >> > >> > > >> > drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr, > >> > intel_dp->is_mst); > >> > >> -- > >> Jani Nikula, Intel > > -- > Jani Nikula, Intel
