On Tue, Feb 18, 2025 at 07:34:47PM +0800, Inochi Amaoto wrote: > On Tue, Feb 18, 2025 at 10:40:14AM +0000, Russell King (Oracle) wrote: > > 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. > > > > What I said follows the second, the clock is set at 2.5/25/125MHz > with speed at 10/100/1000Mbps. The only thing I can refer to is the > ip databook. > > > 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). > > > > OK, I have no problem and find some descriptions related to this in > the databook. > > > 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. > > > > This is what I want to say. clk_rx_i is not fixed but the > s32 uses it as a fixed one (This is the thing I felt weird). > > In fact, Non-fixed clk_rx_i is why I suggested adding the rx > clock to the core at first. Since the drive may not use rx > clock as the databook says, it is good to leave it alone. Please ignore my wrong point, I mistake the direction of the rx clock. It is not provided by the mac, but the phy. Regards, Inochi
