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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id CA5BCE7717F for ; Tue, 10 Dec 2024 13:45:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HR985HiE65wAXM9O8QvXvTA1gJ8FNQIGOl/hU7K0iww=; b=LC31rMkHBZMHTDa7HgXloCGhxG odCdEB/nXuRKFJaHASDke8RSP4hgit75NG+mg3VhWAvPG3fe83LOaF9QmfguKNhf+/jT4Pr06Fk7c mMC+4iFT7ufnrSSC/+Lhn5IiEpSd042NuQJoGLdxLqw1IQetWSL9M3qLYaU8dfnSFmtmfxdipsAAF g0HAolWwcshJIV+SO/gkOCYwv1xVZm7eRrbY4TXDOyILjfScbCf6k0CeW+8tCwmn3+v1mm+FBVs/U NLmrB97QnQdtIZxiwp2UMrb/vZNQXwFL17sY3Tcw9vczyVbx0kfU4WFMUfhaT/RZseoW09T0tgbcS dCLygcBg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tL0YF-0000000BcIx-18dO; Tue, 10 Dec 2024 13:45:23 +0000 Received: from mail.manjaro.org ([116.203.91.91]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tL0XB-0000000BcAB-3rja; Tue, 10 Dec 2024 13:44:19 +0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1733838255; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HR985HiE65wAXM9O8QvXvTA1gJ8FNQIGOl/hU7K0iww=; b=XFWjja7yGGHwKBg/bK2+h1h7SVh2fqrDrWxnE+tVJmxaRVJsqLZ3mtiwtJY3S2u7Z6nKni bROXKcLWiD3kioD0yKVuF2TCPoCBR9+cXomUeftaxuwCex6/Y/dgyuAi8TeqGax9dwu438 rG6imA1HJIVtI7w/34QtStg9qUmod9UIuXm0LRhyS4NB8lE3OdlYk5U0MhYBvn93AReZnI oZyJGqmJuQ6eEHbVQ/hplsYZz3OWa6Zt/GoaYA/ImRmI2sNDZIsjGjPoaS4ds1gu56WQTz nsERVgGNpU2+SLEOWl468F+JYzPjJzuBxgZ1P/ycA6PDNX/FRoUqg+d9tJ+cqw== Date: Tue, 10 Dec 2024 14:44:14 +0100 From: Dragan Simic To: Peter Geis Cc: Heiko Stuebner , Conor Dooley , Diederik de Haas , Johan Jonker , Krzysztof Kozlowski , Rob Herring , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org Subject: Re: [PATCH 6/6] arm64: dts: rockchip: Remove address aligned beats from rk3328-roc In-Reply-To: References: <20241210013010.81257-1-pgwipeout@gmail.com> <20241210013010.81257-7-pgwipeout@gmail.com> <2b68c2dd3618e5904a4eac1ec87d29a7@manjaro.org> Message-ID: <6453e714b2a48572ff1e57cd74b0f6d3@manjaro.org> X-Sender: dsimic@manjaro.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=dsimic@manjaro.org smtp.mailfrom=dsimic@manjaro.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241210_054418_252540_A837D3C1 X-CRM114-Status: GOOD ( 29.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Peter, On 2024-12-10 12:29, Peter Geis wrote: > On Tue, Dec 10, 2024 at 5:45 AM Dragan Simic > wrote: >> Thanks for the patch. Please, see some comments below. >> >> On 2024-12-10 02:30, Peter Geis wrote: >> > Since commit 8a469ee35606 ("arm64: dts: rockchip: Add txpbl node for >> > RK3399/RK3328"), the snps,aal, snps,txpbl, and snps,rxpbl nodes have >> > been unnecessary in the separate device trees. There is also a >> > performance loss to using snps,aal. Remove these from the rk3328-roc >> > device tree. >> > >> > Signed-off-by: Peter Geis >> > >> > --- >> > >> > arch/arm64/boot/dts/rockchip/rk3328-roc.dtsi | 3 --- >> > 1 file changed, 3 deletions(-) >> > >> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc.dtsi >> > b/arch/arm64/boot/dts/rockchip/rk3328-roc.dtsi >> > index 6984387ff8b3..0d476cc2144d 100644 >> > --- a/arch/arm64/boot/dts/rockchip/rk3328-roc.dtsi >> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-roc.dtsi >> > @@ -155,12 +155,9 @@ &gmac2io { >> > phy-mode = "rgmii"; >> > pinctrl-names = "default"; >> > pinctrl-0 = <&rgmiim1_pins>; >> > - snps,aal; >> >> Huh, I see that quite a few RK3328 board dts files specify >> the snps,aal node. I wonder was it a "cargo cult" approach >> at play, :) or was there some real need for it? >> >> Actually, I see now that you added snps,aal to rk3328-roc- >> cc.dts in the commit 393f3875c385 ("arm64: dts: rockchip: >> improve rk3328-roc-cc rgmii performance."), so I guess that >> your further research and testing showed that it actually >> isn't needed for Ethernet stability? >> >> > snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; >> > snps,reset-active-low; >> > snps,reset-delays-us = <0 10000 50000>; >> > - snps,rxpbl = <0x4>; >> > - snps,txpbl = <0x4>; >> >> Unless I'm missing something, the commit 8a469ee35606 ("arm64: >> dts: rockchip: Add txpbl node for RK3399/RK3328") doesn't add >> the snps,rxpbl node to the RK3328 SoC dtsi, and the respective >> driver does nothing about it when the snps,txpbl node is found. >> >> Though, I see that rk3328-rock-pi-e.dts is the only other >> RK3328 board dts file that specifies the snps,rxpbl node, so >> it seems that removing the snps,rxpbl node here should be safe, >> especially because it was you who added it in the same commit >> mentioned above. If there were some SoC-level issues, all >> RK3328 boards would've needed it. > > Good Morning, > > You'll notice the author of that patch was me. Setting aal, txpbl, and > rxpbl was the original fix I came up with for the rk3328, which I > applied to the only board I had. Someone else later on isolated it > specifically isolated it to just the txpbl and applied it to both the > rk3328 and rk3399 directly. > > This was just something that was left hanging after that result. > > Looking at how rk356x was done, I suspect there's an even more elegant > solution. However I don't have the deep level knowledge nor > documentation to implement it. Sure, I noticed that you authored the original Ethernet stability fix. :) With all this in mind, please feel free to include Reviewed-by: Dragan Simic and I'll prepare a patch or two that clean up any and all leftovers in other board dts(i) files.