On 2024-12-09 11:13, Andrew Lunn wrote:
On Mon, Dec 09, 2024 at 10:11:23AM +0800, Yijie Yang wrote:
On 2024-11-29 23:29, Andrew Lunn wrote:
I was mistaken earlier; it is actually the EMAC that will introduce a time
skew by shifting the phase of the clock in 'rgmii' mode.
This is fine, but not the normal way we do this. The Linux preference
is that the PHY adds the delays. There are a few exceptions, boards
which have PHYs which cannot add delays. In that case the MAC adds the
delays. But this is pretty unusual.
After testing, it has been observed that modes other than 'rgmii' do not
function properly due to the current configuration sequence in the driver
code.
O.K, so now you need to find out why.
It not working probably suggests you are adding double delays, both in
the MAC and the PHY. Where the PHY driver add delays is generally easy
to see in the code. Just search for PHY_INTERFACE_MODE_RGMII_ID. For
the MAC driver you probably need to read the datasheet and find
registers which control the delay.
As previously mentioned, using 'rgmii' will enable EMAC to provide the
delay while disabling the delay for EPHY. So there's won't be double delay.
Additionally, the current implementation of the QCOM driver code
exclusively supports this mode, with the entire initialization sequence
of EMAC designed and fixed for this specific mode.
Therefore, no other options are available until changes are made to the
driver.
If you decided you want to be unusual and have the MAC add the delays,
it should not be hard coded. You need to look at phy-mode. Only add
Are you suggesting that 'rgmii' indicates the delay is introduced by the
board rather than the EMAC?
Yes.
But according to the
Documentation/devicetree/bindings/net/ethernet-controller.yaml, this mode
explicitly states that 'RX and TX delays are added by the MAC when
required'. That is indeed my preference.
You need to be careful with context. If the board is not adding
delays, and you pass PHY_INTERFACE_MODE_RGMII to the PHY, the MAC must
be adding the delays, otherwise there will not be any delays, and it
will not work.
I'm not sure if there's a disagreement about the definition or a
misunderstanding with other vendors. From my understanding, 'rgmii'
should not imply that the delay must be provided by the board, based on
both the definition in the dt-binding file and the implementations by
other EMAC vendors. Most EMAC drivers provide the delay in this mode.
I confirmed that there is no delay on the qcs615-ride board., and the
QCOM EMAC driver will adds the delay by shifting the clock after
receiving PHY_INTERFACE_MODE_RGMII.
delays for rgmii-id. And you then need to mask the value passed to the
PHY, pass PHY_INTERFACE_MODE_RGMII, not PHY_INTERFACE_MODE_RGMII_ID,
so the PHY does not add delays as well.
Andrew
--
Best Regards,
Yijie
