> Do we need updates on this description. It doesn't talk about external PCB
> level delays?
>
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L77-L90
>
> This is what you explained:
>
> MAC driver reads following phy-mode from device tree. 95% of mac driver
> directly
> pass it to PHY through phy_connect.
>
> rgmii - PCB has long clock lines so delay is added by PCB
> On this mode PHY does nothing.
> rgmii-id - PCB doesn't add delay. Either MAC or PHY needs to add the delay
> Add delays in both directions. Some PHY may not add delay in that
> case MAC needs to add the delay mask rgmii-id to rgmii.
> rgmii-rxid - If there is an extra long TX clock line, but not RX clock,
> you would use rgmii-rxid
> rgmii-txid - When there is an extra long RX clock line on the PCB, but not
> the TX clock line, you would use rgmii-txid
The documentation is not great, that has been said a few times. What
is described here is the view from the PHY, which is not ideal.
# RX and TX delays are added by the MAC when required
- rgmii
>From the perspective of the PHY, this means it does not need to add
delays, because the MAC has added the delays, if required, e.g. the
PCB has not added the delays.
We have the problem that DT is supposed to describe the
hardware. Saying the PHY should add the delays, but if the MAC adds
the delays it needs to mask the value passed to the PHY does not
describe the hardware, it is Linix implementation details. The DT
Maintainers don't want that in the DT binding because other OSes might
decide to implement the details differently.
So your description becomes:
rgmii - PCB has long clock lines so delays are added by the PCB
rgmii-id - PCB doesn't add delay. Either MAC or PHY needs to add the delays
in both directions.
rgmii-rxid - There is an extra long TX clock line on the PCB, but not the RX
clock.
rgmii-txid - There is an extra long RX clock line on the PCB, but not the TX
clock.
It is correct, but leaves so much unsaid developers will still get it
wrong. What we really want is that developers:
1) Read the mailing list. Patches for RGMII delays are posted at least
once an month and i point out how they are wrong. If developers
actually read the mails, they would not make the same mistake again
and again.
2) Developers for some reason like to invent their own code, rather
than taking the easy route of copy from a driver already in Linux.
The majority of drivers in Linux get this right, so if you copy
another driver, you should get it right for free as well.
Andrew
_______________________________________________
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
