Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4238657imm; Sat, 25 Aug 2018 12:13:04 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZzhQTHyB6kkPSVi/Vua/Qet6z1ChTjr3jl0vVmpXBJ9N0bZWkDhNmdXMSXVG1GTxu9lxIm X-Received: by 2002:a62:6283:: with SMTP id w125-v6mr7255170pfb.108.1535224384336; Sat, 25 Aug 2018 12:13:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535224384; cv=none; d=google.com; s=arc-20160816; b=tbBeU+8vFrqV9qGtyGi4XIqWXLQZwme61yrCeVXjE6oMJNEUatCMQtmjuB/jDmaEdP D1bG7MboGodudsFjvfFaVnQVrsdePKdSIUCizorWy8TKKH2nsSVkfgxx8555hugQ08Id gmxc20UyL13zQVsiZUG2MNWom1HPSjdpSlNir5HKjS8p8FVg8Vtvsc0Un2aNj1FCNiO2 oJpS377st5yE+SZhlD6HrXE5+7Y5uLgfZWLVNfwCnlr5KX+8+afOvXbZ8TiqBT+A2Zry ba+RDPhBh7C1+7YfeGcZKsgKefeVcclcgQLUcUhBqF53LI4FRMxUAINpetnS/wwhfnVs 8SCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=wJ9/vcjJl1scXax/IPh+K5vQl0mqJgl9tQAmGSUVi/8=; b=MIiMUae0Julgupuft8Py6Dq8otEIGg7Y0V1/oTeWyG/6ACiknKdmwS4NldidvsCpdg G6GIU+9TTS+5GUAeFF6M27NekMP7tHLA1il1agybbjm2Iw+mugHozekoS7x5RK2OgDBR uxwgFu0Q4UgUxiGAWqCfOzW6NluuwuSfTry36zUFWJdFtgZb1KBGyBcUVHZOXJQAz+kR FYhDO2tdUZyN8FeDle6pA1HPtpXeLoWbzlh0zJS5OhquElZ/0Oas1haRGnsS/JaQaXhI V2gakbdNkheF2pgmJhSU1nHluO+cBB15yKX1H8b2U/TWCats9HWnssU28PwUBKBQI1rF PcGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n4-v6si10113926pgi.69.2018.08.25.12.12.36; Sat, 25 Aug 2018 12:13:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727000AbeHYWuh (ORCPT + 99 others); Sat, 25 Aug 2018 18:50:37 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:51704 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726751AbeHYWuh (ORCPT ); Sat, 25 Aug 2018 18:50:37 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3154ADBDA; Sat, 25 Aug 2018 19:10:45 +0000 (UTC) Received: from malachite.redhat.com (ovpn-120-49.rdu2.redhat.com [10.10.120.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id D130310F1BF9; Sat, 25 Aug 2018 19:10:40 +0000 (UTC) From: Lyude Paul To: intel-gfx@lists.freedesktop.org Cc: Jan-Marek Glogowski , stable@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH v4] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse" Date: Sat, 25 Aug 2018 15:10:35 -0400 Message-Id: <20180825191035.3945-1-lyude@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Sat, 25 Aug 2018 19:10:45 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Sat, 25 Aug 2018 19:10:45 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lyude@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jan-Marek Glogowski 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") Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by: Lyude Paul Signed-off-by: Jan-Marek Glogowski Cc: stable@vger.kernel.org --- Resending this to update patchwork; will push in a little bit drivers/gpu/drm/i915/intel_dp.c | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index b3f6f04c3c7d..db8515171270 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4333,18 +4333,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) { @@ -5031,7 +5019,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp) } static int -intel_dp_long_pulse(struct intel_connector *connector) +intel_dp_long_pulse(struct intel_connector *connector, + struct drm_modeset_acquire_ctx *ctx) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_dp *intel_dp = intel_attached_dp(&connector->base); @@ -5090,6 +5079,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, ctx); } /* @@ -5151,7 +5156,7 @@ intel_dp_detect(struct drm_connector *connector, return ret; } - status = intel_dp_long_pulse(intel_dp->attached_connector); + status = intel_dp_long_pulse(intel_dp->attached_connector, ctx); } intel_dp->detect_done = false; -- 2.17.1