Hi Min, Russell, Krzysztof,

On 1/26/26 22:14, Min Lin wrote:

Hi Russell,

quoted

-----Original Messages-----
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Send time:Tuesday, 27/01/2026 02:29:09
To: "Min Lin" <linmin@eswincomputing.com>
Cc: "Bo Gan" <redacted>, "Andrew Lunn" <andrew@lunn.ch>, "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <redacted>, devicetree@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.com
Subject: Re: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control

On Mon, Jan 26, 2026 at 11:10:12AM +0800, Min Lin wrote:

quoted

Due to chip backend reasons, there is already a ~4-5ns skew between the RX
clock and data of the eth1 MAC controller inside the silicon.

Let's analyse this.

	TXC / RXC	TXC / RXC
Speed	Clock rate	Clock period
1G	125MHz		8ns
100M	25MHz		40ns
10M	2.5MHz		400ns

The required skew for TXC and RXC at the receiver is specified to be
between 1 and 2.6ns irrespective of the speed. The edge of the clock
is also important: the rising edge indicates the lower 4 bits, and
the falling edge indicates the upper 4 bits.

At 1G speed, with a "4 to 5ns" skew in the chip. If this is accurate,
then inverting the clock and adding 1ns of additional skew by some
means (PCB trace, or at the MAC or PHY) will give the required clock
at the receiver.

Yes, that's exactly the case.

quoted

The timing table in the RGMII standard (3.3) allows for Tcyc (the
clock rate) to be scaled, but there is no allowance for scaling
TskewR (the required 1 to 2.6ns skew.) This skew parameter is
fixed.

So, at the other speeds, you are completely unable to meet the timing
specification, whether irrespective of the clock inversion. In effect,
the only speed that you can meet the specification is 1G.

The timing table in the RGMII standard(3.3) says the max value of Tskew
for 10/100 is unspecified.
Quotation:"note1: ...,For 10/100 the Max value is unspecified."

I think for 10/100, the "4 to 5ns" skew in the chip doesn't break the
standard. At 10/100 speeds, it meets the timing specification without
having to to add clock inversion.
In practice, it works at 10/100 speeds in the rgmii-id phy mode.

quoted

Thus, I think this is something that needs a lot more than just "do
we need to invert the clock". You also need to prevent 10M and 100M
being supported IMHO.

Regards,
Lin Min

I had an offline discussion with Yao Zi and others regarding this. We feel
like the proper way for ESWIN to deal with this broken eth1 is to have a
different compatible string just for eth1, where it can be associated with
platform data with quirks to do eswin,rx-clk-invert at 1G. The property is
therefore not required to be exposed in DT. (Pretend it conforms to spec
for 1G). Need confirmation for 10M/100M, though. I double checked Lin Min's
claim, and indeed the spec says "For 10/100 the Max value is unspecified":
https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/20655/1/RGMIIv2_0_final_hp.pdf

Thoughts?

Bo