Current RGMII TXD/RXD delay results in link instability
under load, with throughput eventually dropping to zero.
Adjust the RGMII TXD/RXD delay values for stable link
under load and stable Gigabit throughput

Signed-off-by: Adrian Kossmann <adrian.kossmann@posteo.de>
---
Changes in v2:
- Changed the patch subject as the last one contained
  incorrect changes
- Drop incorrect PHY compatible string change from v1
- Adjustments to RGMII RX/TX delay values
- Link to v1: https://lore.kernel.org/linux-rockchip/20251209210658.458506-2-adrian.kossmann@posteo.de/

 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
index a4bdd87d0729..29ff0b8b8f18 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -153,8 +153,8 @@ &gmac2io {
 	phy-supply = <&vcc_io>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&rgmiim1_pins>;
-	tx_delay = <0x26>;
-	rx_delay = <0x11>;
+	tx_delay = <0x1a>;
+	rx_delay = <0x14>;
 	status = "okay";
 
 	mdio {
-- 
2.52.0

On Fri, Dec 12, 2025 at 10:02:24PM +0000, Adrian Kossmann wrote:
> Current RGMII TXD/RXD delay results in link instability
> under load, with throughput eventually dropping to zero.
> Adjust the RGMII TXD/RXD delay values for stable link
> under load and stable Gigabit throughput
> 
> Signed-off-by: Adrian Kossmann <adrian.kossmann@posteo.de>
> ---
> Changes in v2:
> - Changed the patch subject as the last one contained
>   incorrect changes
> - Drop incorrect PHY compatible string change from v1
> - Adjustments to RGMII RX/TX delay values
> - Link to v1: https://lore.kernel.org/linux-rockchip/20251209210658.458506-2-adrian.kossmann@posteo.de/
> 
>  arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> index a4bdd87d0729..29ff0b8b8f18 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> @@ -153,8 +153,8 @@ &gmac2io {
>  	phy-supply = <&vcc_io>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&rgmiim1_pins>;
> -	tx_delay = <0x26>;
> -	rx_delay = <0x11>;
> +	tx_delay = <0x1a>;
> +	rx_delay = <0x14>;
>  	status = "okay";

You cannot see it here, it appears before this context:

&gmac2io {
        assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
        assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
        clock_in_out = "input";
        phy-handle = <&rtl8211>;
        phy-mode = "rgmii";

rgmii means the PCB provides the delay. I doubt that is the
case. Please try changing this to rgmii-id, as recommended here:

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287

and then try out different rx_delay and tx_delay values.

    Andrew

Hi Andrew,

> rgmii means the PCB provides the delay. I doubt that is the
> case.

Yes, however, to my understanding, there are two kinds of delays that
influence RGMII timing: Delays that are added onto the clock signal 
(TXC/RXC) and delays added to the data signal (TXD/RXD) by the GMAC.
The link provided by you describes delays that are either introduced by 
longer clock traces  on the PCB (rgmii phy-mode) or by programmable clock delays 
(rgmii-id phy-mode). Delays for TXD timing and RXD timing are described in [1] 
and are implemented by the Rockchip Ethernet driver which is bound to node 
gmac2io according to [2]. The example DT binding in [1] as well as other 
mainline DTS of devices that use the RK3328 seem to adjust RGMII timing 
via TXD and RXD delays and setting phy-mode to rgmii, despite having 
programmable TXC/RXC delays, at least according to the technical 
manual of the RK3328. So, in this case this may be an exception
from the usual convention that any RGMII phy mode other than 
'rgmii-id' is probably wrong.

Of course, I may have overlooked something or misunderstood, and I 
would appreciate further guidance in this case.

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
[2] https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/tree/arch/arm64/boot/dts/rockchip/rk3328.dtsi#n982


      Adrian