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: 9966625 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 43C2D600C5 for ; Fri, 22 Sep 2017 16:46:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 319512994F for ; Fri, 22 Sep 2017 16:46:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 25A7D29954; Fri, 22 Sep 2017 16:46:07 +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 9CF7429955 for ; Fri, 22 Sep 2017 16:46:04 +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=Rc79msHwpmxJXPBN4nT0Ky8+lcuGqpc1z2zs1zXbhFY=; b=tSzULgBPogVB55jRs9V0t3M2Op MqZNF1JHeNCv5slypHwqDSl/y7/N45xZa33JcNWoN1xDwfvtd8gXjZUWEBl3nVy2gIloJGyy7ypY/ Pj7SHkcKxVEsEsf7g5VhfW/JNTB5EoqkwVSGtGp3526M4QWNQWNXPsXj3DZt1dsfRDeEwUob9MK+L QLTMJAV5jqOcKsN6p6ttNw360Ibx01A33BXRWiHG/bVGzB39N0oO3pFf+iCy6zaUZz0zLkLR96cmL thbyouZV67m64V6rZby3T131i+OGZUwlJSASIhex+79PlTolSGAuBrTEOc9RXucGvzsZEc/amZ+lz 0fzREWQA==; 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 1dvR5B-0006PG-L3; Fri, 22 Sep 2017 16:45:41 +0000 Received: from mail-pf0-x22f.google.com ([2607:f8b0:400e:c00::22f]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dvR4G-0004QW-KK for linux-rockchip@lists.infradead.org; Fri, 22 Sep 2017 16:45:03 +0000 Received: by mail-pf0-x22f.google.com with SMTP id g65so800019pfe.13 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=axgKB8uNO42P2Z7ne3DNz/TGYPozFowCRGL1BIp6Th1tANguoEB5lICM495PKuRvtb 9a7JoetRbUG8eTiQupvPhkdxwB8I58+PsXjCsMkkl1U09eE8a/cXdfSOSy3/wopEFFI3 k9DCMX2gO1UnNe9nVPmZzMqzH45+Y82/+10Oyz92FDh69cFesYpgWMjnjohlLagBcVl7 AS2XupR+oZza0idji0pndx+qmT3wQsCM0Ktx6CMOBibpgBJRkpe0hdk3gE0VG4q9gjzt PXv+1erBm8aak9rJoqm60oLE+q/NBv0fnQHkwW5NdOp9XHqBw/GnCxGTPnJHiL3m+rvz n9CQ== X-Gm-Message-State: AHPjjUhwvRPSNJtQQarpkgp1bOgYo2CQU5XlLlR/w82S1aBAOe9Xw+sz hTn+MNdRMhftP4FqDeGgoXEwpw== 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_091967_B84FCF14 X-CRM114-Status: GOOD ( 19.71 ) 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 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 */