[Intel-gfx] [PATCH 2/4] drm/dp: use more of the extended receiver cap

Lyude Paul lyude at redhat.com
Thu Aug 26 19:41:05 UTC 2021


On Thu, 2021-08-26 at 14:11 +0300, Jani Nikula wrote:
> On Wed, 25 Aug 2021, Jani Nikula <jani.nikula at intel.com> wrote:
> > On Thu, 19 Aug 2021, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > > On Fri, Aug 13, 2021 at 01:43:20PM +0300, Jani Nikula wrote:
> > > > Extend the use of extended receiver cap at 0x2200 to cover
> > > > MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation
> > > > hides
> > > > the DP 2.0 128b/132b channel encoding cap.
> > > > 
> > > > Cc: Manasi Navare <manasi.d.navare at intel.com>
> > > > Signed-off-by: Jani Nikula <jani.nikula at intel.com>
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 9b2a2961fca8..9389f92cb944 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -608,7 +608,7 @@ static u8 drm_dp_downstream_port_count(const u8
> > > > dpcd[DP_RECEIVER_CAP_SIZE])
> > > >  static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> > > >                                           u8
> > > > dpcd[DP_RECEIVER_CAP_SIZE])
> > > >  {
> > > > -       u8 dpcd_ext[6];
> > > > +       u8 dpcd_ext[DP_MAIN_LINK_CHANNEL_CODING + 1];
> > > 
> > > Why are we even reading less of this than the normal receiver caps?
> > 
> > Good question. I forget my reasoning to only extend to what might affect
> > this use case. Should we extend to the size of the usual receiver caps?
> 
> Ah, there was a previous discussion [1] with Lyude (Cc'd).

Yeah - basically the problem is that we just need to make sure we take care to
avoid clearing info from the non-extended DPCD by accident. Extending this to
7 bits should be fine.

JFYI reading back at your comments it sounds like we might actually be safe to
read the entire DPCD, but we need to make sure we take care to avoid
accidentally replacing the main DPCD with a zeroed-out DPCD which could happen
on systems that have no support for extended DPCDs.

(Also - super bonus points if you can write a unit test to confirm we're not
overwriting the original DPCD! I don't know how much effort this would be
though so don't worry about it too much)

> 
> BR,
> Jani.
> 
> 
> [1]
> https://patchwork.freedesktop.org/patch/msgid/20200901123226.4177-1-jani.nikula@intel.com
> 
> 
> > 
> > BR,
> > Jani.
> > 
> > 
> > > 
> > > >         int ret;
> > > >  
> > > >         /*
> > > > -- 
> > > > 2.20.1
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat



More information about the Intel-gfx mailing list