From patchwork Mon Apr 2 21:21:41 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Lyude Paul X-Patchwork-Id: 10320401 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id F10D460116 for ; Mon, 2 Apr 2018 21:22:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DB9B2289F4 for ; Mon, 2 Apr 2018 21:22:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D06B128A9B; Mon, 2 Apr 2018 21:22:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 567B0289F4 for ; Mon, 2 Apr 2018 21:22:10 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 008EE6E35D; Mon, 2 Apr 2018 21:22:09 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by gabe.freedesktop.org (Postfix) with ESMTPS id C454F6E35D; Mon, 2 Apr 2018 21:22:07 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7E8F4406E8BD; Mon, 2 Apr 2018 21:21:56 +0000 (UTC) Received: from malachite.bss.redhat.com (dhcp-10-20-1-55.bss.redhat.com [10.20.1.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id 03787215CDAF; Mon, 2 Apr 2018 21:21:52 +0000 (UTC) From: Lyude Paul To: intel-gfx@lists.freedesktop.org Date: Mon, 2 Apr 2018 17:21:41 -0400 Message-Id: <20180402212142.19841-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 02 Apr 2018 21:22:06 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 02 Apr 2018 21:22:06 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lyude@redhat.com' RCPT:'' Subject: [Intel-gfx] [PATCH] i915/dp_mst: Keep AUX block running when disabling DPMS X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Rodrigo Vivi , Laura Abbott , Dhinakaran Pandiyan Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to continue handling aux transactions even when none of the sinks are turned on since it's possible for us to have a single atomic commit which results in disabling each downstream sink, followed by subsequently re-enabling each sink. If we don't do this, we'll end up stalling any pending ESI interrupts from the sink for up to 1ms. Unfortunately, dropping ESIs during this timespan makes it so that link fallback retraining for MST (which I will be submitting to the ML shortly) fails due to the channel EQ failure interrupts potentially getting dropped. Additionally, when performing a modeset that brings the hub status's link status from bad -> good having ESIs disabled for that long causes us to miss the hub's response to us trying to start link training as well. Since any sink with MST is going to support DisplayPort 1.2 anyway, save us the hassle of trying to wait until the sink comes back up and just never shut the aux block down. Signed-off-by: Lyude Paul Cc: Laura Abbott Cc: Dhinakaran Pandiyan Cc: Ville Syrjälä Cc: stable@vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_dp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 62f82c4298ac..0479c377981b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode) return; if (mode != DRM_MODE_DPMS_ON) { + unsigned char data = intel_dp->is_mst ? + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3; + if (downstream_hpd_needs_d0(intel_dp)) return; - ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, - DP_SET_POWER_D3); + ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, data); } else { struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);