Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add informative text about RGMII delays

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Fri, Jun 13, 2025 at 04:01:37PM +0800, Icenowy Zheng wrote:
> 在 2025-06-11星期三的 17:28 +0200，Andrew Lunn写道：
> > > Well in fact I have an additional question: when the MAC has any
> > > extra
> > > [tr]x-internal-delay-ps property, what's the threshold of MAC
> > > triggering patching phy mode? (The property might be only used for
> > > a
> > > slight a few hundred ps delay for tweak instead of the full 2ns
> > > one)
> > 
> > Maybe you should read the text.
> > 
> > The text says:
> > 
> >   In the MAC node, the Device Tree properties 'rx-internal-delay-ps'
> >   and 'tx-internal-delay-ps' should be used to indicate fine tuning
> >   performed by the MAC. The values expected here are small. A value
> > of
> >   2000ps, i.e 2ns, and a phy-mode of 'rgmii' will not be accepted by
> >   Reviewers.
> > 
> > So a few hundred ps delay is fine. The MAC is not providing the 2ns
> > delay, the PHY needs to do that, so you don't mask the value.
> 
> Thus if the MAC delay is set to 1xxx ps (e.g. 1800ps), should the MAC
> do the masking?
> 
> What should be the threshold? 1ns?

Why should there be a "threshold" ? It's really a case by case issue
where the capabilities of the hardware need to be provided and
considered before a decision can be made.

In order to first understand this, one needs to understand the
requirements of RGMII. RGMII v1.3 states:

Symbol	Parameter		Min	Typ	Max	Units
TskewT	Data to Clock output	-500	0	500	ps
	skew at clock tx
TskewR	Data to Clock input	1		2.6	ns
	skew at clock rx

The RGMII specification is written based upon the clock transmitter
and receiver having no built-in delays, and the delay is achieved
purely by trace routing. So, where delays are provided by the
transmitter or receiver (whether that's the MAC or the PHY depends
on whether TXC or RXC is being examined) these figures need to be
thought about.

However, the range for the delay at the receiver is -1ns to +0.6ns.

In your example, you're talking about needing a 1800ps delay. I
would suggest that, *assuming the PCB tracks introduce a 200ps skew
between the data and clock*, then using the PHY's built-in 2ns delay
is perfectly within the requirements of the RGMII specification.

That bit "assuming" is where the discussion needs to happen, and why
it would be case by case. If the skew due to trace routing were
800ps, then enabling the PHY's built-in 2ns delay would take the
delay out of spec.

Thrown into this would also be temperature effects, so trying to get
to as near as the 2ns delay as possible is probably a good idea.

Lastly, there's the question whether the software engineer even
knows what the skew provided by the hardware actually is.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!