Re: RGMII timing calibration (on 12nm Amlogic SoCs) - integration into dwmac-meson8b

[Martin Blumenstingl]

Hi Andrew,

On Sat, Sep 26, 2020 at 12:14 AM Andrew Lunn <andrew@xxxxxxx> wrote:
>
> On Fri, Sep 25, 2020 at 11:47:18PM +0200, Martin Blumenstingl wrote:
> > Hello,
> >
> > Amlogic's 12nm SoC generation requires some RGMII timing calibration
> > within the Ethernet controller glue registers.
> > This calibration is only needed for the RGMII modes, not for the
> > (internal) RMII PHY.
> > With "incorrect" calibration settings Ethernet speeds up to 100Mbit/s
> > will still work fine, but no data is flowing on 1Gbit/s connections
> > (similar to when RX or TX delay settings are incorrect).
>
> Hi Martin
>
> Is this trying to detect the correct RGMII interface mode:
>         PHY_INTERFACE_MODE_RGMII,
>         PHY_INTERFACE_MODE_RGMII_ID,
>         PHY_INTERFACE_MODE_RGMII_RXID,
>         PHY_INTERFACE_MODE_RGMII_TXID,
>
> In general, we recommend the MAC does not insert any delay, we leave
> it up to the PHY. In DT, you then set the correct phy-mode value,
> which gets passed to the PHY when the MAC calls the connect function.
yes and no.
The reference code I linked tries to detect the RGMII interface mode.
However, for each board we know the phy-mode as well as the RX and TX
delay - so I'm not trying to port the RGMII interface detection part
to the mainline driver.

on X96 Air (which I'm using for testing) Amlogic configures phy-mode
"rgmii" with a 2ns TX delay provided by the MAC and 0ns RX delay
anywhere (so I'm assuming that the board adds the 2ns RX delay)
I am aware that the recommendation is to let the PHY generate the delay.
For now I'm trying to get the same configuration working which is used
by Amlogic's vendor kernel and u-boot.

> Is there any documentation as to what the calibration values mean?  I
> would just hard code it to whatever means 0uS delay, and be done. The
> only time the MAC needs to add delays is when the PHY is not capable
> of doing it, and generally, they all are.
This calibration is not the RGMII RX or TX delay - we have other
registers for that and already know how to program these.

This new calibration only exists on 12nm SoCs so I assume (but have no
proof) that they need to solve some challenge that comes with the
advanced node (previous SoCs were manufactured using a 28nm process).
In the old days the vendors put calibration data into the eFuse.
However I think for mass-production of cheap boards this is not nice
for the manufacturers (because they need this eFuse programming step).
So I think Amlogic added a calibration circuit to handle tolerances
within the SoC manufacturing as well as the "environment" of the SoC
(there are some TI SoCs where the MMC controller's clock calibration
depends on the SoC temperature for example. For these Amlogic SoCs I
don't know the factors that influence this calibration though - one
guess however is cost-cutting).

All of that said: I don't have any scope that's fast enough to see the
clock-skew on such high-speed signals so I cannot tell for sure what
problem they are solving.
What I can say is that u-boot programs calibration value 0xf (the
maximum value) on my X96 Air board. With this I cannot get Ethernet
working - regardless of how I change the RX or TX delays.
If I leave everything as-is (2ns TX delay generated by the MAC, 0ns RX
delay, ...) and change the calibration value to 0x0 or 0x3 (the latter
is set by the vendor kernel) then Ethernet starts working.


Best regards,
Martin