Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

[Andrew Lunn <andrew@lunn.ch>]

> >> 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.

> 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.

> 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.

> 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