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:43:14PM +0800, Icenowy Zheng wrote:
> 在 2025-06-13星期五的 09:35 +0100，Russell King (Oracle)写道：
> > 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.
> 
> Sigh, my experience is that the only thing I can get is some magic
> numbers from HW vendor... *facepalm*

I may have missed it if you've given the details, but tell us what
information you have, what the capabilities of the hardware is, and
we should be able to make suggestions.

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