From: Andrew Lunn <andrew@lunn.ch>
To: Biao Huang <biao.huang@mediatek.com>
Cc: AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Richard Cochran <richardcochran@gmail.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
macpaul.lin@mediatek.com
Subject: Re: [PATCH v5 1/2] stmmac: dwmac-mediatek: enable 2ns delay only for special cases
Date: Fri, 23 Dec 2022 15:18:39 +0100 [thread overview]
Message-ID: <Y6W4vwJHG+6PI8fd@lunn.ch> (raw)
In-Reply-To: <20221223015029.24978-2-biao.huang@mediatek.com>
On Fri, Dec 23, 2022 at 09:50:28AM +0800, Biao Huang wrote:
> In current driver, MAC will always enable 2ns delay in RGMII mode,
> but that will lead to transmission failures for "rgmii-id"/"rgmii-txid"
> cases.
>
> Modify the implementation of fix_mac_speed() to ensure the 2ns delay
> will only take effect for "rgmii-rxid"/"rgmii" cases, then user can
> choose phy-mode freely.
This does not seem correct. There are three ways the delays can be added:
1) The MAC
2) The PHY
3) Extra long lines on the board.
What the four RGMII modes tell you is what is needed in addition to
whatever the board provides. So it describes the combination of 1) and
2). Your board does not appear to be applying any delays, so you
should be using rgmii-id.
The MAC and PHY driver then need to decide how to add these delays,
and in most cases, the MAC does nothing, and passes phy-mode to the
PHY and the PHY adds the delay.
The MAC can add delays, but if it does, it need to mask out the delays
it added to the value passed to the PHY. Otherwise the PHY will add
the delay as well.
>
> - if ((phy_interface_mode_is_rgmii(priv_plat->phy_mode))) {
> + switch (priv_plat->phy_mode) {
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> /* prefer 2ns fixed delay which is controlled by TXC_PHASE_CTRL,
> * when link speed is 1Gbps with RGMII interface,
> * Fall back to delay macro circuit for 10/100Mbps link speed.
So this is wrong. PHY_INTERFACE_MODE_RGMII means the board is adding
the delay via long lines. You should not be added any delay at all.
For PHY_INTERFACE_MODE_RGMII_RXID, you need to mask the RXID bit from
phy_mode when connecting the MAC to the PHY. Otherwise the PHY is
going to add this delay as well.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-23 14:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-23 1:50 [PATCH v5 0/2] arm64: dts: mt8195: Add Ethernet controller Biao Huang
2022-12-23 1:50 ` [PATCH v5 1/2] stmmac: dwmac-mediatek: enable 2ns delay only for special cases Biao Huang
2022-12-23 9:24 ` AngeloGioacchino Del Regno
2022-12-23 14:18 ` Andrew Lunn [this message]
2022-12-26 3:50 ` Biao Huang (黄彪)
2022-12-26 15:19 ` Andrew Lunn
2022-12-27 7:09 ` Biao Huang (黄彪)
2022-12-27 16:20 ` Andrew Lunn
2022-12-28 6:22 ` Biao Huang (黄彪)
2022-12-28 16:00 ` Andrew Lunn
2022-12-29 0:37 ` Biao Huang (黄彪)
2022-12-23 1:50 ` [PATCH v5 2/2] arm64: dts: mt8195: Add Ethernet controller Biao Huang
2022-12-23 9:24 ` AngeloGioacchino Del Regno
2022-12-28 6:23 ` Biao Huang (黄彪)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y6W4vwJHG+6PI8fd@lunn.ch \
--to=andrew@lunn.ch \
--cc=alexandre.torgue@foss.st.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=biao.huang@mediatek.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=macpaul.lin@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=pabeni@redhat.com \
--cc=peppe.cavallaro@st.com \
--cc=richardcochran@gmail.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).