Re: [RFC PATCH 6/6] arm64: dts: amlogic: t7: khadas-vim4: enable the ethernet port

On Mon, Oct 5, 2026 at 5:27 PM Andrew Lunn [off-list ref] wrote:

quoted

+&ethmac {
+     status = "okay";
+     pinctrl-0 = <&eth_pins>, <&eth_rgmii_pins>;
+     pinctrl-names = "default";
+
+     /*
+      * The RGMII clock delays are added by the MAC, so the PHY is
+      * asked for the mode that adds none.
+      */
+     phy-mode = "rgmii";
+     phy-handle = <&external_phy>;
+     amlogic,tx-delay-ns = <2>;
+     rx-internal-delay-ps = <2000>;

I agree with Maxime here, rgmii is wrong. We really need to understand
what is going on here, especially since you are asking for the MAC to
do the usual 2ns, nothing special.

Is the PHY not actually inserting the correct delay?

It does. The PHY driver shows both delay bits going from off to on, so
nothing was strapped and the bootloader did not set them.

I swept the MAC RX clock delay and counted CRC errors, to see where the
good window is:

  MAC does RX delay, PHY none:  clean 400 .. 3800ps
  PHY does RX delay, MAC adds:  clean 0 .. 1600ps

Same window, moved 11 steps. So the PHY gives about 2200ps, and the
first window is centred at 2100ps. It is right.

Transmit is the broken one. With rgmii-txid the peer sees nothing we
send.

What does the

datasheet say?

The A311D2 covers both ways of doing it. Table 5-21, RGMII receive:

  PHY internal delay on:   needs 1.2ns setup and 1.2ns hold
  PHY internal delay off:  needs -0.5 .. 0.5ns skew

with a note to check setup/hold when the PHY delay is on, and skew when
it is off. Table 5-22 does the same for transmit, separate numbers for
"clock delay added" and "no clock delay added".

So the MAC doing the delay is a documented mode of this SoC.

What it does not say is why the PHY TX delay misses. I asked Khadas
about the clock trace lengths, no answer yet.

Also, we have one vendor property and one generic property. Can
amlogic,tx-delay-ns be replaced by tx-internal-delay-ps? But that
comes later, once we have determined these properties really must be
used.

A new version of the series will have a fix for it. It will prefer the
generic one.
One thing to know: that register field is a fraction of the clock
period, not a time.
The driver comment says "8ns / 4 * tx_dly_val". A quarter cycle is 2ns
at 1Gbit and 10ns
at 100Mbit, so 2000 is only true at gigabit.

Humm, what is meson8b_init_rgmii_delays() doing?

It picks the MAC delays from phy-mode alone, with the sense inverted:

  rgmii       MAC adds both delays
  rgmii-rxid  MAC adds TX
  rgmii-txid  MAC adds RX
  rgmii-id    MAC adds none

So the mode that says the delays are internal is the one where the MAC
switches its own off. It also ignores the *-internal-delay-ps
properties in those modes. With rgmii-id and both of them set I get:

  phy-mode rgmii-id: tx-delay-ns 2 rx-delay-ps 2000
    -> PRG_ETH0 delay_config 0x0, PRG_ETH1 cfg_rxclk_dly 0x0

What is

phydev->interface in the PHY driver.

Whatever phy-mode says, dwmac-meson8b.c never rewrites it. Which
means the MAC and the PHY always split the job:

  rgmii       MAC both    PHY none
  rgmii-rxid  MAC TX      PHY RX
  rgmii-txid  MAC RX      PHY TX
  rgmii-id    MAC none    PHY both

They never both delay the same clock, and never both skip it. So the
driver is self consistent, it is just labelled backwards from phy.rst.
That is why the boards using "rgmii" work, and why rgmii-id is the one
that does not here: it is the mode that hands everything to the PHY.

Please take a read on:

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

and figure out what is going on here, because at a first look, it
seems broken.

      Andrew

It is broken. phy-mode describes the PCB, but dwmac-meson8b.c reads it
as which chip adds the delay. The labels are backwards, and in rgmii-id
both *-internal-delay-ps properties are ignored.

I measured each direction with an eye scan. The PHY RX delay is fine,
about 2200ps. Its TX delay does not work at all, so the MAC must do
that one.

Fix: in the -id modes each *-internal-delay-ps property means the MAC
does that delay, and the PHY is told to do the rest:

  both properties    MAC does TX and RX     PHY told rgmii
  tx property only    MAC does TX                 PHY told rgmii-rxid
  rx property only    MAC does RX                 PHY told rgmii-txid
  no property           MAC does nothing          PHY told rgmii-id

Boards without those properties keep today's behaviour, so
meson8b-odroidc1 and meson8m2-mxiii-plus are untouched.

Vim4 will use phy-mode = "rgmii-id" with tx-internal-delay-ps =
<2000>. 935Mbit/s both ways, no CRC errors.

I am sending a v2 with the fix for dwmac-meson8b.c  as its own patch.

Thanks
Lucas