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

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.

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.

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.

I can't get my head around why someone would come up with this crazy,
crippled design, but maybe they didn't bother reading the RGMII
specification and ensuring that their design met the requirements
before implementing the hardware.

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