Message-ID: <9922727607de39da7ed75d1edaf1873147e26336.camel@icenowy.me>
Date: Fri, 13 Jun 2025 16:43:14 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Rob Herring <robh@...nel.org>, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Chaoyi Chen <chaoyi.chen@...k-chips.com>,
 Matthias Schiffer <matthias.schiffer@...tq-group.com>, Heiner Kallweit
 <hkallweit1@...il.com>,  netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add
 informative text about RGMII delays

在 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*

> 

Powered by blists - more mailing lists