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

[Quentin Schulz <quentin.schulz@cherry.de>]

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@lunn.ch> 于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@cherry.de/

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

Cheers,
Quentin