All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Souza, Jose" <jose.souza@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>,
	"Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 3/4] drm/i915: Cache sink_count for eDP
Date: Wed, 10 Oct 2018 01:09:38 +0000	[thread overview]
Message-ID: <1eb69bbebaa24b1f20f6ba18d9b4c2c4b2502306.camel@intel.com> (raw)
In-Reply-To: <20181009132718.GG9144@intel.com>

On Tue, 2018-10-09 at 16:27 +0300, Ville Syrjälä wrote:
> On Mon, Oct 08, 2018 at 05:54:17PM -0700, Dhinakaran Pandiyan wrote:
> > On Mon, 2018-10-08 at 17:35 -0700, Souza, Jose wrote:
> > > On Mon, 2018-10-08 at 17:19 -0700, Dhinakaran Pandiyan wrote:
> > > > On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> > > > > For eDP panels all the DPCD and EDID data is cached when
> > > > > initializing
> > > > > the eDP connector so in futher detection it do not call
> > > > > intel_dp_detect_dpcd() for eDP.
> > > > > The problem is on the first short pulse interruption it calls
> > > > > intel_dp_get_dpcd() for eDP and DP and it will read and set
> > > > > the
> > > > > sink
> > > > > count, causing a mismatch between old sink count and the new
> > > > > one
> > > > > triggering a full detection without needed.
> > > > > 
> > > > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_dp.c | 5 +++++
> > > > >  1 file changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 19f0c3f59cbe..4a1c31ec9065 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -3926,6 +3926,7 @@ intel_edp_init_dpcd(struct intel_dp
> > > > > *intel_dp)
> > > > >  {
> > > > >  	struct drm_i915_private *dev_priv =
> > > > >  		to_i915(dp_to_dig_port(intel_dp)-
> > > > > >base.base.dev);
> > > > > +	u8 val;
> > > > >  
> > > > >  	/* this function is meant to be called only once */
> > > > >  	WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > > > > @@ -3997,6 +3998,10 @@ intel_edp_init_dpcd(struct intel_dp
> > > > > *intel_dp)
> > > > >  
> > > > >  	intel_dp_set_common_rates(intel_dp);
> > > > >  
> > > > > +	if (drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT,
> > > > > &val) <=
> > > > > 0)
> > > > > +		return false;
> > > > > +	intel_dp->sink_count = DP_GET_SINK_COUNT(val);
> > > > 
> > > > Is this even relevant for eDPs? Seems unnecessary to read or
> > > > compare
> > > > sink count for eDP. I'd suggest skipping DP_SINK_COUNT checks
> > > > for
> > > > eDP.
> > > 
> > > I'm not sure as DP specs for DP_SINK_COUNT says:
> > > 
> > > The Sink device shall add one more if it has a local Rendering
> > > Function.
> > > 
> > > and eDP spec do not redefine or alter this, so I guess is more
> > > safe
> > > also read for eDP too.
> > > 
> > 
> > We already special case eDP in several places, for example, don't
> > update link rates from the short pulse handler etc. And also don't
> > support hotplug, I don't see a point.
> 
> IIRC some conformance test or something required that we read this.
> I guess what we could do is still read it but just not update
> intel_dp->sink_count. We already seem to have a special case which
> ignores a zero sink_count on eDP. Might as well extend that a bit
> I suppose.

Okay, I will skip the comparison for eDP.

> 
> In general I think special cases are bad, so IMO we should try
> hard not add more unless really necessary. In this case it seems
> the special case is warranted. Unfortunately commit 1034ce707b57
> ("drm/i915: Fixing eDP detection on certain platforms") failed to add
> a comment explaining why. I'd appreciate if someone could add that
> comment now so that we don't forget this in the future.

Sure, I will add this comment.

> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-10-10  1:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-05 23:35 [PATCH 1/4] drm/i915/psr: Always wait for idle state when disabling PSR José Roberto de Souza
2018-10-05 23:35 ` [PATCH 2/4] drm/i915: Disable PSR when a PSR aux error happen José Roberto de Souza
2018-10-09  0:14   ` Dhinakaran Pandiyan
2018-10-09  0:30     ` Souza, Jose
2018-10-09  0:49       ` Dhinakaran Pandiyan
2018-10-09  0:57         ` Souza, Jose
2018-10-05 23:35 ` [PATCH 3/4] drm/i915: Cache sink_count for eDP José Roberto de Souza
2018-10-09  0:19   ` Dhinakaran Pandiyan
2018-10-09  0:35     ` Souza, Jose
2018-10-09  0:54       ` Dhinakaran Pandiyan
2018-10-09 13:27         ` Ville Syrjälä
2018-10-10  1:09           ` Souza, Jose [this message]
2018-10-05 23:35 ` [PATCH 4/4] drm/i915: Check PSR errors instead of retrain while PSR is enabled José Roberto de Souza
2018-10-06  0:50 ` ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/psr: Always wait for idle state when disabling PSR Patchwork
2018-10-06  1:10 ` ✓ Fi.CI.BAT: success " Patchwork
2018-10-06  8:52 ` ✓ Fi.CI.IGT: " Patchwork
2018-10-08 22:43 ` [PATCH 1/4] " Dhinakaran Pandiyan
2018-10-10  1:12   ` Souza, Jose

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=1eb69bbebaa24b1f20f6ba18d9b4c2c4b2502306.camel@intel.com \
    --to=jose.souza@intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --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 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.