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. At last, it seems like that I need to improve my statement. I am sorry for it. > > 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. > Thanks for your explanation. This is OK for me. Regards, Inochi
