[net-next,v2,5/7] net: dsa: mt7530: simplify mt7530_setup_port6() and change to void
Message ID | 20240130-for-netnext-mt7530-improvements-2-v2-5-ba06f5dd9eb0@arinc9.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-44828-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp1297373dyb; Tue, 30 Jan 2024 07:25:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IH6SRR8LjP7AMw83Xau0ag4eQ6qK3aG99NcJCXaWvgvy6zSf68TSiRh14SFzAIreHFHPM+4 X-Received: by 2002:a05:6a00:9281:b0:6dd:e150:8bcf with SMTP id jw1-20020a056a00928100b006dde1508bcfmr8832985pfb.29.1706628340734; Tue, 30 Jan 2024 07:25:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706628340; cv=pass; d=google.com; s=arc-20160816; b=eNvoRt5VbB5maEOw8bpy3/z0DZD0sKx2Z1n9cQyqpJ2aZcVdePXAa/gLddKC2bsGC5 /N2rkir8dgX4DMBr4JXFd47Vhg714ymfY7zsi0n1d+kcljU68x2zUIdPmg8NPx/0T1u0 aEtPAbYCchHScgTjb2ahpgF/szlecQgGjSB40M2hbzbP/c8zlhtaVPjBGZgvAOVEw69o qArUC+vKKuPm45v7r4+e8MwtFSKBuI6oAZEkYoTOZf404OGNS/brrbw6ZG9gCt144gXj FV/KxjQ4txRGKXxlmvRvpmauwXCd3KFsgW1nUdfFQPWcM1+431kSrtOeCI6vUCgr4DDy Gv+A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=reply-to:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:subject:date:from:dkim-signature; bh=BBeUhAyB62iTu/Rko8n4eyZUYKGT2nq5odxGxg4lQ+Y=; fh=xNlE86XmqkSplYYMvvd74gD/RbF2aUqtHPBgVCVc3H8=; b=HTFTI1VCpBVaJyf4HcDgcsW1b5cVko+44c7INNhFQA6JAkcCW0aoFnA0N49nP3QSbt Ai3hsxcGRl5CT4NNRdVTYoeQWcYbktaiZmthcIuMual9p+TXMys/mZE+TXq+GWu0tsEa vOPdsyKlg1GUbag2pbTlXgkZpl5LzjLKnunqNvYUNMzrLMNPxLiNyNMaQ4t8Wm0xwdXu ezDuNLuX4tEZzIS9EA0zYf56uyk759Rw2L0zTEWfE0wvhspvTqIrZ/1O9SVOI3SqAYBb dg+nq/UXvKbxrphj0aHAtcGDw47KFjAM6p8A8Z3RuOqEk0vGa0fLdhDjRiQsxr76HskA 59Ug== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jlwQttUm; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-44828-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44828-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id c129-20020a633587000000b005cf8b7a0629si7498685pga.663.2024.01.30.07.25.40 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 07:25:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-44828-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jlwQttUm; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-44828-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44828-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 3ACE928CFEF for <ouuuleilei@gmail.com>; Tue, 30 Jan 2024 15:23:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E294012BEA8; Tue, 30 Jan 2024 15:21:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jlwQttUm" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29816823B2; Tue, 30 Jan 2024 15:20:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706628057; cv=none; b=YuLg/xqzHYXzszHny53orkFc44lsyb7MgSGA5CmpRNfrfbdL4dIjlsjat/cP9Pz5GWVMGa8RHr8D4UhaWQQdhB35uO9BS3M85b/g4Kr9XMuXx+0IU2RMkykOQPQiheAnfblyGn7LvMa6sTzNRjLFfkphMycFCg1iDA6UM8Mzz0w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706628057; c=relaxed/simple; bh=+lJa57P19Tq2sGpIYqkCxLj9WTIbGgFWWKjycsir2/w=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=UNdCVX5Xp2buD+1+pppO/B6ZCVImz6IY42VVSMWTWi9CLIsloJ+zINk9474SKF1GvTsDMFhO+IjAQWykJDi5mInNzdsM4Ttppl6vyEHMvKizXGQOT4rakqJ2TbzKoLhFxUxTqc67Fj4RX0BW8GHfXL6Zwbi/OZUS/DMb0THQhOY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jlwQttUm; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPS id CB732C32783; Tue, 30 Jan 2024 15:20:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706628056; bh=+lJa57P19Tq2sGpIYqkCxLj9WTIbGgFWWKjycsir2/w=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=jlwQttUmaFuqTRBFNcl1ZyyPZcHLx44hIDt1aLVuOsH81+upVNxLtCrOOkNvH6FXS L9QJoC2Xkys01H5OpMEf9idmH1GXDpJaVQ/QMDVinmw0PAwRFGJTM7r4mxyuZpva2r ltE1ULf11Ox53BRsNVBl58bnUnL1HC9X5RXKfXXFTi9K9HPUwpRrcJtEN6pE3eJ6ny 3BTvx+G0tkXpgJJ9RsK+6fnv8Jy8rvIYRzKSNxkUSPig8wmQh5qN4JIst1/D1g0uo9 DL7YznDdA3cuO7jLI8W4Z/WmCujOQjf05T+FKFUZ7YW/LTmPSE150X60MW83dEpQbD 5O36cyFTHfoHg== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB1A9C46CD2; Tue, 30 Jan 2024 15:20:56 +0000 (UTC) From: =?utf-8?b?QXLEsW7DpyDDnE5BTA==?= via B4 Relay <devnull+arinc.unal.arinc9.com@kernel.org> Date: Tue, 30 Jan 2024 18:20:51 +0300 Subject: [PATCH net-next v2 5/7] net: dsa: mt7530: simplify mt7530_setup_port6() and change to void Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20240130-for-netnext-mt7530-improvements-2-v2-5-ba06f5dd9eb0@arinc9.com> References: <20240130-for-netnext-mt7530-improvements-2-v2-0-ba06f5dd9eb0@arinc9.com> In-Reply-To: <20240130-for-netnext-mt7530-improvements-2-v2-0-ba06f5dd9eb0@arinc9.com> To: Daniel Golle <daniel@makrotopia.org>, DENG Qingfang <dqfext@gmail.com>, Sean Wang <sean.wang@mediatek.com>, Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Vladimir Oltean <olteanv@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Russell King <linux@armlinux.org.uk> Cc: mithat.guner@xeront.com, erkin.bozoglu@xeront.com, Bartel Eerdekens <bartel.eerdekens@constell8.be>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, =?utf-8?b?QXLEsW7DpyDDnE5BTA==?= <arinc.unal@arinc9.com> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=ed25519-sha256; t=1706628055; l=5539; i=arinc.unal@arinc9.com; s=arinc9-patatt; h=from:subject:message-id; bh=SoDdRySeB2VjNzEzmEpX6Ha3WH6UgllbLr7DNQh8kXA=; b=f7Hlk9ksPK2bYo8i2hs574JPrUjqxCCTbkdmuLbx4rvEFixJcsrcC1hOZeiahW/zAZM/+oFWD QCTHbk7ptDLB8nRYy91zKM2A7PHL9T27uE2gB3ibCLb6FfOWRTXc00w X-Developer-Key: i=arinc.unal@arinc9.com; a=ed25519; pk=VmvgMWwm73yVIrlyJYvGtnXkQJy9CvbaeEqPQO9Z4kA= X-Endpoint-Received: by B4 Relay for arinc.unal@arinc9.com/arinc9-patatt with auth_id=115 X-Original-From: =?utf-8?b?QXLEsW7DpyDDnE5BTA==?= <arinc.unal@arinc9.com> Reply-To: <arinc.unal@arinc9.com> X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789529518691884955 X-GMAIL-MSGID: 1789529518691884955 |
Series |
MT7530 DSA Subdriver Improvements Act II
|
|
Commit Message
Arınç ÜNAL via B4 Relay
Jan. 30, 2024, 3:20 p.m. UTC
From: Arınç ÜNAL <arinc.unal@arinc9.com> This code is from before this driver was converted to phylink API. Phylink deals with the unsupported interface cases before mt7530_setup_port6() is run. Therefore, the default case would never run. However, it must be defined nonetheless to handle all the remaining enumeration values, the phy-modes. Switch to if statement for RGMII and return which simplifies the code and saves an indent. Set P6_INTF_MODE, which is the the three least significant bits of the MT7530_P6ECR register, to 0 for RGMII even though it will already be 0 after reset. This is to keep supporting dynamic reconfiguration of the port in the case the interface changes from TRGMII to RGMII. The core operations for TRGMII does not interfere with RGMII so no need to undo them. Read XTAL after checking for RGMII as it's only needed for the TRGMII interface mode. Change mt7530_setup_port6() to void now that there're no error cases left. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> --- drivers/net/dsa/mt7530.c | 103 ++++++++++++++++++++--------------------------- 1 file changed, 43 insertions(+), 60 deletions(-)
Comments
On Tue, Jan 30, 2024 at 06:20:51PM +0300, Arınç ÜNAL via B4 Relay wrote: > From: Arınç ÜNAL <arinc.unal@arinc9.com> > > This code is from before this driver was converted to phylink API. Phylink > deals with the unsupported interface cases before mt7530_setup_port6() is > run. Therefore, the default case would never run. However, it must be > defined nonetheless to handle all the remaining enumeration values, the > phy-modes. > > Switch to if statement for RGMII and return which simplifies the code and > saves an indent. > > Set P6_INTF_MODE, which is the the three least significant bits of the > MT7530_P6ECR register, to 0 for RGMII even though it will already be 0 > after reset. This is to keep supporting dynamic reconfiguration of the port > in the case the interface changes from TRGMII to RGMII. The core operations > for TRGMII does not interfere with RGMII so no need to undo them. That last sentence doesn't parse English gramar. "operations": plural "does": singular Should probably be either "The core operation for TRGMII does not..." or "The core operations for TRGMII do not..." As you are mentioning it, I'm now curious if you consider to dynamically reconfiguring TRGIII<->RGMII on port 6 depending on whether there is more then 1 GBit/s possible bandwidth needed between port 6 and the remaining ports? That could make sense for power management, but then we should at least again switch off the TRGMII clocks in the RGMII case before returning, see my suggestion inline below. > > Read XTAL after checking for RGMII as it's only needed for the TRGMII > interface mode. > > Change mt7530_setup_port6() to void now that there're no error cases left. > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Daniel Golle <daniel@makrotopia.org> > --- > drivers/net/dsa/mt7530.c | 103 ++++++++++++++++++++--------------------------- > 1 file changed, 43 insertions(+), 60 deletions(-) > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c > index c4d492e29fdf..36dc2bbcf3b6 100644 > --- a/drivers/net/dsa/mt7530.c > +++ b/drivers/net/dsa/mt7530.c > @@ -414,70 +414,57 @@ mt753x_preferred_default_local_cpu_port(struct dsa_switch *ds) > } > > /* Setup port 6 interface mode and TRGMII TX circuit */ > -static int > +static void > mt7530_setup_port6(struct dsa_switch *ds, phy_interface_t interface) > { > struct mt7530_priv *priv = ds->priv; > - u32 ncpo1, ssc_delta, trgint, xtal; > - > - xtal = mt7530_read(priv, MT7530_MHWTRAP) & HWTRAP_XTAL_MASK; > + u32 ncpo1, ssc_delta, xtal; > > - switch (interface) { > - case PHY_INTERFACE_MODE_RGMII: > - trgint = 0; > - break; > - case PHY_INTERFACE_MODE_TRGMII: > - trgint = 1; > - if (xtal == HWTRAP_XTAL_25MHZ) > - ssc_delta = 0x57; > - else > - ssc_delta = 0x87; > - if (priv->id == ID_MT7621) { > - /* PLL frequency: 125MHz: 1.0GBit */ > - if (xtal == HWTRAP_XTAL_40MHZ) > - ncpo1 = 0x0640; > - if (xtal == HWTRAP_XTAL_25MHZ) > - ncpo1 = 0x0a00; > - } else { /* PLL frequency: 250MHz: 2.0Gbit */ > - if (xtal == HWTRAP_XTAL_40MHZ) > - ncpo1 = 0x0c80; > - if (xtal == HWTRAP_XTAL_25MHZ) > - ncpo1 = 0x1400; > - } > - break; > - default: > - dev_err(priv->dev, "xMII interface %d not supported\n", > - interface); > - return -EINVAL; > + if (interface == PHY_INTERFACE_MODE_RGMII) { > + mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, > + P6_INTF_MODE(0)); Maybe at least switch off TRGMIICK here because we are sure we don't need it in the RGMII case, ie: core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); And that then is another line of code already present just below which means you could keep variable trgint as it was and return after switching off TRGMIICK below anyway... > + return; > } > > - mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, > - P6_INTF_MODE(trgint)); > + mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, P6_INTF_MODE(1)); > > - if (trgint) { > - /* Disable the MT7530 TRGMII clocks */ > - core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); > + xtal = mt7530_read(priv, MT7530_MHWTRAP) & HWTRAP_XTAL_MASK; > > - /* Setup the MT7530 TRGMII Tx Clock */ > - core_write(priv, CORE_PLL_GROUP5, RG_LCDDS_PCW_NCPO1(ncpo1)); > - core_write(priv, CORE_PLL_GROUP6, RG_LCDDS_PCW_NCPO0(0)); > - core_write(priv, CORE_PLL_GROUP10, RG_LCDDS_SSC_DELTA(ssc_delta)); > - core_write(priv, CORE_PLL_GROUP11, RG_LCDDS_SSC_DELTA1(ssc_delta)); > - core_write(priv, CORE_PLL_GROUP4, > - RG_SYSPLL_DDSFBK_EN | RG_SYSPLL_BIAS_EN | > - RG_SYSPLL_BIAS_LPF_EN); > - core_write(priv, CORE_PLL_GROUP2, > - RG_SYSPLL_EN_NORMAL | RG_SYSPLL_VODEN | > - RG_SYSPLL_POSDIV(1)); > - core_write(priv, CORE_PLL_GROUP7, > - RG_LCDDS_PCW_NCPO_CHG | RG_LCCDS_C(3) | > - RG_LCDDS_PWDB | RG_LCDDS_ISO_EN); > + if (xtal == HWTRAP_XTAL_25MHZ) > + ssc_delta = 0x57; > + else > + ssc_delta = 0x87; > > - /* Enable the MT7530 TRGMII clocks */ > - core_set(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); > + if (priv->id == ID_MT7621) { > + /* PLL frequency: 125MHz: 1.0GBit */ > + if (xtal == HWTRAP_XTAL_40MHZ) > + ncpo1 = 0x0640; > + if (xtal == HWTRAP_XTAL_25MHZ) > + ncpo1 = 0x0a00; > + } else { /* PLL frequency: 250MHz: 2.0Gbit */ > + if (xtal == HWTRAP_XTAL_40MHZ) > + ncpo1 = 0x0c80; > + if (xtal == HWTRAP_XTAL_25MHZ) > + ncpo1 = 0x1400; > } > > - return 0; > + /* Disable the MT7530 TRGMII clocks */ > + core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); .. by moving this line up and letting it happen unconditionally for both RGMII and TRGMII (in case that works and doesn't break the RGMII case, but I assume it doesn't) > + > + /* Setup the MT7530 TRGMII Tx Clock */ > + core_write(priv, CORE_PLL_GROUP5, RG_LCDDS_PCW_NCPO1(ncpo1)); > + core_write(priv, CORE_PLL_GROUP6, RG_LCDDS_PCW_NCPO0(0)); > + core_write(priv, CORE_PLL_GROUP10, RG_LCDDS_SSC_DELTA(ssc_delta)); > + core_write(priv, CORE_PLL_GROUP11, RG_LCDDS_SSC_DELTA1(ssc_delta)); > + core_write(priv, CORE_PLL_GROUP4, RG_SYSPLL_DDSFBK_EN | > + RG_SYSPLL_BIAS_EN | RG_SYSPLL_BIAS_LPF_EN); > + core_write(priv, CORE_PLL_GROUP2, RG_SYSPLL_EN_NORMAL | > + RG_SYSPLL_VODEN | RG_SYSPLL_POSDIV(1)); > + core_write(priv, CORE_PLL_GROUP7, RG_LCDDS_PCW_NCPO_CHG | > + RG_LCCDS_C(3) | RG_LCDDS_PWDB | RG_LCDDS_ISO_EN); > + > + /* Enable the MT7530 TRGMII clocks */ > + core_set(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); > } > > static void > @@ -2609,15 +2596,11 @@ mt7530_mac_config(struct dsa_switch *ds, int port, unsigned int mode, > phy_interface_t interface) > { > struct mt7530_priv *priv = ds->priv; > - int ret; > > - if (port == 5) { > + if (port == 5) > mt7530_setup_port5(priv->ds, interface); > - } else if (port == 6) { > - ret = mt7530_setup_port6(priv->ds, interface); > - if (ret) > - return ret; > - } > + else if (port == 6) > + mt7530_setup_port6(priv->ds, interface); > > return 0; > } > > -- > 2.40.1 > >
On 30.01.2024 18:59, Daniel Golle wrote: > On Tue, Jan 30, 2024 at 06:20:51PM +0300, Arınç ÜNAL via B4 Relay wrote: >> From: Arınç ÜNAL <arinc.unal@arinc9.com> >> >> This code is from before this driver was converted to phylink API. Phylink >> deals with the unsupported interface cases before mt7530_setup_port6() is >> run. Therefore, the default case would never run. However, it must be >> defined nonetheless to handle all the remaining enumeration values, the >> phy-modes. >> >> Switch to if statement for RGMII and return which simplifies the code and >> saves an indent. >> >> Set P6_INTF_MODE, which is the the three least significant bits of the >> MT7530_P6ECR register, to 0 for RGMII even though it will already be 0 >> after reset. This is to keep supporting dynamic reconfiguration of the port >> in the case the interface changes from TRGMII to RGMII. The core operations >> for TRGMII does not interfere with RGMII so no need to undo them. > > That last sentence doesn't parse English gramar. > "operations": plural > "does": singular > > Should probably be either "The core operation for TRGMII does not..." > or "The core operations for TRGMII do not..." I'll use the latter, thanks. > > As you are mentioning it, I'm now curious if you consider to > dynamically reconfiguring TRGIII<->RGMII on port 6 depending on > whether there is more then 1 GBit/s possible bandwidth needed between > port 6 and the remaining ports? That could make sense for power > management, but then we should at least again switch off the TRGMII > clocks in the RGMII case before returning, see my suggestion inline > below. Turning off the TRGMII clocks for RGMII makes sense to me. But I don't see any cases where dynamic interface change between TRGMII and RGMII would ever occur. Speed too. No PHYs support TRGMII, only some MediaTek SoC MACs do. That means TRGMII would only be used in fixed links which there is no dynamic reconfiguration. My patch is about simplifying the code so I don't want to change the dynamic reconfiguration behaviour. That said, last year, I have very thoroughly tested this "turbo" RGMII interface between MT7530 standalone switch and MT7623NI SoC, which would supposedly achieve 2 Gbps TX & 2 Gbps RX. The performance was as if the link was regular RGMII. Unless the MediaTek SoC ethernet driver somehow caps TRGMII to 1 Gbps, I consider this whole TRGMII shenanigans a scam, to be extremely blunt. I'll give this a one last shot sometime before I push for the removal of TRGMII from Linux altogether and default to RGMII where it's used. Because of this, I don't want to spend too much time on this patch as it's potentially wasted effort. > >> >> Read XTAL after checking for RGMII as it's only needed for the TRGMII >> interface mode. >> >> Change mt7530_setup_port6() to void now that there're no error cases left. >> >> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> > > Reviewed-by: Daniel Golle <daniel@makrotopia.org> > >> --- >> drivers/net/dsa/mt7530.c | 103 ++++++++++++++++++++--------------------------- >> 1 file changed, 43 insertions(+), 60 deletions(-) >> >> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c >> index c4d492e29fdf..36dc2bbcf3b6 100644 >> --- a/drivers/net/dsa/mt7530.c >> +++ b/drivers/net/dsa/mt7530.c >> @@ -414,70 +414,57 @@ mt753x_preferred_default_local_cpu_port(struct dsa_switch *ds) >> } >> >> /* Setup port 6 interface mode and TRGMII TX circuit */ >> -static int >> +static void >> mt7530_setup_port6(struct dsa_switch *ds, phy_interface_t interface) >> { >> struct mt7530_priv *priv = ds->priv; >> - u32 ncpo1, ssc_delta, trgint, xtal; >> - >> - xtal = mt7530_read(priv, MT7530_MHWTRAP) & HWTRAP_XTAL_MASK; >> + u32 ncpo1, ssc_delta, xtal; >> >> - switch (interface) { >> - case PHY_INTERFACE_MODE_RGMII: >> - trgint = 0; >> - break; >> - case PHY_INTERFACE_MODE_TRGMII: >> - trgint = 1; >> - if (xtal == HWTRAP_XTAL_25MHZ) >> - ssc_delta = 0x57; >> - else >> - ssc_delta = 0x87; >> - if (priv->id == ID_MT7621) { >> - /* PLL frequency: 125MHz: 1.0GBit */ >> - if (xtal == HWTRAP_XTAL_40MHZ) >> - ncpo1 = 0x0640; >> - if (xtal == HWTRAP_XTAL_25MHZ) >> - ncpo1 = 0x0a00; >> - } else { /* PLL frequency: 250MHz: 2.0Gbit */ >> - if (xtal == HWTRAP_XTAL_40MHZ) >> - ncpo1 = 0x0c80; >> - if (xtal == HWTRAP_XTAL_25MHZ) >> - ncpo1 = 0x1400; >> - } >> - break; >> - default: >> - dev_err(priv->dev, "xMII interface %d not supported\n", >> - interface); >> - return -EINVAL; >> + if (interface == PHY_INTERFACE_MODE_RGMII) { >> + mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, >> + P6_INTF_MODE(0)); > > Maybe at least switch off TRGMIICK here because we are sure we don't need it > in the RGMII case, ie: > core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); > > And that then is another line of code already present just below which > means you could keep variable trgint as it was and return after > switching off TRGMIICK below anyway... > >> + return; >> } >> >> - mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, >> - P6_INTF_MODE(trgint)); >> + mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, P6_INTF_MODE(1)); >> >> - if (trgint) { >> - /* Disable the MT7530 TRGMII clocks */ >> - core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); >> + xtal = mt7530_read(priv, MT7530_MHWTRAP) & HWTRAP_XTAL_MASK; >> >> - /* Setup the MT7530 TRGMII Tx Clock */ >> - core_write(priv, CORE_PLL_GROUP5, RG_LCDDS_PCW_NCPO1(ncpo1)); >> - core_write(priv, CORE_PLL_GROUP6, RG_LCDDS_PCW_NCPO0(0)); >> - core_write(priv, CORE_PLL_GROUP10, RG_LCDDS_SSC_DELTA(ssc_delta)); >> - core_write(priv, CORE_PLL_GROUP11, RG_LCDDS_SSC_DELTA1(ssc_delta)); >> - core_write(priv, CORE_PLL_GROUP4, >> - RG_SYSPLL_DDSFBK_EN | RG_SYSPLL_BIAS_EN | >> - RG_SYSPLL_BIAS_LPF_EN); >> - core_write(priv, CORE_PLL_GROUP2, >> - RG_SYSPLL_EN_NORMAL | RG_SYSPLL_VODEN | >> - RG_SYSPLL_POSDIV(1)); >> - core_write(priv, CORE_PLL_GROUP7, >> - RG_LCDDS_PCW_NCPO_CHG | RG_LCCDS_C(3) | >> - RG_LCDDS_PWDB | RG_LCDDS_ISO_EN); >> + if (xtal == HWTRAP_XTAL_25MHZ) >> + ssc_delta = 0x57; >> + else >> + ssc_delta = 0x87; >> >> - /* Enable the MT7530 TRGMII clocks */ >> - core_set(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); >> + if (priv->id == ID_MT7621) { >> + /* PLL frequency: 125MHz: 1.0GBit */ >> + if (xtal == HWTRAP_XTAL_40MHZ) >> + ncpo1 = 0x0640; >> + if (xtal == HWTRAP_XTAL_25MHZ) >> + ncpo1 = 0x0a00; >> + } else { /* PLL frequency: 250MHz: 2.0Gbit */ >> + if (xtal == HWTRAP_XTAL_40MHZ) >> + ncpo1 = 0x0c80; >> + if (xtal == HWTRAP_XTAL_25MHZ) >> + ncpo1 = 0x1400; >> } >> >> - return 0; >> + /* Disable the MT7530 TRGMII clocks */ >> + core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); > > ... by moving this line up and letting it happen unconditionally for > both RGMII and TRGMII (in case that works and doesn't break the RGMII > case, but I assume it doesn't) I've just tested this, works fine. This looks simpler than bringing back the trgint variable. static void mt7530_setup_port6(struct dsa_switch *ds, phy_interface_t interface) { struct mt7530_priv *priv = ds->priv; u32 ncpo1, ssc_delta, xtal; /* Disable the MT7530 TRGMII clocks */ core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); if (interface == PHY_INTERFACE_MODE_RGMII) { mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, P6_INTF_MODE(0)); return; } mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, P6_INTF_MODE(1)); .. Arınç
On Tue, Jan 30, 2024 at 08:46:04PM +0300, Arınç ÜNAL wrote: > would supposedly achieve 2 Gbps TX & 2 Gbps RX Source? Commit 8efaa653a8a5 ("net: ethernet: mediatek: Add MT7621 TRGMII mode support") says "TRGMII speed is 1200MBit.". > Unless the MediaTek SoC ethernet driver somehow caps TRGMII to 1 Gbps, > I consider this whole TRGMII shenanigans a scam I laughed :) You have to see whether the CPU isn't in fact at 100% already, becoming a bottleneck before the interface speed does. Also, mtk_eth_soc.c has an interesting comment "TRGMII is not permitted on MT7621 if using DDR2" - not sure if applicable to your setup or not. I just got myself an ASUS RT-AX1800U (uses the mt7621_asus_rt-ax53u.dts device tree AFAICT) which I'll be setting up with OpenWrt in the weeks to come, and on which I might also be able to run some tests from time to time.
On 2.02.2024 02:57, Vladimir Oltean wrote: > On Tue, Jan 30, 2024 at 08:46:04PM +0300, Arınç ÜNAL wrote: >> would supposedly achieve 2 Gbps TX & 2 Gbps RX > > Source? Commit 8efaa653a8a5 ("net: ethernet: mediatek: Add MT7621 TRGMII > mode support") says "TRGMII speed is 1200MBit.". That is for MT7621. It's claimed that TRGMII on MT7621 can only handle that much. I already told you I'm doing the test on MT7623NI SoC. MT7623 is ARM and more powerful. On that one, the PLL frequency can be set all the way up to 362.5 MHz to provide 2900 Mbps (allegedly). You can check the repository that the commit above links to for more details: https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/591910e127cd9c811fe9e811ddb6c7278d8ed934/linux-mt/drivers/net/ethernet/raeth/Kconfig#L141 https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/591910e127cd9c811fe9e811ddb6c7278d8ed934/linux-mt/drivers/net/ethernet/raeth/raeth_config.h#L201 https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/591910e127cd9c811fe9e811ddb6c7278d8ed934/u-boot-mt/drivers/net/rt2880_eth.c#L2178 > >> Unless the MediaTek SoC ethernet driver somehow caps TRGMII to 1 Gbps, >> I consider this whole TRGMII shenanigans a scam > > I laughed :) > > You have to see whether the CPU isn't in fact at 100% already, becoming > a bottleneck before the interface speed does. I'm happy I'm entertaining you but you've got to give me a little credit. :) MT7621 won't even handle 1 Gbps RX & 1 Gbps TX. But if the IP traffic is offloaded to the packet processing engine (drivers/net/ethernet/mediatek/mtk_ppe_offload.c), there won't be any load on the CPU. table ip global { flowtable f { hook ingress priority 0 devices = { wan, lan1, lan2, lan3, lan4 } flags offload } chain forward { type filter hook forward priority 0 ip protocol { tcp, udp } flow offload @f } chain postrouting { type nat hook postrouting priority 0 oifname "wan" masquerade } } MT7623 can handle 1 Gbps RX & 1 Gbps without much CPU load. It performs the same with or without hardware flow offloading, unlike MT7621. The way I test this: I do the test on a single computer. I have two gigabit ports on my motherboard. I isolate a port by putting it on another network namespace to do the test. Client Network iperf client: 192.168.2.2/24 router: 192.168.2.1/24 Server Network router: 192.168.3.2/24 iperf server: 192.168.3.1/24 iperf Client ip a add 192.168.2.2/24 dev enp9s0 ip l set up enp9s0 ip route add 192.168.3.1 via 192.168.2.1 iperf3 -c 192.168.3.1 --bidir -t 20 iperf Server ip netns add iperfserver ip link set dev eno1 netns iperfserver ip netns exec iperfserver ip a add 192.168.3.1/24 dev eno1 ip netns exec iperfserver ip l set up eno1 ip netns exec iperfserver iperf3 -s I did say I've done thorough testing. > > Also, mtk_eth_soc.c has an interesting comment "TRGMII is not permitted > on MT7621 if using DDR2" - not sure if applicable to your setup or not. My device has DDR3 memory. Also, with a device tree defining trgmii on a link of MediaTek SoC MAC, that check should prevent the mtk_eth_soc driver from configuring the MAC if the device has DDR2 memory, no? > > I just got myself an ASUS RT-AX1800U (uses the mt7621_asus_rt-ax53u.dts > device tree AFAICT) which I'll be setting up with OpenWrt in the weeks > to come, and on which I might also be able to run some tests from time > to time. Doing tests on MT7621 will be useless without utilising the PPE. To use it, you can add these to /etc/config/firewall: config defaults ... option flow_offloading '1' option flow_offloading_hw '1' Or enable software flow offloading and hardware flow offloading options if using LuCI. When both options are enabled, hardware flow offloading will be used. Make sure to change the PLL frequency on the MT7530 side to 150 MHz. It operates at the standard RGMII frequency since commit 37c218d8021e ("net: dsa: mt7530: fix corrupt frames using trgmii on 40 MHz XTAL MT7621"). For 40MHz XTAL: 0x0640 x 0d1,2 = 0x0780 For 25MHz XTAL: 0x0a00 x 0d1,2 = 0x0c00 Arınç
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c index c4d492e29fdf..36dc2bbcf3b6 100644 --- a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c @@ -414,70 +414,57 @@ mt753x_preferred_default_local_cpu_port(struct dsa_switch *ds) } /* Setup port 6 interface mode and TRGMII TX circuit */ -static int +static void mt7530_setup_port6(struct dsa_switch *ds, phy_interface_t interface) { struct mt7530_priv *priv = ds->priv; - u32 ncpo1, ssc_delta, trgint, xtal; - - xtal = mt7530_read(priv, MT7530_MHWTRAP) & HWTRAP_XTAL_MASK; + u32 ncpo1, ssc_delta, xtal; - switch (interface) { - case PHY_INTERFACE_MODE_RGMII: - trgint = 0; - break; - case PHY_INTERFACE_MODE_TRGMII: - trgint = 1; - if (xtal == HWTRAP_XTAL_25MHZ) - ssc_delta = 0x57; - else - ssc_delta = 0x87; - if (priv->id == ID_MT7621) { - /* PLL frequency: 125MHz: 1.0GBit */ - if (xtal == HWTRAP_XTAL_40MHZ) - ncpo1 = 0x0640; - if (xtal == HWTRAP_XTAL_25MHZ) - ncpo1 = 0x0a00; - } else { /* PLL frequency: 250MHz: 2.0Gbit */ - if (xtal == HWTRAP_XTAL_40MHZ) - ncpo1 = 0x0c80; - if (xtal == HWTRAP_XTAL_25MHZ) - ncpo1 = 0x1400; - } - break; - default: - dev_err(priv->dev, "xMII interface %d not supported\n", - interface); - return -EINVAL; + if (interface == PHY_INTERFACE_MODE_RGMII) { + mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, + P6_INTF_MODE(0)); + return; } - mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, - P6_INTF_MODE(trgint)); + mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, P6_INTF_MODE(1)); - if (trgint) { - /* Disable the MT7530 TRGMII clocks */ - core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); + xtal = mt7530_read(priv, MT7530_MHWTRAP) & HWTRAP_XTAL_MASK; - /* Setup the MT7530 TRGMII Tx Clock */ - core_write(priv, CORE_PLL_GROUP5, RG_LCDDS_PCW_NCPO1(ncpo1)); - core_write(priv, CORE_PLL_GROUP6, RG_LCDDS_PCW_NCPO0(0)); - core_write(priv, CORE_PLL_GROUP10, RG_LCDDS_SSC_DELTA(ssc_delta)); - core_write(priv, CORE_PLL_GROUP11, RG_LCDDS_SSC_DELTA1(ssc_delta)); - core_write(priv, CORE_PLL_GROUP4, - RG_SYSPLL_DDSFBK_EN | RG_SYSPLL_BIAS_EN | - RG_SYSPLL_BIAS_LPF_EN); - core_write(priv, CORE_PLL_GROUP2, - RG_SYSPLL_EN_NORMAL | RG_SYSPLL_VODEN | - RG_SYSPLL_POSDIV(1)); - core_write(priv, CORE_PLL_GROUP7, - RG_LCDDS_PCW_NCPO_CHG | RG_LCCDS_C(3) | - RG_LCDDS_PWDB | RG_LCDDS_ISO_EN); + if (xtal == HWTRAP_XTAL_25MHZ) + ssc_delta = 0x57; + else + ssc_delta = 0x87; - /* Enable the MT7530 TRGMII clocks */ - core_set(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); + if (priv->id == ID_MT7621) { + /* PLL frequency: 125MHz: 1.0GBit */ + if (xtal == HWTRAP_XTAL_40MHZ) + ncpo1 = 0x0640; + if (xtal == HWTRAP_XTAL_25MHZ) + ncpo1 = 0x0a00; + } else { /* PLL frequency: 250MHz: 2.0Gbit */ + if (xtal == HWTRAP_XTAL_40MHZ) + ncpo1 = 0x0c80; + if (xtal == HWTRAP_XTAL_25MHZ) + ncpo1 = 0x1400; } - return 0; + /* Disable the MT7530 TRGMII clocks */ + core_clear(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); + + /* Setup the MT7530 TRGMII Tx Clock */ + core_write(priv, CORE_PLL_GROUP5, RG_LCDDS_PCW_NCPO1(ncpo1)); + core_write(priv, CORE_PLL_GROUP6, RG_LCDDS_PCW_NCPO0(0)); + core_write(priv, CORE_PLL_GROUP10, RG_LCDDS_SSC_DELTA(ssc_delta)); + core_write(priv, CORE_PLL_GROUP11, RG_LCDDS_SSC_DELTA1(ssc_delta)); + core_write(priv, CORE_PLL_GROUP4, RG_SYSPLL_DDSFBK_EN | + RG_SYSPLL_BIAS_EN | RG_SYSPLL_BIAS_LPF_EN); + core_write(priv, CORE_PLL_GROUP2, RG_SYSPLL_EN_NORMAL | + RG_SYSPLL_VODEN | RG_SYSPLL_POSDIV(1)); + core_write(priv, CORE_PLL_GROUP7, RG_LCDDS_PCW_NCPO_CHG | + RG_LCCDS_C(3) | RG_LCDDS_PWDB | RG_LCDDS_ISO_EN); + + /* Enable the MT7530 TRGMII clocks */ + core_set(priv, CORE_TRGMII_GSW_CLK_CG, REG_TRGMIICK_EN); } static void @@ -2609,15 +2596,11 @@ mt7530_mac_config(struct dsa_switch *ds, int port, unsigned int mode, phy_interface_t interface) { struct mt7530_priv *priv = ds->priv; - int ret; - if (port == 5) { + if (port == 5) mt7530_setup_port5(priv->ds, interface); - } else if (port == 6) { - ret = mt7530_setup_port6(priv->ds, interface); - if (ret) - return ret; - } + else if (port == 6) + mt7530_setup_port6(priv->ds, interface); return 0; }