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

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

 



On Thu, 2021-08-26 at 14:11 +0300, Jani Nikula wrote:
> On Wed, 25 Aug 2021, Jani Nikula <jani.nikula@xxxxxxxxx> wrote:
> > On Thu, 19 Aug 2021, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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@xxxxxxxxx>
> > > > Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
> > > > ---
> > > >  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@xxxxxxxxx
> 
> 
> > 
> > BR,
> > Jani.
> > 
> > 
> > > 
> > > >         int ret;
> > > >  
> > > >         /*
> > > > -- 
> > > > 2.20.1
> 

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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux