Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1778354imm; Thu, 27 Sep 2018 02:18:45 -0700 (PDT) X-Google-Smtp-Source: ACcGV60/QeJ7NdbQIvUispjAwLkS0ROyViGJ+17GgSgbVU4M3Ov0XD2ZycOM1P1ps65ZFmF5tAgE X-Received: by 2002:a17:902:8eca:: with SMTP id x10-v6mr10148068plo.336.1538039925322; Thu, 27 Sep 2018 02:18:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538039925; cv=none; d=google.com; s=arc-20160816; b=FazuVr4pGqcTiA/HH8l5Bb7q4E+zUOEcMFqKO28BvTh5ooD8eW4HQq7gjysdTFRwUC gTz7D+fUwQPsEpoopTiq5MhI89GgGHEAH78XKj73r8WCYmNw4sfDPsjz7COCW4uIUuBW q3Kh26w8D15JlD89OX8B4eRdivwuqkIon2uuFCjuz/bLoqRjisYT03EbUqk1qGjipmsV SonSKxkXmC8AyQBXzCjz0KNErFpzEuIoL1aN5I8MvQdBAsTeFkiC30w2CwSQPmxtLvfz q6dD+fGOVbBapihlfZNBBQS5RIyuyzFgEmcrZPOptLZE7VsSJo2IPtQu35YNlWeElRxu BfWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from; bh=ntcn6fvlB7T15x++t9TouY3sy9Ap47s1JvOlWC1c73E=; b=ChMxzC7Ei2FXzW/scJFbwPRMWCL5BOWcawyVGw2PaSnerfGXmFqq/N0GFaMICgwLC9 WmU49IlePU6EeAKkOsjelRndjWvl5vt4CVlQNzdRVNIqyLUYkn5vUyDJGLv8ZEdXhC47 KRy/UdeMY9d9rth+fhaBQjl9DrpEjbyxGjEsmFkfdz8FlUB0bCg0E0uOKJ3ukcYgQ3W6 3ufED3zA5giTUi+d209Hfsh9oOmJzgGu0KFlBaz/3ZDpIGRGU/B6Ck+8bR3EqUvLE6im R7qGBGYGaG5O9D0+ofF2PtLHiF9sT/RUOaCF1CnNWuzoFh2e5247QkYbWZ807PgNvyZy jiBQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si1607144plq.390.2018.09.27.02.18.30; Thu, 27 Sep 2018 02:18:45 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728805AbeI0Pdj (ORCPT + 99 others); Thu, 27 Sep 2018 11:33:39 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:55874 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727522AbeI0Pdj (ORCPT ); Thu, 27 Sep 2018 11:33:39 -0400 Received: from localhost (ip-213-127-77-73.ip.prioritytelecom.net [213.127.77.73]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 63CD01117; Thu, 27 Sep 2018 09:16:21 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lyude Paul , Karol Herbst , Ben Skeggs Subject: [PATCH 4.18 62/88] drm/nouveau: Reset MST branching unit before enabling Date: Thu, 27 Sep 2018 11:03:43 +0200 Message-Id: <20180927090308.281386714@linuxfoundation.org> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20180927090300.631426620@linuxfoundation.org> References: <20180927090300.631426620@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lyude Paul commit fa3cdf8d0b092c4561f9f017dfac409eb7644737 upstream. When probing a new MST device, it's not safe to make any assumptions about it's current state. While most well mannered MST hubs will just disable the branching unit on hotplug disconnects, this isn't enough to save us from various other scenarios that might have resulted in something writing to the MST branching unit before we got control of it. This could happen if a previous probe we tried failed, if we're booting in kexec context and the hub is still in the state the last kernel put it in, etc. Luckily; there is no reason we can't just reset the branching unit every time we enable a new topology. So, fix this by resetting it on enabling new topologies to ensure that we always start off with a clean, unmodified topology state on MST sinks. This fixes occasional hard-lockups on my P50's laptop dock (e.g. AUX times out all DPCD trasactions) observed after multiple docks, undocks, and module reloads. Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Cc: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -1098,17 +1098,21 @@ nv50_mstm_enable(struct nv50_mstm *mstm, int ret; if (dpcd >= 0x12) { - ret = drm_dp_dpcd_readb(mstm->mgr.aux, DP_MSTM_CTRL, &dpcd); + /* Even if we're enabling MST, start with disabling the + * branching unit to clear any sink-side MST topology state + * that wasn't set by us + */ + ret = drm_dp_dpcd_writeb(mstm->mgr.aux, DP_MSTM_CTRL, 0); if (ret < 0) return ret; - dpcd &= ~DP_MST_EN; - if (state) - dpcd |= DP_MST_EN; - - ret = drm_dp_dpcd_writeb(mstm->mgr.aux, DP_MSTM_CTRL, dpcd); - if (ret < 0) - return ret; + if (state) { + /* Now, start initializing */ + ret = drm_dp_dpcd_writeb(mstm->mgr.aux, DP_MSTM_CTRL, + DP_MST_EN); + if (ret < 0) + return ret; + } } return nvif_mthd(disp, 0, &args, sizeof(args));