From patchwork Tue Sep 19 19:56:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 9960105 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 B9548601E9 for ; Tue, 19 Sep 2017 19:58:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A9C36286E7 for ; Tue, 19 Sep 2017 19:58:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9EBFE28EDA; Tue, 19 Sep 2017 19:58:32 +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,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 467DD286E7 for ; Tue, 19 Sep 2017 19:58:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:References: In-Reply-To:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=CUZbhruDyawmHBmCqkkT+BNbc1jYnUOKkZfxuLPL5+w=; b=qWiGasHpZIiGQXnu3p5G8mU4zN FWKnxFEW1SB4STkJ0QozbqRBgLxIgblLkfN5pc3+UfZGM57yxCrlQNWJyxN1q9dGnOoicM5ACS/Kv HLeBviSZKYaE+z3PymyXUdkdHIsemPsXzlgQvOqW/ig2SLDdNWZZWnxGZxlzsRvW3E19pRvk/Gh35 DFsCgLPNgjtZSyvgVXd3Urx9Q8yedm6VKUBeGbv4v0s+dEV8g0xLsjTYFwYjN0n9S+8gIzQifBiYo CR0488AzOGWMRNZKXje5sIYDKmNmWSEmnltaLcxJgHIFKBYScXB1chLNUw5pczvWIn89+ap7NFubX 8DpC3YcQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1duOf8-0001Mj-1u; Tue, 19 Sep 2017 19:58:30 +0000 Received: from mail-pg0-x232.google.com ([2607:f8b0:400e:c05::232]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1duOdy-0000In-4n for linux-rockchip@lists.infradead.org; Tue, 19 Sep 2017 19:57:29 +0000 Received: by mail-pg0-x232.google.com with SMTP id 7so390237pgd.13 for ; Tue, 19 Sep 2017 12:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=7V/JU5jFp3sT0h4bUs031a539fINmhgO2W92yA7df/k=; b=kxpYk9s4l8Bjq80G1876dOJpYxox4mH1u6x2W+vkGTRvv1UbXxX6xX7Yf7EfY+ujJ9 wWFe18l9PhoLWAzjrJAelBg6CJXbfgqR7P0BmRfUM4dHVCgltun3h9w+DwJ4eN3p7YLk cz4Nb33Mm5mF2+V87M5+MIJ4xmMXOo0DjDmgI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=7V/JU5jFp3sT0h4bUs031a539fINmhgO2W92yA7df/k=; b=qQFfuIDZPn6ZGFTNFjvsrHC3hQFXHsZ8lhIPQ9cwPF8lAHWv8HEpkbgz48rQupQ0VA jvbxz6tUA3bwloIHL3OjOS7OxBt7w3RpA+O+wIyGcvPCYSghzulZRDflMrNPQJgNIpPO tKhcJf+POP8M7ZQcShnh2HmOigeqTjmE+p3qMGzIuZzW1QYA5pKO5748jfUfKevWmEkn LT/8VxMnNvx/zYgq3BlNC/Tju2IVdGCdQH1J2kGUOw3jHveGunxaWKk0T6y9HX+Dn2yq fI+O1rFW3Xsawb/oUiaWnLyfw1kf1D/8LJW+DA7BYFGxgZ92HlkC6LeALa04ZjTzHpVX P9XQ== X-Gm-Message-State: AHPjjUgkxuMLFsnoGsBE06tOyI5Na1fJqi5MViE3Db3xA9P4dTvSG/44 8Qfv7tn5ytpKkDLH/LM4H/4IUw== X-Google-Smtp-Source: AOwi7QDkMMGMd1NSUy3aYQ99G18deMDGwxrUV2vXz6incxWV51zDfEW+AB2irGdJZvwYV7qv6FICzg== X-Received: by 10.84.211.136 with SMTP id c8mr2332057pli.233.1505851017272; Tue, 19 Sep 2017 12:56:57 -0700 (PDT) Received: from tictac.mtv.corp.google.com ([172.22.112.154]) by smtp.gmail.com with ESMTPSA id k12sm7079131pgt.3.2017.09.19.12.56.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Sep 2017 12:56:56 -0700 (PDT) From: Douglas Anderson To: kishon@ti.com, heiko@sntech.de, zyw@rock-chips.com Subject: [PATCH v2 4/4] phy: rockchip-typec: Don't set the aux voltage swing to 400 mV Date: Tue, 19 Sep 2017 12:56:30 -0700 Message-Id: <20170919195630.18747-5-dianders@chromium.org> X-Mailer: git-send-email 2.14.1.690.gbb1197296e-goog In-Reply-To: <20170919195630.18747-1-dianders@chromium.org> References: <20170919195630.18747-1-dianders@chromium.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170919_125718_536525_3B0FA61C X-CRM114-Status: GOOD ( 20.65 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: shawnn@chromium.org, Douglas Anderson , dnschneid@chromium.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, groeck@chromium.org, linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On rk3399-gru-kevin there are some cases where we're seeing AUX CH failures when trying to do DisplayPort over type C. Problems are intermittent and don't reproduce all the time. Problems are often bursty and failures persist for several seconds before going away. The failure case I focused on is: * A particular type C to HDMI adapter. * One orientation (flip mode) of that adapter. * Easier to see failures when something is plugged into the _other type C port at the same time. * Problems reproduce on both type C ports (left and right side). Ironically problems also stop reproducing when I solder wires onto the AUX CH signals on a port (even if no scope is connected to the signals). In this case, problems only stop reproducing on the port with the wires connected. From the above it appears that something about the signaling on the aux channel is marginal and any slight differences can bring us over the edge to failure. It turns out that we can fix our problems by just increasing the voltage swing of the AUX CH, giving us a bunch of extra margin. In DP up to version 1.2 the voltage swing on the aux channel was specced as .29 V to 1.38 V. In DP version 1.3 the aux channel voltage was tightened to be between .29 V and .40 V, but it clarifies that it really only needs the lower voltage when operating at the highest speed (HBR3 mode). So right now we are trying to use a voltage that technically should be valid for all versions of the spec (including version 1.3 when transmitting at HBR3). That would be great to do if it worked reliably. ...but it doesn't seem to. It turns out that if you continue to read through the DP part of the rk3399 TRM and other parts of the type C PHY spec you'll find out that while the rk3399 does support DP 1.3, it doesn't support HBR3. The docs specifically say "RBR, HBR and HBR2 data rates only". Thus there is actually no requirement to support an AUX CH swing of .4 V. Even if there is no actual requirement to support the tighter voltage swing, one could possibly argue that we should support it anyway. The DP spec clarifies that the lower voltage on the AUX CH will reduce cross talk in some cases and that seems like it could be beneficial even at the lower bit rates. At the moment, though, we are seeing problems with the AUX CH and not on the other lines. Also, checking another known working and similar laptop shows that the other laptop runs the AUX channel at a higher voltage. Other notes: * Looking at measurements done on the AUX CH we weren't actually compliant with the DP 1.3 spec anyway. AUX CH peek-to-peek voltage was measured on rk3399-gru-kevin as .466 V which is > .4 V. * With this new patch the AUX channel isn't actually 1.0 V, but it has been confirmed that the signal is better and has more margin. Eye diagram passes. * If someone were truly an expert in the Type C PHY and in DisplayPort signaling they might be able to make things work and keep the voltage at < .4 V. The Type C PHY seems to have a plethora of tuning knobs that could almost certainly improve the signal integrity. Some of these things (like enabling tx_fcm_full_margin) even seem to fix my problems. However, lacking expertise I can't say whether this is a better or worse solution. Tightening signals to give cleaner waveforms can often have adverse affects, like increasing EMI or adding noise to other signals. I'd rather not tune things like this without a healthy application of expertise that I don't have. Signed-off-by: Douglas Anderson --- Changes in v2: - Voltage swing patch new for v2. drivers/phy/rockchip/phy-rockchip-typec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c index a1f961844efe..a96635447d48 100644 --- a/drivers/phy/rockchip/phy-rockchip-typec.c +++ b/drivers/phy/rockchip/phy-rockchip-typec.c @@ -669,8 +669,8 @@ static void tcphy_dp_aux_calibration(struct rockchip_typec_phy *tcphy) */ writel(0, tcphy->base + TX_ANA_CTRL_REG_4); - /* Set voltage swing to 400 mV peak to peak (differential) */ - writel(LOW_POWER_SWING_EN, tcphy->base + TXDA_COEFF_CALC_CTRL); + /* Don't set voltage swing to 400 mV peak to peak (differential) */ + writel(0, tcphy->base + TXDA_COEFF_CALC_CTRL); /* Init TXDA_CYA_AUXDA_CYA for unknown magic reasons */ writel(0, tcphy->base + TXDA_CYA_AUXDA_CYA);