change r2pro dts to public hw version (was "Board code with 2 dts" )

Sun Apr 10 08:00:27 PDT 2022

Am 10.04.22 um 11:28 schrieb Trent Piepho:
> On Sun, Apr 10, 2022 at 12:41 AM Oleksij Rempel <linux at rempel-privat.de> wrote:
>>
>> Am 09.04.22 um 19:08 schrieb Trent Piepho:
>>> On Sat, Apr 9, 2022 at 9:02 AM Oleksij Rempel <linux at rempel-privat.de> 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>;

Just to make sure, we do not don't talk past each other. My point is: most of rgmii specific
information in many devicetree makes no sense. And here is my explanation...

I assume you used this example:
arch/arm64/boot/dts/mediatek/mt2712-evb.dts

Why not use more of it?

         phy-mode ="rgmii-rxid";
         mediatek,tx-delay-ps = <1530>;

         mdio {
                 ethernet_phy0: ethernet-phy at 5 {
                         compatible = "ethernet-phy-id0243.0d90";

First what we see is:
- rgmii-rxid is used, so PHY will configure RX delay to some value.
- tx delay is configured by the MAC.

So, we have two options:
1. board design is very special and all RGMII traces except of rxclk have same length and the length
is ~10cm longer then all other RGMII traces. This sounds as very special design and it sounds not so
realistic.
2. there is something special about PHY and/or MAC. this one is more realistic.

The PHY id is hard coded, so we can find the datasheet:
http://pdf.eepw.com.cn/i20090903/8d594ec98b62289dd0d3cd17fc8ffdd1.pdf
Page 46:
Ts3,
- if TXPHASE_SEL=0, then clock is shifted by -0.65 ns
- if TXPHASE_SEL=1, then clock is shifted by  1.35 ns

Td3
- if RXPHASE_SEL=0, then clock is shifted by  0,4 ns
- if RXPHASE_SEL=1, then clock is shifted by  2.4 ns

It means, if driver supports rgmii-id, the PHY configuration will be out of spec. 1.35 ns delay is
not enough. Ok, so designer has two options:
- combine two delays: rgmii-id + mediatek,tx-delay-ps. In this case by review I personally would
ask: why?!
- or rgmii-rxid + mediatek,tx-delay-ps
In any case, both options are OK.

So, why mediatek,tx-delay-ps = <1530>? 1.5 is not enough for RGMII.
In case of rgmii-rxid internal PHY clk skew will be -0.65 ns. Hard to say, if it is typo, but 1530 +
650ps will be 2180, which is enough for RGMII.

This make sense so far and confirms my claim: most of embedded boards have nearly equal RGMII traces
and there is no need for fine tuning. I doubt that that provided delay information is a good place
for the board specific device tree. The delay calculation could be solved between MAC and PHY
driver, in case both of them would provide needed information.

I can take apart many more dts files, but the result will be in most cases very similar. There is no
good reason to set this information in the devicetree and many developers are making mistakes by
copypasting it to other boards.

> 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.

Good point and it confirms my claim: this information should not be set in the devicetree, at least
not as delay. Instead we probably should use trace properties. It should be automatically calculated
by drivers and in your example, automatically compensated by the temperature. Especially if we are
talking about temperature range of -50 to 100C

>> 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.

ack.

--
Regards,
Oleksij