> >>> +ð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.
> >>> + 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
