public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Lyude Paul <lyude@redhat.com>
To: "Jani Nikula" <jani.nikula@intel.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Manasi Navare <manasi.d.navare@intel.com>
Subject: Re: [Intel-gfx] [PATCH 2/4] drm/dp: use more of the extended receiver cap
Date: Thu, 26 Aug 2021 15:41:05 -0400	[thread overview]
Message-ID: <76e484cc5146e2ffd63aecff1e6bdb2803a772a0.camel@redhat.com> (raw)
In-Reply-To: <87lf4ocvfn.fsf@intel.com>

On Thu, 2021-08-26 at 14:11 +0300, Jani Nikula wrote:
> On Wed, 25 Aug 2021, Jani Nikula <jani.nikula@intel.com> wrote:
> > On Thu, 19 Aug 2021, Ville Syrjälä <ville.syrjala@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@intel.com>
> > > > Signed-off-by: Jani Nikula <jani.nikula@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


  reply	other threads:[~2021-08-26 19:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13 10:43 [Intel-gfx] [PATCH 0/4] drm/dp: add some defines and prep for DP 2.0 Jani Nikula
2021-08-13 10:43 ` [Intel-gfx] [PATCH 1/4] drm/dp: add DP 2.0 UHBR link rate and bw code conversions Jani Nikula
2021-08-13 10:43 ` [Intel-gfx] [PATCH 2/4] drm/dp: use more of the extended receiver cap Jani Nikula
2021-08-19 17:16   ` Ville Syrjälä
2021-08-25 14:30     ` Jani Nikula
2021-08-26 11:11       ` Jani Nikula
2021-08-26 19:41         ` Lyude Paul [this message]
2021-08-13 10:43 ` [Intel-gfx] [PATCH 3/4] drm/dp: add LTTPR DP 2.0 DPCD addresses Jani Nikula
2021-08-13 10:43 ` [Intel-gfx] [PATCH 4/4] drm/dp: add helper for extracting adjust 128b/132b TX FFE preset Jani Nikula
2021-08-13 11:53 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp: add some defines and prep for DP 2.0 Patchwork
2021-08-13 15:14 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76e484cc5146e2ffd63aecff1e6bdb2803a772a0.camel@redhat.com \
    --to=lyude@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=manasi.d.navare@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox