On Sun, Apr 10, 2022 at 12:41 AM Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> wrote:
>
> Am 09.04.22 um 19:08 schrieb Trent Piepho:
> > On Sat, Apr 9, 2022 at 9:02 AM Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> wrote:>
> >>
> >> In this case driver will set some default values:
> >> priv->tx_delay = used cd;
> >> priv->rx_delay = 0x10;
> >>
> >> No idea what this values mean.
> >
> > They are supposed to be delays in picoseconds, but sometimes driver
> > authors are lazy and just use whatever goes into their device's
> > registers. That creates a dts binding that only works for one
> > specific device.
>
> According to RGMII 2.0 specification, delay should be 2.8 nanosecond or 2800 picoseconds. None of
> used raw values fits to the specified range.
As I understand it, there are also delays due to PCB signal routing
that might be significant enough that they need to be taken into
account too. Thus we have standard properties like:
rx-internal-delay-ps:
description: |
RGMII Receive Clock Delay defined in pico seconds.
This is used for controllers that have configurable RX internal delays.
If this property is present then the MAC applies the RX delay.
This is for the MAC delay, not the PHY delay, but you will notice that
it is in fact in picoseconds. If the value was always 2.8 ns, then it
could just be boolean property to enable the delay. But it's not,
because the delay is not always the same value for every board.
Some drivers will not use this property and will make up their own.
It will probably be whatever is written into the device registers.
Others might use vendor specific properties in picoseconds for some
reason known only to the author, e.g.:
mediatek,tx-delay-ps = <1530>;
You will notice in picroseconds and also not 2800.
When delay is controlled by the PHY, then there are properties like:
- rxc-skew-ps : Skew control of RXC pad
- txc-skew-ps : Skew control of TXC pad
Also in picoseconds. A search of existing device trees will show it
is not always 2800 either.
> Normally we use phy-mode with predefined values:
> - rgmii == tx/rx delay is 0
> - rgmii-id == PHY configures tx and rx delays to closest possible values to 2.8ns
> - rgmii-txid == PHY configures only tx delay to 2.8ns, rx is 0
> - rgmii-rxid == same as rgmii-txid but for rx.
>
> Using raw values or fine tuning this delays makes no sense in 99% cases.
I agree today, rgmii-id is the normal configuration and usually works
with no further modification.
For a new board design, I think running though the delay test is a
valuable part of validating the RGMII design of the board. Just
because the 20 prototype boards all work at room temperature does not
mean the million you make afterward will have a 0% failure rate over
the full spec temp range.
> As I already said, except of delays there can be other issue. For example:
> - incorrect pinmux configuration
> - incorrect RGMII clock source configuration
> - incorrect MAC or PHY mode configuration (xMII instead of RGMII)
> - incorrect reset or power up sequence affecting proper bootstrap configuration.
> - incorrect MDIO configuration, for example CLK rate outside of range supported by the PHY.
> - not properly configured SoCs internal clock dependencies.
> - some missing "enable" bit on the PHY or the MAC side
If all one knows is ethernet doesn't work, then I think all of those
problems above are more likely the problem than a need to fine tune
the RGMII delays.
> Even if you don't like the fact, that for most of this cases, scope will reduce dramatically
> investigation time. I'll need to repeat it, it will help to use the scope.
Where do get this idea that I do not like an oscilloscope? I use one
constantly. I do not own one that can measure the clk vs data delay
on RGMII to 100 ps precision. Do have one at work that can. But
rarely does a board have test points to do this anyway. Determining
if the various 25/50/125 MHz clocks are there is far more feasible.
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
