On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
> On Tue, 01 Sep 2020, Lyude Paul <lyude@xxxxxxxxxx> wrote:
> > On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> > > In the future, we'll be needing more of the extended receiver capability
> > > field starting at DPCD address 0x2200. (Specifically, we'll need main
> > > link channel coding cap for DP 2.0.) Start using it now to not miss out
> > > later on.
> > >
> > > Cc: Lyude Paul <lyude@xxxxxxxxxx>
> > > Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
> > >
> > > ---
> > >
> > > I guess this can be merged after the topic branch to drm-misc-next or
> > > so, but I'd prefer to have this fairly early on to catch any potential
> > > issues.
> > > ---
> > > 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 1e7c638873c8..3a3c238452df 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -436,7 +436,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_RECEIVER_CAP_SIZE];
> >
> > Not 100% sure this is right? It's not clear at first glance of the 2.0
> > spec, but
> > my assumption would be that on < DP2.0 devices that everything but those
> > first 6
> > bytes are zeroed out in the extended DPRX field. Since we memcpy()
> > dpcd_ext
> > using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the
> > DPCD caps
> > that comes after those 6 bytes.
>
> Re-reading stuff... AFAICT everything in 0x2200..0x220F should be
> valid. They should match what's in 0x0000..0x000F except for 0x0000,
> 0x0001, and 0x0005, for backwards compatibility.
>
> Apparently there are no such backwards compatibility concerns with the
> other receiver cap fields then.
>
> But it gives me an uneasy feeling that many places in the spec refer to
> 0x2200+ even though they should per spec be the same in 0x0000+.
>
> I guess we can try without the change, and fix later if we hit issues.
I'm fine with the change if it doesn't break things btw - just as long as
we're making sure that we don't zero things out by accident
>
>
> BR,
> Jani.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
