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=-11.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 7DCC8C43381 for ; Tue, 12 Mar 2019 01:21:36 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4ABA4214AF for ; Tue, 12 Mar 2019 01:21:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="sbSmDQ/J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4ABA4214AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=kHBBC0TePkru8rkQ6Wgq7ZJFmH+v2UkLlLHZwY5pKls=; b=sbSmDQ/JpzZJf1P1c846sTqbx khGrhML7yU9GRNjGbbHsDX9Kze6B5BNLviCjZUCjuWnYApPWLzKMS9HdiZr8hBBKP9VTEIIbX1lUl vLyc0UiE6AYDhFIzMQOzjzlnmuJwWKr75j1T9sLHpEmrqTK82WEcuMK2/pfGlf1EE1Q6ddk6WXQaE VZStkbYKb1qvSGqNaiTXSHjvEy17zB7icoL7L2xaTouFLZC/mcGTw4XjTJfbAcpQZTWXwDoU9TeTo pO/03vDSiKwlI4vs235hRKwEUi1Qt7P+VrkyFI47w00+0a1RTNZMhYTGljIStHxcvUHfLZ+A9DKjp szrByT/zA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h3W6h-000463-MS; Tue, 12 Mar 2019 01:21:27 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h3W6e-00045g-9D; Tue, 12 Mar 2019 01:21:25 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 22BAA374; Mon, 11 Mar 2019 18:21:23 -0700 (PDT) Received: from [192.168.1.123] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D60403F575; Mon, 11 Mar 2019 18:21:21 -0700 (PDT) Subject: Re: [PATCH] arm64: dts: rockchip: Fix rk3328 rgmii high tx error rate To: Peter Geis , Heiko Stuebner References: <20190309182013.22162-1-pgwipeout@gmail.com> From: Robin Murphy Message-ID: Date: Tue, 12 Mar 2019 01:21:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190309182013.22162-1-pgwipeout@gmail.com> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190311_182124_335200_CB459586 X-CRM114-Status: GOOD ( 21.82 ) 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: Mark Rutland , linux-rockchip@lists.infradead.org, Rob Herring , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2019-03-09 6:20 pm, Peter Geis wrote: > Several rk3328 based boards experience high rgmii tx error rates. > This is due to several pins in the rk3328.dtsi rgmii pinmux that are > missing a pull level setting. > This causes the pinmux driver to default to 0ma. Hmm, according to the TRM, there is no 0ma setting; only 2, 4, 8, or 12... > Fix this by setting those pins to 12ma, consistent with the other tx pins. > This allows much higher data rates with much fewer retries and no recorded > tx errors. > > Tested on the rk3328-roc-cc board. > > Signed-off-by: Peter Geis > --- > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi > index 84f14b132e8f..48a4477ebe58 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi > @@ -1673,19 +1673,19 @@ > <1 RK_PC1 2 &pcfg_pull_none_12ma>, > > /* mac_txclk */ > - <0 RK_PB0 1 &pcfg_pull_none>, > + <0 RK_PB0 1 &pcfg_pull_none_12ma>, > /* mac_txen */ > - <0 RK_PB4 1 &pcfg_pull_none>, > + <0 RK_PB4 1 &pcfg_pull_none_12ma>, > /* mac_clk */ > - <0 RK_PD0 1 &pcfg_pull_none>, > + <0 RK_PD0 1 &pcfg_pull_none_12ma>, > /* mac_txd1 */ > - <0 RK_PC0 1 &pcfg_pull_none>, > + <0 RK_PC0 1 &pcfg_pull_none_12ma>, > /* mac_txd0 */ > - <0 RK_PC1 1 &pcfg_pull_none>, > + <0 RK_PC1 1 &pcfg_pull_none_12ma>, > /* mac_txd3 */ > - <0 RK_PC7 1 &pcfg_pull_none>, > + <0 RK_PC7 1 &pcfg_pull_none_12ma>, > /* mac_txd2 */ > - <0 RK_PC6 1 &pcfg_pull_none>; > + <0 RK_PC6 1 &pcfg_pull_none_12ma>; ...but weirder than that, according to the datasheet none of these are actual pins anyway - those are the GPIO1B/C/D entries listed above this set - so it's not really clear what might be going on here, but it doesn't seem as straightforward as the commit message implies. The TRM lists the entire IOMUX registers for GPIO0B and GPOIO0C as reserved, and doesn't even list drive strength registers corresponding to these banks at all. What's interesting is that Rockchip's 4.4 BSP kernel implies that these pins might have actually existed at some point during the chip's development[1], and digging right back into the 3.10 BSP suggests there is some non-obvious interaction between the two configs[2][3]. So I guess there's a question of whether this patch is really doing what we think it's doing, and whether what it does do is truly appropriate to apply as the SoC-level default. Robin. [1] https://github.com/rockchip-linux/kernel/commit/8aceffc885c7d4f3f35d09d56d22ba47e64aad5b [2] https://github.com/rockchip-linux/kernel/commit/727de6da39ee62bb5b1252141a53ed027d5609f8 [3] https://github.com/rockchip-linux/kernel/commit/8e6b7f85dd5b451e57f220922a0ca1caecd71a94 > }; > > rmiim1_pins: rmiim1-pins { > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel