[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8acf4557-ac10-43f1-b1ab-7ae63f64401f@lunn.ch>
Date: Tue, 17 Dec 2024 11:18:49 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Yijie Yang <quic_yijiyang@...cinc.com>
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 Tue, Dec 17, 2024 at 10:26:15AM +0800, Yijie Yang wrote:
>
>
> On 2024-12-16 17:18, Andrew Lunn wrote:
> > > I intend to follow these steps. Could you please check if they are correct?
> > > 1. Add a new flag in DTS to inform the MAC driver to include the delay when
> > > configured with 'rgmii-id'. Without this flag, the MAC driver will not be
> > > aware of the need for the delay.
> >
> > Why do you need this flag?
> >
> > If the phy-mode is rgmii-id, either the MAC or the PHY needs to add
> > the delay.
> >
> > The MAC driver gets to see phy-mode first. If it wants to add the
> > delay, it can, but it needs to mask out the delays before passing
> > phy-mode to the PHY. If the MAC driver does not want to add the
> > delays, pass phy-mode as is the PHY, and it will add the delays.
>
> In this scenario, the delay in 'rgmii-id' mode is currently introduced by
> the MAC as it is fixed in the driver code. How can we enable the PHY to add
> the delay in this mode in the future (If we intend to revert to the most
> common approach of the Linux kernel)? After all, the MAC driver is unsure
> when to add the delay.
You just take out the code in the MAC driver which adds the delay and
masks the phy-mode. 2ns should be 2ns delay, independent of who
inserts it. The only danger is, there might be some board uses a PHY
which is incapable of adding the 2ns delay, and such a change breaks
that board.
But i assume Qualcomm RDKs always make use of a Qualcomm PHY, there is
special pricing if you use the combination, so there is probably
little incentive to use somebody elses PHY. And i assume you can
quickly check all Qualcomm PHYs support RGMII delays. PHYs which don't
support RGMII delays are very rare, it just happened that one vendors
RDK happened to use one, so they ended up with delays in the MAC being
standard for their boards.
Andrew
Powered by blists - more mailing lists