From patchwork Fri Sep 22 16:44:04 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 9966631 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 EBDDD6057C for ; Fri, 22 Sep 2017 16:47:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DAE1E29958 for ; Fri, 22 Sep 2017 16:47:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CE1E42995D; Fri, 22 Sep 2017 16:47:15 +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 1381629950 for ; Fri, 22 Sep 2017 16:47:14 +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=RnHO3YLxB/1fDnTPlq6cyOe5j3/hJ5nSBy6STckamqA=; b=oVZ/1d8BwGCy5vJNA3HSdkbc1o TntZQk2qFDY8JHLCan9U0uiBjE1DzaOb1LZU9xSjJdZ0PTHPn9vJ6AplE67VdziY2Kdsgfh2GaXOY /amW1Baw0wJO0G2OQsbOHaSJPRWdm9Qu2kQOHM3BPGmv32tK6eH4C0JMdcmFjSnDbjmuLSehvLXoN aKx1Q6GelOaXcJPVzCUWjOfE9kOarh9XWFr0/jcu65IJXkc8eDfwsO8gAT20vMWjRw0+x4mKu2iuQ KFuFDgH43HmluoYTr8UeJg1IykIRiEbzKI9u0aLFr1aVXjuVs7iy2m+9/JaPWox9881ZGi4oV8Jsx ZiAQ5TBA==; 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 1dvR5l-0006m5-1J; Fri, 22 Sep 2017 16:46:17 +0000 Received: from mail-pf0-x231.google.com ([2607:f8b0:400e:c00::231]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dvR4G-0004QV-Jy for linux-arm-kernel@lists.infradead.org; Fri, 22 Sep 2017 16:45:07 +0000 Received: by mail-pf0-x231.google.com with SMTP id u12so810836pfl.4 for ; Fri, 22 Sep 2017 09:44:24 -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=R1YlLYM6lv+r2AVxySSFp6ypKQZQ/bqY1nFiXEVKOeQ=; b=YYDKwNH0pSFEtQxNCLHOIONWfLXgyYcfial6M85+NK3ZbS7ZsdJ4vSlcpS7mADQeAj uA6MbSDIfIb0Vp+MTHfg9H8S/tHTAdsJyEoCvbcq0+DUo+BL/XW42deHjp75LUu8zCc6 8W/ueJZUVyaknlTkl5/Hi/O00EPqaaBO2LYHM= 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=R1YlLYM6lv+r2AVxySSFp6ypKQZQ/bqY1nFiXEVKOeQ=; b=HDqwgGpoSvZd0zTjVJB5kZuDwjrStKlKi1H0AQtfgAOI0Megde3YOnkHpIOKRl4btI Oaj+Y3n22078c8L/6mDNftQWAiDLMEyisbD8ZnRyg2PJ1p+0oIKkkMYdHhUVSK15dKKU ADOyS+tKa50kXu4I/XjpqEeUYB9dX+OPO7VTSDBcxSI3IB9NcA008YmGGxJP82LHMC5O 2y0NOfOOitK0qtPslFfhYy+2kpv50jPymQ/Hq2G8Gb5c9iXRjfVVHUZ39VGAzJYYTDmm mads31gp5Pr69TKox2IxTxof9p5+7jcTiDlke8I5nMeX9AVPey/7AiZI1yhj3qMaAtaH mKyg== X-Gm-Message-State: AHPjjUh5/TEgnlr9IWKvilHM/yi1mhTkRRDxNXa9u/jCtXrkJvAl+5KI jhhjwGRmOcBuoqalgCOzlg3gyA== X-Google-Smtp-Source: AOwi7QD85PxDV6tFNc6orEPxb4wRzCOzcDcVFMX7pBkcKHgHF1j4iJ7y4PHK17YfqR2ShNOcTMMVIQ== X-Received: by 10.98.48.195 with SMTP id w186mr9887755pfw.213.1506098663629; Fri, 22 Sep 2017 09:44:23 -0700 (PDT) Received: from tictac.mtv.corp.google.com ([172.22.112.154]) by smtp.gmail.com with ESMTPSA id s189sm365021pgc.1.2017.09.22.09.44.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Sep 2017 09:44:22 -0700 (PDT) From: Douglas Anderson To: kishon@ti.com, heiko@sntech.de, zyw@rock-chips.com Subject: [PATCH v3 2/4] phy: rockchip-typec: Don't set the aux voltage swing to 400 mV Date: Fri, 22 Sep 2017 09:44:04 -0700 Message-Id: <20170922164406.27606-3-dianders@chromium.org> X-Mailer: git-send-email 2.14.1.821.g8fa685d3b7-goog In-Reply-To: <20170922164406.27606-1-dianders@chromium.org> References: <20170922164406.27606-1-dianders@chromium.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170922_094445_071391_674E3A1A X-CRM114-Status: GOOD ( 21.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: 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-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=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 v3: - Voltage swing patch now patch 2. Changes in v2: - Voltage swing patch new for v2. drivers/phy/rockchip/phy-rockchip-typec.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c index 342a77733207..b25c00432f9b 100644 --- a/drivers/phy/rockchip/phy-rockchip-typec.c +++ b/drivers/phy/rockchip/phy-rockchip-typec.c @@ -543,10 +543,11 @@ static void tcphy_dp_aux_calibration(struct rockchip_typec_phy *tcphy) writel(0, tcphy->base + TX_ANA_CTRL_REG_5); /* - * Controls low_power_swing_en, set the voltage swing of the driver - * to 400mv. The values below are peak to peak (differential) values. + * Controls low_power_swing_en, don't set the voltage swing of the + * driver to 400mv. The values below are peak to peak (differential) + * values. */ - writel(4, tcphy->base + TXDA_COEFF_CALC_CTRL); + writel(0, tcphy->base + TXDA_COEFF_CALC_CTRL); writel(0, tcphy->base + TXDA_CYA_AUXDA_CYA); /* Controls tx_high_z_tm_en */