On 2024-11-27 14:17, Yijie Yang wrote:
On 2024-11-22 21:19, Andrew Lunn wrote:
+ðernet {
+ status = "okay";
+
+ pinctrl-0 = <ðernet_defaults>;
+ pinctrl-names = "default";
+
+ phy-handle = <&rgmii_phy>;
+ phy-mode = "rgmii";
That is unusual. Does the board have extra long clock lines?
Do you mean to imply that using RGMII mode is unusual? While the
EMAC controller supports various modes, due to hardware design
limitations, only RGMII mode can be effectively implemented.
Is that a board-specific issue, or something that concerns the SoC
itself?
Lots of developers gets this wrong.... Searching the mainline list for
patchs getting it wrong and the explanation i have given in the past
might help.
The usual setting here is 'rgmmii-id', which means something needs to
insert a 2ns delay on the clock lines. This is not always true, a very
small number of boards use extra long clock likes on the PCB to add
the needed 2ns delay.
Now, if 'rgmii' does work, it means something else is broken
somewhere. I will let you find out what.
The 'rgmii' does function correctly, but it does not necessarily mean
that a time delay is required at the board level. The EPHY can also
compensate for the time skew.
I was mistaken earlier; it is actually the EMAC that will introduce a
time skew by shifting the phase of the clock in 'rgmii' mode.
+ max-speed = <1000>;
Why do you have this property? It is normally used to slow the MAC
down because of issues at higher speeds.
According to the databoot, the EMAC in RGMII mode can support speeds
of up to 1Gbps.
I believe the question Andrew is asking is "how is that effectively
different from the default setting (omitting the property)?"
Correct. If there are no issues at higher speeds, you don't need
this. phylib will ask the PHY what it is capable of, and limit the
negotiated speeds to its capabilities. Occasionally you do see an
RGMII PHY connected to a MII MAC, because a RGMII PHY is cheaper...
Andrew
It does unnecessary, I will remove it.
--
Best Regards,
Yijie
