All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manasi Navare <manasi.d.navare@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, rodrigo.vivi@intel.com
Subject: Re: [PATCH] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
Date: Wed, 26 Sep 2018 02:57:56 -0700	[thread overview]
Message-ID: <20180926095755.GB2619@intel.com> (raw)
In-Reply-To: <87tvmctx1j.fsf@intel.com>

Thanks Jani for backmerging the drm patch.

On Wed, Sep 26, 2018 at 12:42:16PM +0300, Jani Nikula wrote:
> On Thu, 13 Sep 2018, 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.
> >
> > This patch helps with backward compatibility for devices pre DP1.3.
> >
> > v2: read only dpcd values which can be affected, remove incorrect check,
> > split into drm include changes into separate patch, commit message,
> > verbose debugging statements during overwrite.
> > v3: white space fixes
> > v4: make path dependent on DPCD revision > 1.2
> > v5: split into function, removed DPCD rev check
> > v6: add debugging prints for early exit conditions
> >
> > Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
> 
> So I did the backmerge to get the DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT
> to dinq, and was about to merge... but I gotta nitpick here.
> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 58 +++++++++++++++++++++++++++++++++
> >  1 file changed, 58 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index dde92e4af5d3..1190635e4135 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3731,6 +3731,62 @@ intel_dp_link_down(struct intel_encoder *encoder,
> >  	}
> >  }
> >  
> > +static void
> > +intel_dp_extended_receiver_capabilities(struct intel_dp *intel_dp)
> > +{
> > +	/*
> > +	 * Prior to DP1.3 the bit represented by
> > +	 * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> > +	 * if it is set DP_DPCD_REV at 0000h could be at a value less than
> > +	 * the true capability of the panel. The only way to check is to
> > +	 * then compare 0000h and 2200h.
> > +	 */
> > +	if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > +	    DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) {
> 
> Reverse the condition, early exit, and make the rest of the function so
> much easier to read by decreasing indent.
> 

Yes that makes sense, so just exit early if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is not set

> > +		uint8_t dpcd_ext[6];
> 
> u8
> 
> > +
> > +		DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field Present, accessing 02200h through 022FFh\n");
> 
> Logging the offsets is excessive.
> 
> > +
> > +		if (drm_dp_dpcd_read(&intel_dp->aux, DP_DP13_DPCD_REV,
> > +				     &dpcd_ext, sizeof(dpcd_ext)) < 0) {
> 
> != sizeof(dpcd_ext) is more accurate.
>

+1 for this change.
 
> > +			DRM_ERROR("DPCD failed read at extended capabilities\n");
> > +			return;
> > +		}
> > +
> > +		if (intel_dp->dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
> > +			DRM_DEBUG_KMS("DPCD extended DPCD rev less than base DPCD rev\n");
> > +			return;
> > +		}
> > +
> > +		if (memcmp(&intel_dp->dpcd[DP_DPCD_REV], &dpcd_ext[DP_DPCD_REV],
> > +			   sizeof(u8))) {
> > +			DRM_DEBUG_KMS("DPCD: new value for DPCD Revision previous value %2x new value %2x\n",
> > +				      intel_dp->dpcd[DP_DPCD_REV],
> > +				      dpcd_ext[DP_DPCD_REV]);
> > +			memcpy(&intel_dp->dpcd[DP_DPCD_REV],
> > +			       &dpcd_ext[DP_DPCD_REV], sizeof(u8));
> > +		}
> 
> I presume earlier versions of the patch had memcmp/memcpy on the whole
> dpcd_ext, but if for some reason not present in the changelog you really
> need to do this piecemeal, please do not use memcmp/memcpy on
> sizeof(u8)! Ditto below.
> 
> BR,
> Jani.
> 
> > +		if (memcmp(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> > +			   &dpcd_ext[DP_MAX_LINK_RATE], sizeof(u8))) {
> > +			DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate previous value %2x new value %2x\n",
> > +				      intel_dp->dpcd[DP_MAX_LINK_RATE],
> > +				      dpcd_ext[DP_MAX_LINK_RATE]);
> > +			memcpy(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> > +			       &dpcd_ext[DP_MAX_LINK_RATE], sizeof(u8));

The other feedback here from Ville was that, the value of DP_MX_LINK_RATE set here
should be validated against the valid values in drm_dp_bw_code_to_link_rate() otherwise if the faulty panels set it to
a bad value, the driver will default to lowest rate of RBR/1.62Gbps

Manasi

> > +		}
> > +		if (memcmp(&intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > +			   &dpcd_ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
> > +			DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port Present  previous value %2x new value %2x\n",
> > +				      intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > +				      dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
> > +			memcpy(&intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > +			       &dpcd_ext[DP_DOWNSTREAMPORT_PRESENT],
> > +			       sizeof(u8));
> > +		}
> > +	}
> > +}
> > +
> > +
> >  bool
> >  intel_dp_read_dpcd(struct intel_dp *intel_dp)
> >  {
> > @@ -3738,6 +3794,8 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
> >  			     sizeof(intel_dp->dpcd)) < 0)
> >  		return false; /* aux transfer failed */
> >  
> > +	intel_dp_extended_receiver_capabilities(intel_dp);
> > +
> >  	DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), intel_dp->dpcd);
> >  
> >  	return intel_dp->dpcd[DP_DPCD_REV] != 0;
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2018-09-26 10:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13 21:17 [PATCH] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT matthew.s.atwood
2018-09-13 22:12 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-09-13 22:32 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-14  1:12 ` ✓ Fi.CI.IGT: " Patchwork
2018-09-18 21:19 ` [PATCH] " Manasi Navare
2018-09-18 21:36   ` Rodrigo Vivi
2018-09-26  9:42 ` Jani Nikula
2018-09-26  9:57   ` Manasi Navare [this message]

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=20180926095755.GB2619@intel.com \
    --to=manasi.d.navare@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.