Attachment 140956 Details for Bug 107446 – Fix: Re-apply "Perform link quality check unconditionally during long pulse"

[patch] Fix: Re-apply "Perform link quality check unconditionally during long pulse"

0001-drm-i915-Re-apply-Perform-link-quality-check-uncondi.patch (text/plain), 3.27 KB, created by Jan-Marek Glogowski on 2018-08-03 16:55:00 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jan-Marek Glogowski

Created: 2018-08-03 16:55:00 UTC

Size: 3.27 KB

patch

obsolete

>From edf159ae0426d9c90bf974629d83dc50c002bc52 Mon Sep 17 00:00:00 2001
>From: Jan-Marek Glogowski <glogow@fbihome.de>
>Date: Fri, 3 Aug 2018 15:30:55 +0000
>Subject: [PATCH] drm/i915: Re-apply "Perform link quality check
> unconditionally during long pulse"
>
>This re-applies the workaround for "some DP sinks, [which] are a
>little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
>quality check unconditionally during long pulse").
>It makes the secondary AOC E2460P monitor connected via DP to an
>acer Veriton N4640G usable again.
>
>This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
>DP link retraining into the ->post_hotplug() hook")
>
>Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
>---
> drivers/gpu/drm/i915/intel_dp.c | 46 ++++++++++++++++++++++++-----------------
> 1 file changed, 27 insertions(+), 19 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>index 153342c..796c2a2 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -4294,18 +4294,6 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> 	return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> }
> 
>-/*
>- * 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.
>- */
> int intel_dp_retrain_link(struct intel_encoder *encoder,
> 			  struct drm_modeset_acquire_ctx *ctx)
> {
>@@ -4322,10 +4310,12 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
> 	if (!connector || connector->base.status != connector_status_connected)
> 		return 0;
> 
>-	ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
>-			       ctx);
>-	if (ret)
>-		return ret;
>+	if (ctx) {
>+		ret = drm_modeset_lock(
>+			&dev_priv->drm.mode_config.connection_mutex, ctx);
>+		if (ret)
>+			return ret;
>+	}
> 
> 	conn_state = connector->base.state;
> 
>@@ -4333,9 +4323,11 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
> 	if (!crtc)
> 		return 0;
> 
>-	ret = drm_modeset_lock(&crtc->base.mutex, ctx);
>-	if (ret)
>-		return ret;
>+	if (ctx) {
>+		ret = drm_modeset_lock(&crtc->base.mutex, ctx);
>+		if (ret)
>+			return ret;
>+	}
> 
> 	crtc_state = to_intel_crtc_state(crtc->base.state);
> 
>@@ -4854,6 +4846,22 @@ intel_dp_long_pulse(struct intel_connector *connector)
> 		 */
> 		status = connector_status_disconnected;
> 		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.
>+		 */
>+		struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>+
>+		intel_dp_retrain_link(encoder, NULL);
> 	}
> 
> 	/*
>-- 
>2.1.4
>

Actions: View | Splinter Review

Attachments on bug 107446: 140923 | 140924 | 140925 | 140956 | 140957 | 143121 | 143122

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.