From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F658C2BA83 for ; Fri, 14 Feb 2020 17:13:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 22481206CC for ; Fri, 14 Feb 2020 17:13:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581700408; bh=LOx3G48+qeXW1DcwfmUwMyuzLK0jenhTWOn+vwiGn6s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=k6bn9VrBjZq18H/ZcnbooyRVaMkdH2Eu5kp4FPEZsVvJeDnmDhfg/kyQ0NNcSQ1Zs Ewk4p0hivZ/nnR9vqoOT0cDggIqUOZni0WR4Rv780S+cglKMxyE3MZon2TtoV3WLIn SjIzcPgTk6AjJlFJD1fCOBZrthBTxdIWn1i6Rjf8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390063AbgBNRN1 (ORCPT ); Fri, 14 Feb 2020 12:13:27 -0500 Received: from mail.kernel.org ([198.145.29.99]:40658 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392074AbgBNQMv (ORCPT ); Fri, 14 Feb 2020 11:12:51 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DE6BF246AD; Fri, 14 Feb 2020 16:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581696771; bh=LOx3G48+qeXW1DcwfmUwMyuzLK0jenhTWOn+vwiGn6s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OIgGQXouL24ll5AUew/Ttwf9FD6PNTzp/oOAeV6d32mTExZgDs0IXs1TnpVBjo36f wOeI3Yqit6UBSXtOddPqN9ivWGFjE0mOjcCJcHlrq/9bFzHhV644EiKv7LP4FABbCW DLepagD8i5L2j20AAV/Cepik3RZ2H+6iCBZF4fuI= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harry Wentland , Louis Li , Wenjing Liu , Hersen Wu , Eric Yang , Alex Deucher , Sasha Levin , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: [PATCH AUTOSEL 4.19 049/252] drm/amd/display: Retrain dongles when SINK_COUNT becomes non-zero Date: Fri, 14 Feb 2020 11:08:24 -0500 Message-Id: <20200214161147.15842-49-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200214161147.15842-1-sashal@kernel.org> References: <20200214161147.15842-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Harry Wentland [ Upstream commit 3eb6d7aca53d81ce888624f09cd44dc0302161e8 ] [WHY] Two years ago the patch referenced by the Fixes tag stopped running dp_verify_link_cap_with_retries during DP detection when the reason for the detection was a short-pulse interrupt. This effectively meant that we were no longer doing the verify_link_cap training on active dongles when their SINK_COUNT changed from 0 to 1. A year ago this was partly remedied with: commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle") This made sure that we trained the dongle on initial hotplug (without connected downstream devices). This is all fine and dandy if it weren't for the fact that there are some dongles on the market that don't like link training when SINK_COUNT is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately after hotplug, even when a downstream device is connected, and then trigger a shortpulse interrupt indicating a SINK_COUNT change to 1. In order to play nicely we will need our policy to not link train an active DP dongle when SINK_COUNT is 0 but ensure we train it when the SINK_COUNT changes to 1. [HOW] Call dp_verify_link_cap_with_retries on detection even when the detection is triggered from a short pulse interrupt. With this change we can also revert this commit which we'll do in a separate follow-up change: commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle") Fixes: 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure") Suggested-by: Louis Li Tested-by: Louis Li Cc: Wenjing Liu Cc: Hersen Wu Cc: Eric Yang Reviewed-by: Wenjing Liu Signed-off-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 2f42964fb9f45..3abc0294c05f5 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -780,8 +780,7 @@ bool dc_link_detect(struct dc_link *link, enum dc_detect_reason reason) same_edid = is_same_edid(&prev_sink->dc_edid, &sink->dc_edid); if (link->connector_signal == SIGNAL_TYPE_DISPLAY_PORT && - sink_caps.transaction_type == DDC_TRANSACTION_TYPE_I2C_OVER_AUX && - reason != DETECT_REASON_HPDRX) { + sink_caps.transaction_type == DDC_TRANSACTION_TYPE_I2C_OVER_AUX) { /* * TODO debug why Dell 2413 doesn't like * two link trainings -- 2.20.1