RE: [PATCH] drm/i915/display/dp: 128/132b DP-capable with SST

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Nikula, Jani <jani.nikula@xxxxxxxxx>
> Sent: Wednesday, January 10, 2024 4:24 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 Wed, 10 Jan 2024, "Murthy, Arun R" <arun.r.murthy@xxxxxxxxx> wrote:
> >> -----Original Message-----
> >> From: Nikula, Jani <jani.nikula@xxxxxxxxx>
> >> Sent: Tuesday, January 9, 2024 2:59 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, Jani Nikula <jani.nikula@xxxxxxxxx> wrote:
> >> > 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?
> >>
> >> Also, shouldn't we ensure we don't try to do more than one stream?
> >>
> > Yes, this will be taken care of in a separate patch, tracked as part of separate
> JIRA. VLK-55112.
> 
> Well, you shouldn't really first open the possibility for a broken config, and then
> say it'll be taken care of in the future.
> 

Sorry, I misread it as single stream sideband msg. As per the transport is considered not more than one stream will be considered(In this case MSTM_CAP=0x00) based on the sink capability.
If a hub is connected inbetween the panel and the source, then source reads MSTM_CAP as 1xb and native MST will be enabled.

Thanks and Regards,
Arun R Murthy
--------------------
> BR,
> Jani.
> 
> 
> --
> Jani Nikula, Intel




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux