Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Quentin Schulz]

Hi Russel,

On 10/7/25 6:25 PM, Russell King (Oracle) wrote:
> On Tue, Oct 07, 2025 at 04:57:32PM +0200, Andrew Lunn wrote:
> > On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote:
> > > Andrew Lunn <andrew@xxxxxxx> 于2025年10月6日周一 23:51写道：
> > > > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > > > us the schematics which clearly show extra long clock lines.
> > >
> > > In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
> > > just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
> > > https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237
> >
> > Pull low makes no difference to the 2ns RGMII delays.
>
> To be clear, while the RXDLY and TXDLY are hardware strapping controls
> the hardware configuration of the 2ns RGMII clock delays, the realtek
> driver can (and does) override this according to the phy-mode property.
> Thus hardware strapping makes no difference to Linux.
>
> So, what we get at the RTL8211F PHY is:
>
> 	phy-mode	receive clock delay	transmit clock delay
> 	"rgmii"		0ns			0ns
> 	"rgmii-rxid"	2ns			0ns
> 	"rgmii-txid"	0ns			2ns
> 	"rgmii-id"	2ns			2ns
>
> irrespective of RXDLY / TXDLY hardware strapping.
>
> > > The tx_delay and rx_delay values were obtained using Rockchip's
> > > automatic scanning tool:
> > > https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
> > > https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> > > https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> >
> > Vendors get things wrong, including this. 'rgmii' means the PCB adds
> > the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> > vendor recommendations, and then i come along, point out how it is
> > wrong, and ask for it to be fixed, before being merged to Mainline.
>
> Can we at least get the "tx_delay" and "rx_delay" DT properties (which
> are register values) properly documented in the DT binding document?
> I know from the driver code that a value of 0 means "no delay". Other
> values add an unspecified delay - it is not obvious what any non-zero
> value means, or what the default means.
>
> This would help us understand what values such as:
>
> 	tx_delay = 0x3c or 0x4f
>
> and
>
> 	rx_delay = 0x2f or 0x26
>
> actually mean in terms of the resulting delay at the MAC.

I couldn't figure out what they actually mean empirically, see 
https://lore.kernel.org/linux-rockchip/96d32ce8-394b-4454-8910-a66be2813588@xxxxxxxxx/

Without Rockchip's explanation on what this actually does, I'm not sure 
there's something we can do on this side.

Cheers,
Quentin