Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Manasi Navare <manasi.d.navare@intel.com>
To: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: intel-gfx@lists.freedesktop.org, paulo.r.zanoni@intel.com,
	rodrigo.vivi@intel.com
Subject: Re: [PATCH] drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
Date: Wed, 16 May 2018 15:23:07 -0700	[thread overview]
Message-ID: <20180516222306.GF2730@intel.com> (raw)
In-Reply-To: <1526509912.17473.152.camel@intel.com>

On Wed, May 16, 2018 at 03:31:52PM -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-05-16 at 09:33 -0700, matthew.s.atwood@intel.com wrote:
> > From: Matt Atwood <matthew.s.atwood@intel.com>
> > 
> > According to DP spec (2.9.3.1 of DP 1.4) if
> > EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
> > DPCD
> > 02200h through 0220Fh shall contain the DPRX's true capability. These
> > values will match 00000h through 0000Fh, except for DPCD_REV,
> > MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> > 
> > Read from DPCD once for all 3 values as this is an expensive
> > operation.
> > Spec mentions that all of address space 02200h through 0220Fh should
> > contain the right information however currently only 3 values can
> > differ.
> > 
> > There is no address space in the intel_dp->dpcd struct for addresses
> > 02200h through 0220Fh, and since so much of the data is a identical,
> > simply overwrite the values stored in 00000h through 0000Fh with the
> > values that can be overwritten from addresses 02200h through 0220Fh
> 
> Why overwrite all values if this is an expensive operation? From what I
> can see, you'll need to read only 0000h - 00005h
> 
> > 
> > Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 14 ++++++++++++++
> >  include/drm/drm_dp_helper.h     |  5 +++--
> >  2 files changed, 17 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index dde92e4af5d3..899ebc5cece6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3738,6 +3738,20 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
> >  			     sizeof(intel_dp->dpcd)) < 0)
> >  		return false; /* aux transfer failed */
> >  
> > +	if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > +	    DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT &&
> > +	    intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14) {
> 
> The same section in the spec also says - "The Extended Receiver
> Capability registers at DPCD Addresses 02200h through 0220Fh shall
> contain the DPRX’s true capability, while the original Base Receiver
> Capability registers at DPCD Addresses 00000h through 0000Fh might
> indicate DPCD r1.1, a MAX_LINK_RATE of 2.7Gbps/lane, and no DFP to
> avoid interoperability issues ..."
> 
> Which means, intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14 is probably
> not going to be true for panels you want to read the extended
> capabilities for.

Yes thats a good point. So just check on the EXTENDED_EXTENDED_RECEIVER_CAP_FIELD_PRESENT
should suffice.
 
> 
> > +		uint8_t dpcd_ext[16];
> > +
> > +		if (drm_dp_dpcd_read(&intel_dp->aux,
> > DP_DP13_DPCD_REV,
> > +		    &dpcd_ext, sizeof(dpcd_ext)) < 0)
> > +			return false; /* aux transfer failed */
> > +
> > +		intel_dp->dpcd[DP_DPCD_REV] = dpcd_ext[DP_DPCD_REV];
> > +		intel_dp->dpcd[DP_MAX_LINK_RATE] =
> > dpcd_ext[DP_MAX_LINK_RATE];
> > +		intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] =
> > +			dpcd_ext[DP_DOWNSTREAMPORT_PRESENT];
> > +	}
> >  	DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> > intel_dp->dpcd);
> >  
> >  	return intel_dp->dpcd[DP_DPCD_REV] != 0;
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index c01564991a9f..757bd5913f3d 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> 
> This should be a separate patch as it's outside i915.

And also send this patch to dri-devel M-L

Manasi

> 
> > @@ -123,8 +123,9 @@
> >  # define DP_FRAMING_CHANGE_CAP		    (1 << 1)
> >  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE     (1 << 3) /* edp v1.2 or
> > higher */
> >  
> > -#define DP_TRAINING_AUX_RD_INTERVAL         0x00e   /* XXX 1.2? */
> > -# define DP_TRAINING_AUX_RD_MASK            0x7F    /* XXX 1.2? */
> > +#define DP_TRAINING_AUX_RD_INTERVAL             0x00e   /* XXX 1.2?
> > */
> > +# define DP_TRAINING_AUX_RD_MASK                0x7F    /* XXX 1.2?
> > */
> > +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* XXX 1.2?
> > */
> >  
> >  #define DP_ADAPTER_CAP			    0x00f   /* 1.2 */
> >  # define DP_FORCE_LOAD_SENSE_CAP	    (1 << 0)
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-16 22:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-16 16:33 [PATCH] drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT matthew.s.atwood
2018-05-16 17:17 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-05-16 17:33 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-16 22:31 ` [PATCH] " Dhinakaran Pandiyan
2018-05-16 22:23   ` Manasi Navare [this message]
2018-05-17  9:50   ` Jani Nikula
2018-05-17 15:29     ` Atwood, Matthew S
2018-05-17 17:53       ` Jani Nikula
2018-05-17  1:27 ` ✓ Fi.CI.IGT: success for " Patchwork
2018-06-26  0:39 ` [PATCH] " Manasi Navare
2018-06-26 14:54   ` Atwood, Matthew S
2018-07-10 18:51     ` Manasi Navare

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=20180516222306.GF2730@intel.com \
    --to=manasi.d.navare@intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=rodrigo.vivi@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