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

[Nazle Asmade, Muhammad Nazim Amirul]

On 3/7/2026 9:12 pm, Andrew Lunn wrote:
>>>> 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
> 
> 	
Hi Andrew,

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


BR,
Nazim