Message ID | 20230116103926.276869-4-clement.leger@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1124466wrn; Mon, 16 Jan 2023 02:47:22 -0800 (PST) X-Google-Smtp-Source: AMrXdXtEe3NlwWiq0+tLgiA2GVjrbYh+CIFZ6HRWg3u7WXw3JGhbKaZGu8lAnr7Xq8xlC6NXXY7Q X-Received: by 2002:a17:902:d292:b0:189:b4d0:aee with SMTP id t18-20020a170902d29200b00189b4d00aeemr18635677plc.67.1673866042395; Mon, 16 Jan 2023 02:47:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673866042; cv=none; d=google.com; s=arc-20160816; b=ftYvFhk1djlNRiFxwyCLhmpYLdADKBJVFIzUJyGvuziaachQ401TzsRdbX9EKnsHZc sVeCXyLQP06XgPBfluEkmb3syASuxRkEQCcB3k9IfeVWQDao7qQrZgi6nWbVUyDJug7+ d3Ube8+j+PR44qL5zEXnx+6mwGlawb622Gn5/YJYgo0OQDfI87bJbz+thTs9bHriAoom 0JckG1rHL5Bd/52OffaJDToVBTY9hbklJu3lj2moIwn0jktwUE6ocg0fwqMas8LwvOz6 /CuI66xukJEzNhw8Qn7wZpQ7qBr9dQLy8FD1Zwwe6lso3Y1E0yCbgE2e0rFbFsb/UDOk 2cRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=otK04t6Fq+0COownezUclLPHt9Yq8LgEt2fdJEWCBeY=; b=t5Cq655/e6jM/oB7QA9UawdPZYWKz8dtnCbkmYr3LcL8qUFenEZmQ5U6ja0tXNk+XC UsdQd2WOj1YOz+kupByq0JzCx9IVEj1BHO15YZRwXB8MykI4HWO4tMHwlMc53VBHXVO9 63XBrdNDqci5FFMjIoNA16sM+0Cd+QjNBo/spT8n6sDQUHljhSLy93GNH/uSH1sL+vUh gpdDJqeAlAOpi3FzfxynTZlTs35J56i3uCJRRGrg/gY1fgLUAdozkXT7RLMu5xoiN/eW 9rq6QlKp6EXNHhZ0KTvE4xTOaphdW7jzydnc/V9SzWRtOgXzIUIRvcukVRtrYpkbvJcw SvRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=SgVpIa9+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r11-20020a170903410b00b001947e1a94d5si6386122pld.575.2023.01.16.02.47.10; Mon, 16 Jan 2023 02:47:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=SgVpIa9+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230446AbjAPKiK (ORCPT <rfc822;stefanalexe802@gmail.com> + 99 others); Mon, 16 Jan 2023 05:38:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230387AbjAPKhz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 16 Jan 2023 05:37:55 -0500 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::228]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B3031BAFD; Mon, 16 Jan 2023 02:37:35 -0800 (PST) Received: (Authenticated sender: clement.leger@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 2BAD51BF20D; Mon, 16 Jan 2023 10:37:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1673865454; 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=otK04t6Fq+0COownezUclLPHt9Yq8LgEt2fdJEWCBeY=; b=SgVpIa9+7N5kErKew4ZANdCP3OgDdChVG7HEXYslpXSzH7kvthC+fDHeFxhnov9U3/LWVX VjRKdfUkztdgeLWQV1qbhW2EjzVSlFpO8oSVajOsieEF5LJzu54hu5F81H9DiiyJF7NXv0 wusfQa+cj2Gy/i3aL23RJ+Zv0wh4sjwGsaBGQec3wlbJNGwMlq8kPckzFNJi2DRSbVixKU LzcPKzCgm5A74SLyL/SVLgE5+cDHuffnhAYISWss/MI41KnD23sfO3JYTXtgxzKCk+YoIG Z1EEoADo6NCN6Ok1TK6/zLEBuVeLaGIXzAJkzXKCE6IYT0o35UVIu/nQVDb6UQ== From: =?utf-8?b?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com> To: Sergey Shtylyov <s.shtylyov@omp.ru>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Geert Uytterhoeven <geert+renesas@glider.be>, Magnus Damm <magnus.damm@gmail.com>, Giuseppe Cavallaro <peppe.cavallaro@st.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Russell King <linux@armlinux.org.uk>, Wong Vee Khee <veekhee@apple.com>, =?utf-8?b?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>, Kurt Kanzenbach <kurt@linutronix.de>, Revanth Kumar Uppala <ruppala@nvidia.com>, Tan Tee Min <tee.min.tan@linux.intel.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>, Herve Codina <herve.codina@bootlin.com>, =?utf-8?q?Miqu=C3=A8l_Raynal?= <miquel.raynal@bootlin.com>, Milan Stevanovic <milan.stevanovic@se.com>, Jimmy Lalande <jimmy.lalande@se.com>, Pascal Eberhard <pascal.eberhard@se.com>, Mohammad Athari Bin Ismail <mohammad.athari.ismail@intel.com>, Jon Hunter <jonathanh@nvidia.com>, netdev@vger.kernel.org, linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Subject: [PATCH net-next 3/6] net: stmmac: start phylink before setting up hardware Date: Mon, 16 Jan 2023 11:39:23 +0100 Message-Id: <20230116103926.276869-4-clement.leger@bootlin.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230116103926.276869-1-clement.leger@bootlin.com> References: <20230116103926.276869-1-clement.leger@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755175759585008876?= X-GMAIL-MSGID: =?utf-8?q?1755175759585008876?= |
Series |
net: stmmac: add renesas,rzn1-gmac support
|
|
Commit Message
Clément Léger
Jan. 16, 2023, 10:39 a.m. UTC
The stmmac on the Renesas RZ/N1 platform is connected to the PCS which
must be configured to provide a correct RGMII RX clock to the stmmac IP.
Without the RX clock, the driver will fail to initialize the hardware
(more specifically, the driver will report it fails to reset DMA). In
order to fix that, start phylink mecanism before setting up hardware.
Signed-off-by: Clément Léger <clement.leger@bootlin.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Comments
On Mon, Jan 16, 2023 at 11:39:23AM +0100, Clément Léger wrote: > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index f2247b8cf0a3..88c941003855 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -3818,6 +3818,12 @@ static int __stmmac_open(struct net_device *dev, > } > } > > + /* We need to setup the phy & PCS before accessing the stmmac registers > + * because in some cases (RZ/N1), if the stmmac IP is not clocked by the > + * PCS, hardware init will fail because it lacks a RGMII RX clock. > + */ > + phylink_start(priv->phylink); So what happens if you end up with the mac_link_up method being called at this point in the driver, before the hardware has been setup ? If you use a fixed-link, that's a real possibility.
Le Mon, 16 Jan 2023 10:53:49 +0000, "Russell King (Oracle)" <linux@armlinux.org.uk> a écrit : > On Mon, Jan 16, 2023 at 11:39:23AM +0100, Clément Léger wrote: > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > index f2247b8cf0a3..88c941003855 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > @@ -3818,6 +3818,12 @@ static int __stmmac_open(struct net_device *dev, > > } > > } > > > > + /* We need to setup the phy & PCS before accessing the stmmac registers > > + * because in some cases (RZ/N1), if the stmmac IP is not clocked by the > > + * PCS, hardware init will fail because it lacks a RGMII RX clock. > > + */ > > + phylink_start(priv->phylink); > > So what happens if you end up with the mac_link_up method being called > at this point in the driver, before the hardware has been setup ? > > If you use a fixed-link, that's a real possibility. I actually have this setup. On the board, one GMAC is connected to a DSA switch using a fixed-link and the other using the PCS such as added by this series. From what I see, indeed, the mac_link_up() function is called before stmmac_hw_setup(). This does not seems to have any effect on my setup (except making it working of course) but I agree this is clearly not ideal. What I could do is adding a function in the miic pcs driver that could be called from my rzn1 stmmac probe function to actually configure the PCS at probe time based on the detected "phy-mode". Does that seems better to you ? Thanks,
On Tue, Feb 07, 2023 at 03:41:35PM +0100, Clément Léger wrote: > Le Mon, 16 Jan 2023 10:53:49 +0000, > "Russell King (Oracle)" <linux@armlinux.org.uk> a écrit : > > > On Mon, Jan 16, 2023 at 11:39:23AM +0100, Clément Léger wrote: > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > index f2247b8cf0a3..88c941003855 100644 > > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > @@ -3818,6 +3818,12 @@ static int __stmmac_open(struct net_device *dev, > > > } > > > } > > > > > > + /* We need to setup the phy & PCS before accessing the stmmac registers > > > + * because in some cases (RZ/N1), if the stmmac IP is not clocked by the > > > + * PCS, hardware init will fail because it lacks a RGMII RX clock. > > > + */ > > > + phylink_start(priv->phylink); > > > > So what happens if you end up with the mac_link_up method being called > > at this point in the driver, before the hardware has been setup ? > > > > If you use a fixed-link, that's a real possibility. > > I actually have this setup. On the board, one GMAC is connected to a > DSA switch using a fixed-link and the other using the PCS such as added > by this series. > > From what I see, indeed, the mac_link_up() function is called before > stmmac_hw_setup(). This does not seems to have any effect on my setup > (except making it working of course) but I agree this is clearly not > ideal. > > What I could do is adding a function in the miic pcs driver that could > be called from my rzn1 stmmac probe function to actually configure the > PCS at probe time based on the detected "phy-mode". Does that seems > better to you ? I think Clark Wang is also working on addressing a very similar problem with stmmac. Please can you check out his work first, he's adding a new function to phylink to bring the PHY up early in the resume path. I would like you both to work together to address what seems to be the same issue.
Le Fri, 10 Feb 2023 11:03:34 +0000, "Russell King (Oracle)" <linux@armlinux.org.uk> a écrit : > On Tue, Feb 07, 2023 at 03:41:35PM +0100, Clément Léger wrote: > > Le Mon, 16 Jan 2023 10:53:49 +0000, > > "Russell King (Oracle)" <linux@armlinux.org.uk> a écrit : > > > > > On Mon, Jan 16, 2023 at 11:39:23AM +0100, Clément Léger wrote: > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > > index f2247b8cf0a3..88c941003855 100644 > > > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > > @@ -3818,6 +3818,12 @@ static int __stmmac_open(struct net_device *dev, > > > > } > > > > } > > > > > > > > + /* We need to setup the phy & PCS before accessing the stmmac registers > > > > + * because in some cases (RZ/N1), if the stmmac IP is not clocked by the > > > > + * PCS, hardware init will fail because it lacks a RGMII RX clock. > > > > + */ > > > > + phylink_start(priv->phylink); > > > > > > So what happens if you end up with the mac_link_up method being called > > > at this point in the driver, before the hardware has been setup ? > > > > > > If you use a fixed-link, that's a real possibility. > > > > I actually have this setup. On the board, one GMAC is connected to a > > DSA switch using a fixed-link and the other using the PCS such as added > > by this series. > > > > From what I see, indeed, the mac_link_up() function is called before > > stmmac_hw_setup(). This does not seems to have any effect on my setup > > (except making it working of course) but I agree this is clearly not > > ideal. > > > > What I could do is adding a function in the miic pcs driver that could > > be called from my rzn1 stmmac probe function to actually configure the > > PCS at probe time based on the detected "phy-mode". Does that seems > > better to you ? > > I think Clark Wang is also working on addressing a very similar problem > with stmmac. Please can you check out his work first, he's adding a new > function to phylink to bring the PHY up early in the resume path. > > I would like you both to work together to address what seems to be the > same issue. > Acked
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index f2247b8cf0a3..88c941003855 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3818,6 +3818,12 @@ static int __stmmac_open(struct net_device *dev, } } + /* We need to setup the phy & PCS before accessing the stmmac registers + * because in some cases (RZ/N1), if the stmmac IP is not clocked by the + * PCS, hardware init will fail because it lacks a RGMII RX clock. + */ + phylink_start(priv->phylink); + ret = stmmac_hw_setup(dev, true); if (ret < 0) { netdev_err(priv->dev, "%s: Hw setup failed\n", __func__); @@ -3826,7 +3832,6 @@ static int __stmmac_open(struct net_device *dev, stmmac_init_coalesce(priv); - phylink_start(priv->phylink); /* We may have called phylink_speed_down before */ phylink_speed_up(priv->phylink);