[PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K

[Andrew Lunn]

> > > Rockchip by default do bad things with RGMII delays.
> > > 
> > >  tx_delay:
> > >    description: Delay value for TXD timing.
> > >    $ref: /schemas/types.yaml#/definitions/uint32
> > >    minimum: 0
> > >    maximum: 0x7F
> > >    default: 0x30
> > > 
> > >  rx_delay:
> > >    description: Delay value for RXD timing.
> > >    $ref: /schemas/types.yaml#/definitions/uint32
> > >    minimum: 0
> > >    maximum: 0x7F
> > >    default: 0x10
> > > 
> > > Try setting both of these to 0. And then use 'rgmii-id'.
> > > 
> > >    Andrew  
> Setting both gmac0 and gmac1 to phy-mode=rgmii-id with tx/rx delay set to
> <0x0> yields about a 7x improvement from ~6 Mbs (with phy-mode=rgmii-id and
> tx/rx delay unset) to about 43 Mbps, which is still well below the ~950 Mbs
> with phy-mode=rgmii and tx/rx delay unset.

You need to split the problem into two. Rx delays and Tx delays. Use
something like iperf in UDP mode, to send a stream of UDP packets, or
receive a stream of UDP packets. TCP is bad for this sort of testing
because Rx and Tx are interconnected due to flow control and
retransmissions.

Try small values of rx_delay to see if you can improve the Rx
performance. Try small values to tx_delay, to see if you can improve
the Tx performance.

One problem we have with rx_delay and tx_delay is that they are
magic. We have no idea what they mean. The RGMII standard says there
should be a 2ns delay between data and clock. A poorly designed board
could mean the MAC/PHY pair needs to insert say 1.8ns or 2.2ns, not
2ns as defined by the RGMiI standard. Rockchip also seem to encourage
using rx_delay and tx_delay, so i would not be surprised to find
Rockchip boards are often poorly designed and don't follow the RGMII
standard.

rx_delay/tx_delay can probably insert 0.2ns of delay, but it probably
cannot insert -0.2ns of delay. So it could be, you cannot improve
it. If that is the case, we need to consider another solution.

   Andrew