Re: [PATCH v3 7/8] arm64: dts: amlogic: t7: khadas-vim4: enable the ethernet port

From: Lucas Tanure <tanure@linux.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: xianwei.zhao@amlogic.com, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 7/8] arm64: dts: amlogic: t7: khadas-vim4: enable the ethernet port
Date: Thu, 22 Oct 2026 18:40:51 +0100	[thread overview]
Message-ID: <74840159-62d9-4d6d-a0c3-b079e6e4da6e@linux.com> (raw)
In-Reply-To: <CAFBinCC8iKESoc2zEXJMEmqk0cwWbVap-a2KcAtB7-KFKO9Atg@mail.gmail.com>

On 10/10/2026 23:00, Martin Blumenstingl wrote:
> On Sat, Oct 10, 2026 at 12:59 PM Lucas Tanure <tanure@linux.com> wrote:
> [...]
>> RGMII needs a delay on each of its two clocks, and on this board
>> both come from inside the chips, not from the board traces. The PHY
>> adds the one on receive. Its transmit delay does not work here, so the
>> controller adds that one.
> [...]
>> +&ethmac {
>> +       status = "okay";
>> +       pinctrl-0 = <&eth_pins>, <&eth_rgmii_pins>;
>> +       pinctrl-names = "default";
>> +       phy-mode = "rgmii-id";
>> +       phy-handle = <&external_phy>;
>> +       tx-internal-delay-ps = <2000>;
> You're stating that RTL8211F's TX delay doesn't work but not explaining why.
> I haven't come across this behavior before and I'm worried that that's
> an issue with a batch of RTL8211F.
> What if the previous/next batch of RTL8211F will have working TX delay
> again - wouldn't that mean 4ns delay in total unless the RTL8211F
> driver is changed?

Yes, you are right. After I understood I had a missing clock I re-tested 
the everything from scratch.

On the T7 the register block with PRG_ETH0/PRG_ETH1 sits behind a clock
gate (the "pclk" clock in patches 2 and 6). My first tests ran before I
knew about that gate: the block ignored every write and PRG_ETH0 kept
the value the bootloader left there, 0x1621. Bit 5 of that value is the
TX clock phase select, 1/4 cycle, which is 2ns at 1Gbit/s. So with
"rgmii-id" the PHY added 2ns and the MAC added another 2ns nobody asked
for, 4ns in total. The CRC errors from that made me believe the PHY TX
delay was not working.

With the clock enabled and a plain "rgmii-id" node, no delay property:

   PRG_ETH0 = 0x1601 (TX phase 0), PRG_ETH1 = 0x0
   RTL8211F page 0xd08: reg 0x11 = 0x0109 (TX delay on),
                        reg 0x15 = 0x0019 (RX delay on)
   iperf3: 940 Mbit/s board to PC, 943 Mbit/s PC to board, 0 retransmits
   0 CRC errors on both ends

v4 drops tx-internal-delay-ps from the VIM4 node and the wrong sentence
from the commit message. The PHY adds both delays, as the generic text
expects.

Thanks
Lucas

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic