Message-ID: <2e518360-be24-45d8-914d-1045c6771620@quicinc.com>
Date: Tue, 10 Dec 2024 11:29:47 +0800
From: Yijie Yang <quic_yijiyang@...cinc.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Bjorn Andersson
	<andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        Richard Cochran <richardcochran@...il.com>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] arm64: dts: qcom: qcs615-ride: Enable ethernet
 node



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

Powered by blists - more mailing lists