[PATCH 2/2] arm64: dts: rockchip: Add rk3399-evb-ind board

[Andrew Lunn]

On Tue, Apr 29, 2025 at 10:42:59AM +0800, Chaoyi Chen wrote:
> Hi Andrew,
> 
> On 2025/4/28 20:45, Andrew Lunn wrote:
> > On Mon, Apr 28, 2025 at 09:47:34AM +0800, Chaoyi Chen wrote:
> > > Hi Andrew,
> > > 
> > > On 2025/4/28 4:42, Andrew Lunn wrote:
> > > > > +&gmac {
> > > > > +	assigned-clocks = <&cru SCLK_RMII_SRC>;
> > > > > +	assigned-clock-parents = <&clkin_gmac>;
> > > > > +	pinctrl-names = "default";
> > > > > +	pinctrl-0 = <&rgmii_pins>;
> > > > > +	clock_in_out = "input";
> > > > > +	phy-supply = <&vcc_phy>;
> > > > > +	phy-mode = "rgmii";
> > > > Does the PCB have extra long clock lines to implement the RGMII 2ns
> > > > delay?
> > > The 2ns delay of RGMII is implemented inside the RK3399 chip instead of PCB
> > > lines, and there are also additional delayline configurations.
> > If the PCB does not implement the delay, rgmii is wrong.
> > 
> > If the MAC/PHY pair is implementing the delay, you need to use
> > rgmii-id. You can then use additional properties to fine tune the
> > delay the MAC/PHY is adding. And the Linux preference is that the PHY
> > adds the delay.
> 
> The signal path of RK3399 is as follows:
> 
> MAC <---> IO <---> PHY
> 
> In fact, the delay is added to the path between the MAC and the IO, rather
> than being implemented in the MAC itself. These delay value is controlled by
> the GRF register[0] . These paths are implemented inside the SoC and have
> not yet reached the board level.

'rgmii' implies that the PCB is implementing the delay. Since this is
not the case here, you should be using rgmii-id.

> According to the document[1], use "rgmii" when "RX and TX delays are added
> by the MAC when required". In addition, currently we can see that all RK3399
> boards use "rgmii".  Is there anything I missed? Thank you.

What you are missing is that they are all wrong. Quite a few systems
get is wrong at the moment, and i'm being more strict. Ideally i want
to stop more examples of wrong rgmii being added. There is also a
discussion going on to clarify the documentation.

Implementing delays via the IO is also reasonably common. The MAC
should have control over the GRF register, normally via syscon. So the
MAC can implement correct behaviour. The default is that the MAC,
including IO, adds 0 delay, passes phy-mode to the PHY and the PHY
adds the delay.

Please consider how you can fix the MAC driver without breaking all
the boards using the wrong rgmii value. There are a few discussion
about this on the mailing list if you go searching.

	Andrew