public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: Jan-Marek Glogowski <glogow@fbihome.de>,
	Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 1/3] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse()
Date: Fri, 07 Sep 2018 15:39:24 +0300	[thread overview]
Message-ID: <8736ul4h37.fsf@intel.com> (raw)
In-Reply-To: <20180907062135.30054-1-dhinakaran.pandiyan@intel.com>

On Thu, 06 Sep 2018, Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> wrote:
> Comment claims link needs to be retrained because the connected sink raised
> a long pulse to indicate link loss. If the sink did so,
> intel_dp_hotplug() would have handled link retraining. Looking at the
> logs in Bugzilla referenced in commit '3cf71bc9904d ("drm/i915: Re-apply
> Perform link quality check, unconditionally during long pulse"")', the
> issue is that the sink does not trigger an interrupt. We want the
> ->detect() from user space to check link status and retrain. Ville's
> review for the original patch also indicates the same root cause.
>
> I have also renamed long_pulse() to full_detect().

Since intel_dp_detect() doesn't actually do *anything* except skip
detect sometimes, I think "full detect" is a misnomer.

Arguably you could merge intel_dp_long_pulse() into its only caller,
intel_dp_detect(), and do an early return on skipping detect. You have
to look at the functions, and wonder if the current split is the right
one.

Please let others chime in too before making changes.

BR,
Jani.


>
> Cc: Lyude Paul <lyude@redhat.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jan-Marek Glogowski <glogow@fbihome.de>
> References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 17 +++++------------
>  1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 436c22de33b6..befdaa076d8c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5012,7 +5012,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>  }
>  
>  static int
> -intel_dp_long_pulse(struct intel_connector *connector,
> +intel_dp_full_detect(struct intel_connector *connector,
>  		    struct drm_modeset_acquire_ctx *ctx)
>  {
>  	struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -5074,16 +5074,8 @@ intel_dp_long_pulse(struct intel_connector *connector,
>  		goto out;
>  	} else {
>  		/*
> -		 * If display is now connected check links status,
> -		 * there has been known issues of link loss triggering
> -		 * long pulse.
> -		 *
> -		 * Some sinks (eg. ASUS PB287Q) seem to perform some
> -		 * weird HPD ping pong during modesets. So we can apparently
> -		 * end up with HPD going low during a modeset, and then
> -		 * going back up soon after. And once that happens we must
> -		 * retrain the link to get a picture. That's in case no
> -		 * userspace component reacted to intermittent HPD dip.
> +		 * Check link status in case the link went out of
> +		 * synchronization and the sink did not tell us.
>  		 */
>  		struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>  
> @@ -5149,7 +5141,8 @@ intel_dp_detect(struct drm_connector *connector,
>  				return ret;
>  		}
>  
> -		status = intel_dp_long_pulse(intel_dp->attached_connector, ctx);
> +		status = intel_dp_full_detect(intel_dp->attached_connector,
> +					      ctx);
>  	}
>  
>  	intel_dp->detect_done = false;

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-09-07 12:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07  6:21 [PATCH 1/3] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() Dhinakaran Pandiyan
2018-09-07  6:21 ` [PATCH 2/3] drm/i915/dp: Restrict link retrain workaround to external monitors Dhinakaran Pandiyan
2018-09-07 14:34   ` Ville Syrjälä
2018-09-07 16:25     ` Manasi Navare
2018-09-07 18:31       ` Dhinakaran Pandiyan
2018-09-07 19:18         ` Ville Syrjälä
2018-09-10 20:03           ` Dhinakaran Pandiyan
2018-09-07  6:21 ` [PATCH 3/3] drm/i915/psr: Enable PSR1 on gen-9+ HW Dhinakaran Pandiyan
2018-09-07 15:35   ` Nathan Ciobanu
2018-09-07 18:36     ` Dhinakaran Pandiyan
2018-09-07  7:58 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() Patchwork
2018-09-07  8:16 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-07  9:27 ` ✓ Fi.CI.IGT: " Patchwork
2018-09-07 12:39 ` Jani Nikula [this message]
2018-09-07 14:32   ` [PATCH 1/3] " Ville Syrjälä
2018-09-07 16:31     ` Manasi Navare
2018-09-07 18:25     ` 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=8736ul4h37.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=glogow@fbihome.de \
    --cc=intel-gfx@lists.freedesktop.org \
    --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