Re: [PATCH net-next v5 3/3] net: stmmac: Add glue layer for Sophgo SG2044 SoC

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Feb 18, 2025 at 09:01:59AM +0800, Inochi Amaoto wrote:
> On Mon, Feb 17, 2025 at 11:21:28PM +0000, Russell King (Oracle) wrote:
> > 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.
> > 
> 
> RGMII is not the problem. The databook says the RGMII clock (rx/tx)
> follows this set rate logic. 

Sorry, I find this ambiguous. "This" doesn't tell me whether you are
referring to either what s32 does (setting the "rx" clock to 125MHz
only) or what RGMII spec says about RX_CLK (which is that it comes from
the PHY and is 2.5/25/125MHz) which stm32mp151 agrees with and feeds
the PHY's RX_CLK to the clk_rx_i inputs on the DWMAC in RGMII, GMII
and MII modes.

clk_rx_i comes through a bunch of muxes on stm32mp151. When the clock
tree is configured for RMII mode, the rate on clk_rx_i depends on the
MAC speed (10/100Mbps).

This suggests as far as the core is concerned, the clock supplied as
clk_rx_i isn't a fixed rate clock but depends on the speed just like
the transmit clock.

> For other things, I agree with you. A fixed "rx" clock does reach the
> limit of what I know. And the databook told nothing about it. As we
> can not determine the rx clock of s32 and it may be set for the phy,
> it will be better to not move it into the core.

I'm intending to leave s32's rx clock alone for this reason as it does
not match what I expect. Maybe on s32 there is a bunch of dividers
which are selected by the mac_speed_o signals from the core to divide
the 125MHz clock down to 25 or 2.5MHz for 100 and 10Mbps respectively.
As I don't know, it's safer that I leave it alone as that means the
"rx" clock used there is not clk_rx_i.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!