[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7PEeGmNvlYD33rZ@shell.armlinux.org.uk>
Date: Mon, 17 Feb 2025 23:21:28 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Inochi Amaoto <inochiama@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Chen Wang <unicorn_wang@...look.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Richard Cochran <richardcochran@...il.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
"Jan Petrous (OSS)" <jan.petrous@....nxp.com>,
Hariprasad Kelam <hkelam@...vell.com>,
Clément Léger <clement.leger@...tlin.com>,
Jisheng Zhang <jszhang@...nel.org>,
Emil Renner Berthing <emil.renner.berthing@...onical.com>,
Drew Fustini <dfustini@...storrent.com>,
Furong Xu <0x1207@...il.com>,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Joe Hattori <joe@...is.s.u-tokyo.ac.jp>,
Serge Semin <fancer.lancer@...il.com>,
Lothar Rubusch <l.rubusch@...il.com>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Jose Abreu <joabreu@...opsys.com>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
sophgo@...ts.linux.dev, linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org,
linux-riscv@...ts.infradead.org, Yixun Lan <dlan@...too.org>,
Longbin Li <looong.bin@...il.com>
Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add glue layer for Sophgo
SG2044 SoC
On Tue, Feb 18, 2025 at 06:50:24AM +0800, Inochi Amaoto wrote:
> On Mon, Feb 17, 2025 at 02:10:50PM +0000, Russell King (Oracle) wrote:
> > On Mon, Feb 17, 2025 at 02:25:33PM +0100, Andrew Lunn wrote:
> > > > I am not sure all whether devices has this clock, but it appears in
> > > > the databook. So I think it is possible to move this in the core so
> > > > any platform with these clock can reuse it.
> > >
> > > Great
> > >
> > > The next problem will be, has everybody called it the same thing in
> > > DT. Since there has been a lot of cut/paste, maybe they have, by
> > > accident.
> >
> > Tegra186: "tx"
> > imx: "tx"
> > intel: "tx_clk"
> > rk: "clk_mac_speed"
> > s32: "tx"
> > starfive: "tx"
> > sti: "sti-ethclk"
> >
>
> The dwc-qos-eth also use clock name "tx", but set the clock with
> extra calibration logic.
Yep, that's what I meant by "Tegra186" above.
> > so 50% have settled on "tx" and the rest are doing their own thing, and
> > that horse has already bolted.
> >
>
> The "rx" clock in s32 also uses the same logic. I think the core also
> needs to take it, as this rx clock is also mentioned in the databook.
The "rx" clock on s32 seems to only be set to 125MHz, and the driver
seems to be limited to RGMII.
This seems weird as the receive clock is supposed to be supplied by the
PHY, and is recovered from the media (and thus will be 2.5, 25 or
125MHz as determined by the PHY.) So, I'm not sure that the s32 "rx"
clock is really the clk_rx_i clock supplied to the DWMAC core.
Certainly on stm32mp151, it states that ETH_RX_CLK in RGMII mode will
be 2.5, 25 or 125MHz provided by the PHY, and the clock tree indicates
that ETH_RX_CLK in RGMII mode will be routed directly to the clk_rx_i
input on the DWMAC(4) core.
> > I have some ideas on sorting this out, and I'm working on some patches
> > today.
>
> Great, Could you cc me when you submit them? So I can take it and
> change my series.
Will do - I'm almost at that point, I have three other cleanup patches
I will be sending before hand, so I'll send those out and then this
series as RFC.
The only platform drivers I've left with a call to rgmii_clock() are
sti, imx (for imx93 only as that does extra fiddling after setting the
clock and I'm not sure if there's an ordering dependency there) and
the rk platforms.
Five platforms converted, three not, and hopefully your platform can
also use the helper as well!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists