On Thu, Jan 8, 2026 at 12:02 PM Chaoyi Chen [off-list ref] wrote:

On 1/8/2026 3:42 PM, Chaoyi Chen wrote:

quoted

Hello Alexey, Andrew,

On 1/8/2026 2:53 PM, Alexey Charkov wrote:

quoted

On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn [off-list ref] wrote:

quoted

quoted

+&gmac0 {
+     clock_in_out = "output";
+     phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock
line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Actually it would be great if Rockchip could clarify the delay
duration introduced by a single delay element in GMAC-IOMUX delay
lines, which are controlled in the GMAC driver by the {tx,rx}_delay
properties. Maybe we could then switch to using
{tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side
as envisaged in DT bindings [1], and use phy-mode = "rgmii-id"
throughout. Chaoyi, any chance you could ask around in your hardware
team?

Currently though removing the delays at GMAC side altogether causes
unstable link operation - see [2] for example.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
[2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c

Sorry, this problem has been discussed many times before. It's because
the gmac on the Rockchip platform currently relies on setting the
corresponding delay via phy-mode [3].

[3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/ (local)

The delay introduced by the delay line is not absolute. In reality,
it depends on factors such as the chip's design and process technology.

And for RK3576, you can assume that:

      time(ns) = 0.0579 * delay_line_count + 0.105

For example, tx_delay = <0x20> means:

      time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns

And I believe {tx,rx}_internal_delay_ps is indeed a good idea.
I'll try to add them in v3. Thanks.

I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY,
and compared to doing it in the MAC, which one is the better choice?

Your PHY defaults to 1950ps in rgmii-id [1], so adding anything on top
of that on GMAC side would land you with a longer total TX delay than
you currently get according to the coefficients you've just posted
(1784.1ps). I would say go for "tx-internal-delay-ps = <1800>" on the
PHY side for the closest match.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36

Best regards,
Alexey