[PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control

[李志]

> -----原始邮件-----
> 发件人: "Andrew Lunn" <andrew at lunn.ch>
> 发送时间:2026-01-10 02:27:54 (星期六)
> 收件人: lizhi2 at eswincomputing.com
> 抄送: devicetree at vger.kernel.org, andrew+netdev at lunn.ch, davem at davemloft.net, edumazet at google.com, kuba at kernel.org, robh at kernel.org, krzk+dt at kernel.org, conor+dt at kernel.org, netdev at vger.kernel.org, pabeni at redhat.com, mcoquelin.stm32 at gmail.com, alexandre.torgue at foss.st.com, rmk+kernel at armlinux.org.uk, linux-stm32 at st-md-mailman.stormreply.com, linux-arm-kernel at lists.infradead.org, linux-kernel at vger.kernel.org, ningyu at eswincomputing.com, linmin at eswincomputing.com, pinkesh.vaghela at einfochips.com, weishangjuan at eswincomputing.com
> 主题: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control
> 
> >    rx-internal-delay-ps:
> > -    enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> > +    enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
> >  
> >    tx-internal-delay-ps:
> > -    enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> > +    enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
> 
> You need to add some text to the Changelog to indicate why this is
> safe to do, and will not cause any regressions for DT blobs already in
> use. Backwards compatibility is very important and needs to be
> addressed.
> 
Thanks for the review.

Understood. Our understanding is that changing the allowed values of
rx-internal-delay-ps / tx-internal-delay-ps needs to be explicitly
justified as DT ABI safe.

For v2, we are planning to replace the enum with a min/max constraint.
These properties carry literal delay values in picoseconds, and all
previously valid values will remain valid and retain the same meaning.
Existing DT blobs will therefore continue to work unchanged.

We will also add explicit text to the commit message explaining why this
change is DT ABI safe and why no regressions are expected.

> > +  eswin,rx-clk-invert:
> > +    description:
> > +      Invert the receive clock sampling polarity at the MAC input.
> > +      This property may be used to compensate for SoC-specific
> > +      receive clock to data skew and help ensure correct RX data
> > +      sampling at high speed.
> > +    type: boolean
> 
> This does not make too much sense to me. The RGMII standard indicates
> sampling happens on both edges of the clock. The rising edge is for
> the lower 4 bits, the falling edge for the upper 4 bits. Flipping the
> polarity would only swap the nibbles around.
> 
You are correct about the RGMII specification. The intent of
eswin,rx-clk-invert is not to change the RGMII sampling rule, but to
compensate for SoC-internal RXC-to-RXD skew and restore the correct
sampling relationship at the MAC input.

On EIC7700, RXC and RXD experience an internal skew before reaching the
MAC. At high speed, this can shift the effective sampling point by
approximately half a cycle, causing the MAC to sample the wrong nibble
on each edge.

Conceptually, the situations are as follows.

RGMII-specified behavior (correct):

RXC:   __/‾‾\__/‾‾\__
         ↑  ↓      
         |  |      
         |  |      
         |  +--------- sample RXD[4:7]
         +------------ sample RXD[0:3]

SoC-internal skew causing incorrect sampling (without invert):

RXC:   __/‾‾\__/‾‾\__
         ↑  ↓      
         |  |      
         |  |      
         |  +--------- sample RXD[0:3]   (wrong)
         +------------ sample RXD[4:7]   (wrong)

After enabling internal RX clock invert:

RXC:   __/‾‾\__/‾‾\__
         ↑  ↓      
         |  |      
         |  |      
         |  +--------- sample RXD[4:7]   (correct)
         +------------ sample RXD[0:3]   (correct)

The invert control restores sampling of RXD[0:3] on the rising edge
and RXD[4:7] on the falling edge, exactly as defined by the RGMII
specification. No protocol-level behavior or edge assignment is
changed.

Thanks,
Li Zhi