Hi Andrew,
Thanks for the reply.
On 1/8/25 11:52, Andrew Lunn wrote:
Does the mac0 TX clock have an extra long clock line on the PCB?
Does the mac1 TX and RX clocks have extra long clock lines on the PCB?
Anything but rgmii-id is in most cases wrong, so you need a really
good explanation why you need to use something else. Something that
shows you understand what is going on, and why what you have is
correct.
Here I'll add some explanation.
In our design, we hope the TX and RX RGMII delay are configured by our MAC side.
We can control the TX/RX RGMII delay on MAC step by step, it is not a setting to delay to 2 ns.
We are not sure the all target PHYs are support for RX internal delay.
But ast2600 MAC1/2 delay cell cannot cover range to 2 ns, MAC 3/4 can do that.
Therefore, when using ast2600 MAC1/2, please enable the RX internal delay on the PHY side
to make up for the part we cannot cover.
Summarize our design and we recommend.
AST2600 MAC1/2: rgmii-rxid
(RGMII with internal RX delay provided by the PHY, the MAC should not add an RX delay in this
case)
AST2600 MAC3/4: rgmii
(RX and TX delays are added by the MAC when required)
rgmii and rgmii-rxid are referred from ethernet-controller.yaml file.
O.K, so you have the meaning of phy-mode wrong. phy-mode effectively
described the PCB. Does the PCB implement the 2ns delay via extra long
clock lines or not. If the PCB has long clock lines, phy-mode is
'rgmii'. If the PCB does not have long clock lines, 'rgmii-id' is
used, meaning either the MAC or the PHY needs to add the delays.
I checked with out hardware team and they did not add any extra delay on
the board.
We have normal point to point clock without any delay added by line.
Regards,
Ninad
The MAC driver is the one that reads the phy-mode from the DT, and
then it decides what to do. 95% of linux MAC drivers simply pass it
direct to the PHY. If the phy-mode is 'rgmii', the PHY does nothing,
because the PCB has added the delays. If it is rgmii-id, it adds
delays in both directions. This works, because nearly very RGMII PHY
on the market does support RGMII delays.
There is however a very small number of MAC drivers which do things
differently. Renesas produced an RDK with a PHY which could not do
delays in the PHY, and so were forced to do the delays in the
MAC. Please look at how the ravb driver works. If the PCB does not add
the delays, rmgii-id, the MAC driver adds the delays. It then masks
the phy-mode it passes to of_phy_connect() back to 'rgmii', so that
the PHY does not add any delays. If the PCB did add the delays,
'rgmii', the MAC driver does not add delays, and it passed rgmii to
the PHY driver, and it also does not add delays.
So, your MAC driver is broken. It is not correctly handling the
phy-mode. First question is, how many boards are there in mainline
which have broken phy-modes. If this is the first board, we can fix
the MAC driver. If there are already boards in mainline we have to be
much more careful when fixing this, so as not to regress boards which
are already merged.
Humm, interesting. Looking at ftgmac100.c, i don't see where you
configure the RGMII delays in the MAC?
Andrew
