All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "José Roberto de Souza" <jose.souza@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Subject: Re: [PATCH v2 5/6] drm/i915: Avoid a full port detection in the first eDP short pulse
Date: Thu, 11 Oct 2018 16:21:21 +0300	[thread overview]
Message-ID: <20181011132121.GI9144@intel.com> (raw)
In-Reply-To: <20181011004124.4110-5-jose.souza@intel.com>

On Wed, Oct 10, 2018 at 05:41:23PM -0700, José Roberto de Souza wrote:
> Some eDP panels do not set a valid sink count value and even for the
> ones that sets is should always be one for eDP, that is why it is not
> cached in intel_edp_init_dpcd().
> 
> But intel_dp_short_pulse() compares the old count with the read one
> if there is a mistmatch a full port detection will be executed, what
> was happening in the first short pulse interruption of eDP panels
> that sets sink count.
> 
> Instead of just skip the compasison for eDP panels, lets not read
> the sink count at all for eDP.
> 
> v2: the previous version of this patch was caching the sink count
> in intel_edp_init_dpcd() but I was pointed out by Ville a patch that
> handled a case of a eDP panel that do not set sink count
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 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 | 44 +++++++++++++++++++--------------
>  1 file changed, 26 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 13ff89be6ad6..1826d491efd7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4034,8 +4034,6 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>  static bool
>  intel_dp_get_dpcd(struct intel_dp *intel_dp)
>  {
> -	u8 sink_count;
> -
>  	if (!intel_dp_read_dpcd(intel_dp))
>  		return false;
>  
> @@ -4045,25 +4043,35 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>  		intel_dp_set_common_rates(intel_dp);
>  	}
>  
> -	if (drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &sink_count) <= 0)
> -		return false;
> -
>  	/*
> -	 * Sink count can change between short pulse hpd hence
> -	 * a member variable in intel_dp will track any changes
> -	 * between short pulse interrupts.
> +	 * Some eDP panels do not set a valid value for sink count, that is why
> +	 * it don't care about read it here and in intel_edp_init_dpcd().

Can't quite parse that.

"Some eDP panels do not set a valid value
 for sink count, so we ignore it."

or something like that perhaps.

>  	 */
> -	intel_dp->sink_count = DP_GET_SINK_COUNT(sink_count);
> +	if (!intel_dp_is_edp(intel_dp)) {
> +		u8 count;
> +		ssize_t r;
>  
> -	/*
> -	 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> -	 * a dongle is present but no display. Unless we require to know
> -	 * if a dongle is present or not, we don't need to update
> -	 * downstream port information. So, an early return here saves
> -	 * time from performing other operations which are not required.
> -	 */
> -	if (!intel_dp_is_edp(intel_dp) && !intel_dp->sink_count)
> -		return false;
> +		r = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &count);
> +		if (r < 1)
> +			return false;

My earlier suggestion was that we should keep reading this
anyway because some cts maybe required it. Would at least
avoid mixing in two functional changes into once patch.

> +
> +		/*
> +		 * Sink count can change between short pulse hpd hence
> +		 * a member variable in intel_dp will track any changes
> +		 * between short pulse interrupts.
> +		 */
> +		intel_dp->sink_count = DP_GET_SINK_COUNT(count);
> +
> +		/*
> +		 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> +		 * a dongle is present but no display. Unless we require to know
> +		 * if a dongle is present or not, we don't need to update
> +		 * downstream port information. So, an early return here saves
> +		 * time from performing other operations which are not required.
> +		 */
> +		if (!intel_dp->sink_count)
> +			return false;
> +	}
>  
>  	if (!drm_dp_is_branch(intel_dp->dpcd))
>  		return true; /* native DP sink */
> -- 
> 2.19.1

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-10-11 13:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11  0:41 [PATCH v2 1/6] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source() José Roberto de Souza
2018-10-11  0:41 ` [PATCH v2 2/6] drm/i915/psr: Always wait for idle state when disabling PSR José Roberto de Souza
2018-10-19 20:42   ` Dhinakaran Pandiyan
2018-10-19 20:47     ` Dhinakaran Pandiyan
2018-10-19 23:46     ` Souza, Jose
2018-10-24  1:33       ` Dhinakaran Pandiyan
2018-10-11  0:41 ` [PATCH v2 3/6] drm/i915/psr: Move intel_psr_disable_source() code to intel_psr_disable_locked() José Roberto de Souza
2018-10-19 20:55   ` Dhinakaran Pandiyan
2018-10-11  0:41 ` [PATCH v2 4/6] drm/i915: Disable PSR when a PSR aux error happen José Roberto de Souza
2018-10-19 23:14   ` Dhinakaran Pandiyan
2018-10-20  0:12     ` Souza, Jose
2018-10-24 22:08       ` Dhinakaran Pandiyan
2018-10-24 23:22         ` Dhinakaran Pandiyan
2018-10-24 23:31           ` Souza, Jose
2018-10-11  0:41 ` [PATCH v2 5/6] drm/i915: Avoid a full port detection in the first eDP short pulse José Roberto de Souza
2018-10-11 13:21   ` Ville Syrjälä [this message]
2018-10-19 23:20     ` Dhinakaran Pandiyan
2018-10-11  0:41 ` [PATCH v2 6/6] drm/i915: Check PSR errors instead of retrain while PSR is enabled José Roberto de Souza
2018-10-19 21:02   ` Dhinakaran Pandiyan
2018-10-20  0:57     ` Souza, Jose
2018-10-11  0:56 ` ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source() Patchwork
2018-10-11  1:16 ` ✓ Fi.CI.BAT: success " Patchwork
2018-10-11 10:26 ` ✓ Fi.CI.IGT: " Patchwork
2018-10-19 20:27 ` [PATCH v2 1/6] " Dhinakaran Pandiyan

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=20181011132121.GI9144@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jose.souza@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.