On 3/7/2026 9:12 pm, Andrew Lunn wrote:

quoted

quoted

quoted

The delays are provided by the FPGA GMII-to-RGMII converter soft IP,
which is hardcoded in the FPGA bitstream and cannot be disabled or
modified from the driver side.

Using phy-mode = "rgmii" is intentional here — it prevents the PHY from
adding its own internal delays on top, since the FPGA converter already
provides the full required delay. This is consistent with how all other
Agilex5 SoCDK board variants are described, as seen in commit
c5637e5ceb4b ("arm64: dts: socfpga: agilex5: Fix phy-mode to rgmii as HW
provides clock delay") already in Dinh Nguyen's tree, which applies the
same rationale across all Agilex5 boards.

I've become more insistent that designs get this correct. So i don't
care too much about past systems. Many vendors are having to fix up
their drivers and DT in order to make new boards consistent.

You can look at your system as the FPGA being the MAC, and the PHY is
the PHY. The PCB is not providing the delay, the MAC is. This exactly
fits the description above.

       Andrew

Hi Andrew,

Thank you for the clarification. We agree with your framework in
principle, but would like to explain why phy-mode = "rgmii" is the
appropriate description for this specific case.

So you want to be different to every other system? Please extend the
text in that document to say that this device is special and has a
different definition of phy-mode to all other systems.

quoted

After getting more information from hw team, for Agilex specific device,
the RGMII timing delays on this board are provided by an FPGA delay
chain (Input/Output Delay Chain primitives in the FPGA fabric). The
reason for using the FPGA rather than the PHY is that the Marvell PHY on
this board only supports 0ns or 2ns delay steps — too coarse to meet the
RGMII timing requirements. The FPGA delay chain provides up to 63 steps
of ~0.1ns precision, which the hardware team has tuned at design time to
achieve correct signal timing.

As the text says, fine tuning is different. You can have fine tuning,
in both the MAC or PHY, while using either rgmii or rgmii-id.

Also, you cannot fine tune just the MAC, tuning needs to take into
account the PCB design, the length of the clock and data tracks on the
PCB. You can however take into account the difference in timing within
the FPGA.

Or does your FPGA team produce a different bitstream per board design,
after some sort of calibration in order to determine what the PCB
characteristics are?

This however opens up a new possibility. It does sound like you can
produce a new bitstream with the delays set to just the tuning delay,
not the 2ns + tuning? You need to decide if this is simpler than
changing the MAC driver to mask the phy-mode.

quoted

Changing to phy-mode = "rgmii-id" and having
the driver strip the delay before passing to the PHY would produce the
same hardware behaviour (PHY adds zero delay), but would add driver
complexity with no practical benefit, and would misrepresent the FPGA
delay as a driver-managed MAC delay when it is actually a fixed,
board-level hardware calibration.

Look at the wording again. It does not say it is driver managed.

# There are a small number of cases where the MAC has hard coded
# delays which cannot be disabled.

This exactly fits your situation.

quoted

Could you advise if you still prefer the rgmii-id approach given this
constraint?

rgmii-id is the correct value for your PCB design. Please follow what
the text says.

	Andrew

	

Hi Andrew,

Sure, will reflect this changes in v2, Thanks for the review


BR,
Nazim