The "rgmii-id" PHY mode applies a symmetric 2ns internal delay in the
PHY. On the Pico-ITX board this leaves insufficient TX timing margin and
no ethernet traffic passes.

Add a 400ps MAC-side TX internal delay on top of the PHY's delay to
correct the TX clock/data skew. The value follows the vendor fork's
asymmetric tuning (tx-phase 73 x 33.3ps - 2000ps ID ~= 400ps); the
driver rounds tx-internal-delay-ps to the nearest supported step.

This builds on commit 3ea695eb111f ("dts: riscv: spacemit: k3: Fix I/O
power settings"), which fixed the GMAC0 1.8V/3.3V I/O switch

Tested on Pico-ITX hardware with iperf3: 60s TCP each direction and 60s
UDP, all at 1Gbps with no TX/RX errors on the interface.

Fixes: 74657a376960 ("riscv: dts: spacemit: Add ethernet device for K3")
Signed-off-by: Andrew Rembrandt <kernel@rembrandt.dev>
---
 arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
index b89c1521e664..59aecaa2d32a 100644
--- a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
+++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
@@ -186,6 +186,7 @@ &eth0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&gmac0_rgmii_0_cfg>, <&gmac0_phy_0_cfg>;
 	phy-mode = "rgmii-id";
+	tx-internal-delay-ps = <400>;
 	phy-handle = <&phy0>;
 	status = "okay";
 
-- 
2.54.0

On Mon, Jun 08, 2026 at 08:23:58PM +0200, Andrew Rembrandt wrote:
> The "rgmii-id" PHY mode applies a symmetric 2ns internal delay in the
> PHY. On the Pico-ITX board this leaves insufficient TX timing margin and
> no ethernet traffic passes.
> 
> Add a 400ps MAC-side TX internal delay on top of the PHY's delay to
> correct the TX clock/data skew. The value follows the vendor fork's
> asymmetric tuning (tx-phase 73 x 33.3ps - 2000ps ID ~= 400ps); the
> driver rounds tx-internal-delay-ps to the nearest supported step.
> 
> This builds on commit 3ea695eb111f ("dts: riscv: spacemit: k3: Fix I/O
> power settings"), which fixed the GMAC0 1.8V/3.3V I/O switch
> 
> Tested on Pico-ITX hardware with iperf3: 60s TCP each direction and 60s
> UDP, all at 1Gbps with no TX/RX errors on the interface.
> 
> Fixes: 74657a376960 ("riscv: dts: spacemit: Add ethernet device for K3")
> Signed-off-by: Andrew Rembrandt <kernel@rembrandt.dev>
> ---
>  arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> index b89c1521e664..59aecaa2d32a 100644
> --- a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> @@ -186,6 +186,7 @@ &eth0 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&gmac0_rgmii_0_cfg>, <&gmac0_phy_0_cfg>;
>  	phy-mode = "rgmii-id";
> +	tx-internal-delay-ps = <400>;
>  	phy-handle = <&phy0>;
>  	status = "okay";
>  

You should set tx-internal-delay-ps of the phy instead of
the controller. This is a phy in "rgmii-id" mode.

Regards,
Inochi

On Tue, Jun 09, 2026 at 01:37:56 pm Inochi Amaoto wrote:
> You should set tx-internal-delay-ps of the phy instead of
> the controller. This is a phy in "rgmii-id" mode.
Thanks for the review. I don't think that works on this board, but
please let me know if I'm missing something.

The PHY is a Realtek RTL8211F. Its driver only toggles the chip's fixed
~2ns delay on/off from phy-mode, and per the datasheet that's a hardware
limit, not a driver one -- the RTL8211F has no tunable delay, so a ps
value on the PHY node has nothing to act on.

The only configurable delay element on K3 is the SoC RGMII delay line,
and dwmac-spacemit programs it from tx-/rx-internal-delay-ps read off
the controller node (spacemit_dwmac_probe()), so that is where the
property has to live to take effect. This is the MAC "fine tuning ...
values expected here are small" case described in
Documentation/devicetree/bindings/net/ethernet-controller.yaml: the
RTL8211F supplies the fixed ~2ns via rgmii-id and the MAC adds a 400ps
trim on top. Ideally the PHY would own the delay, but as Andrew Lunn
noted reviewing dwmac-meson8b, that requires the PHY to implement a
configurable delay, which not all do.

The already-merged k1-bananapi-f3 does the same thing: eth1 combines
phy-mode = "rgmii-id" with tx-internal-delay-ps = <250> on the
controller node (via the K1 EMAC rather than dwmac, but the same DT
pattern).

Would you be OK keeping it on the controller given the above? For v2 I
can add an explicit rx-internal-delay-ps = <0> to match the other
SpacemiT boards (k1-bananapi-f3 included) and spell this reasoning out
in the commit message.

Thanks,
Andrew

On Tue, Jun 09, 2026 at 08:24:46PM +0200, Andrew Rembrandt wrote:
> On Tue, Jun 09, 2026 at 01:37:56 pm Inochi Amaoto wrote:
> > You should set tx-internal-delay-ps of the phy instead of
> > the controller. This is a phy in "rgmii-id" mode.
> Thanks for the review. I don't think that works on this board, but
> please let me know if I'm missing something.
> 
> The PHY is a Realtek RTL8211F. Its driver only toggles the chip's fixed
> ~2ns delay on/off from phy-mode, and per the datasheet that's a hardware
> limit, not a driver one -- the RTL8211F has no tunable delay, so a ps
> value on the PHY node has nothing to act on.
> 
> The only configurable delay element on K3 is the SoC RGMII delay line,
> and dwmac-spacemit programs it from tx-/rx-internal-delay-ps read off
> the controller node (spacemit_dwmac_probe()), so that is where the
> property has to live to take effect. This is the MAC "fine tuning ...
> values expected here are small" case described in
> Documentation/devicetree/bindings/net/ethernet-controller.yaml: the
> RTL8211F supplies the fixed ~2ns via rgmii-id and the MAC adds a 400ps
> trim on top. Ideally the PHY would own the delay, but as Andrew Lunn
> noted reviewing dwmac-meson8b, that requires the PHY to implement a
> configurable delay, which not all do.
> 
> The already-merged k1-bananapi-f3 does the same thing: eth1 combines
> phy-mode = "rgmii-id" with tx-internal-delay-ps = <250> on the
> controller node (via the K1 EMAC rather than dwmac, but the same DT
> pattern).
> 
> Would you be OK keeping it on the controller given the above? 

Yes, it is good for me.


> For v2 I can add an explicit rx-internal-delay-ps = <0> to match 
> the other SpacemiT boards (k1-bananapi-f3 included) and spell this
> reasoning out in the commit message.
> 

Do not do this, just leave the rx-internal-delay-ps untouched.

For this patch

Reviewed-by: Inochi Amaoto <inochiama@gmail.com>

Regards,
Inochi.

On Wed, Jun 10, 2026 at 07:14:56 am Inochi Amaoto wrote:
> Do not do this, just leave the rx-internal-delay-ps untouched.

Sounds good, I'll leave v1 as-is. Many thanks for the review.

Regards,

Andrew

Hi Andrew,

On 6/10/26 02:05, Andrew Rembrandt wrote:
> On Wed, Jun 10, 2026 at 07:14:56 am Inochi Amaoto wrote:
>> Do not do this, just leave the rx-internal-delay-ps untouched.
> 
> Sounds good, I'll leave v1 as-is. Many thanks for the review.
> 
> Regards,
> 
> Andrew
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

I do not notice any difference with or without this property present,
tested Linux -next with U-Boot modification to devicetree:

load usb 0:1 $fdt_addr_r /dtb/spacemit/k3-pico-itx.dtb
fdt addr $fdt_addr_r
fdt resize
fdt header get filesize totalsize
fdt set /soc/ethernet@cac80000 tx-internal-delay-ps <400>
load usb 0:1 $kernel_addr_r /EFI/BOOT/BOOTRISCV64.EFI
# throwaway use of ping is workaround for broken vendor U-Boot
ping 127.0.0.1; bootefi $kernel_addr_r $fdt_addr_r

Aside, there is still some problem with the driver which does cause it
to fail. This can be reproduced by unloading the module and then loading
the module; built from -next with 'olddefconfig' of debian Kconfig for
kernel 7.1, no patches.

# modprobe -r dwmac_spacemit
# modprobe dwmac_spacemit
[   61.469745] spacemit-dwmac cac80000.ethernet end0: cannot attach to
PHY (error: -ENODEV)

[   91.544646] spacemit-dwmac cac80000.ethernet end0: cannot attach to
PHY (error: -ENODEV)

If not reloading the module then I don't see any difference, traffic
passes (ping 1.1.1.1) with or without your suggested
tx-internal-delay-ps property. Is there a specific test to run to
observe expected difference?

Thanks,

-E