From: Alexandre TORGUE <alexandre.torgue@foss.st.com>
To: Marek Vasut <marex@denx.de>, <linux-arm-kernel@lists.infradead.org>
Cc: Alexandre Torgue <alexandre.torgue@st.com>,
Patrice Chotard <patrice.chotard@st.com>,
Patrick Delaunay <patrick.delaunay@st.com>,
<linux-stm32@st-md-mailman.stormreply.com>
Subject: Re: [PATCH] ARM: dts: stm32: Rework LAN8710Ai PHY reset on DHCOM SoM
Date: Tue, 1 Jun 2021 08:50:44 +0200 [thread overview]
Message-ID: <bcac89b7-bcb8-0b84-3a42-0f93be89bd7d@foss.st.com> (raw)
In-Reply-To: <20210408230001.310215-1-marex@denx.de>
On 4/9/21 1:00 AM, Marek Vasut wrote:
> The Microchip LAN8710Ai PHY requires XTAL1/CLKIN external clock to be
> enabled when the nRST is toggled according to datasheet Microchip
> LAN8710A/LAN8710Ai DS00002164B page 35 section 3.8.5.1 Hardware Reset:
> "
> A Hardware reset is asserted by driving the nRST input pin low. When
> driven, nRST should be held low for the minimum time detailed in
> Section 5.5.3, "Power-On nRST & Configuration Strap Timing," on page
> 59 to ensure a proper transceiver reset. During a Hardware reset, an
> external clock must be supplied to the XTAL1/CLKIN signal.
> "
> This is accidentally fulfilled in the current setup, where ETHCK_K is used
> to supply both PHY XTAL1/CLKIN and is also fed back through eth_clk_fb to
> supply ETHRX clock of the DWMAC. Hence, the DWMAC enables ETHRX clock,
> that has ETHCK_K as parent, so ETHCK_K clock are also enabled, and then
> the PHY reset toggles.
>
> However, this is not always the case, e.g. in case the PHY XTAL1/CLKIN
> clock are supplied by some other clock source than ETHCK_K or in case
> ETHRX clock are not supplied by ETHCK_K. In the later case, ETHCK_K would
> be kept disabled, while ETHRX clock would be enabled, so the PHY would
> not be receiving XTAL1/CLKIN clock and the reset would fail.
>
> Improve the DT by adding the PHY clock phandle into the PHY node, which
> then also requires moving the PHY reset GPIO specifier in the same place
> and that then also requires correct PHY reset GPIO timing, so add that
> too.
>
> A brief note regarding the timing, the datasheet says the reset should
> stay asserted for at least 100uS and software should wait at least 200nS
> after deassertion. Set both delays to 500uS which should be plenty.
>
> Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board")
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: linux-stm32@st-md-mailman.stormreply.com
> To: linux-arm-kernel@lists.infradead.org
> ---
> arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
> index 272a1a67a9ad..31d08423a32f 100644
> --- a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
> @@ -123,7 +123,6 @@ ðernet0 {
> max-speed = <100>;
> phy-handle = <&phy0>;
> st,eth-ref-clk-sel;
> - phy-reset-gpios = <&gpioh 3 GPIO_ACTIVE_LOW>;
>
> mdio0 {
> #address-cells = <1>;
> @@ -132,6 +131,13 @@ mdio0 {
>
> phy0: ethernet-phy@1 {
> reg = <1>;
> + /* LAN8710Ai */
> + compatible = "ethernet-phy-id0007.c0f0",
> + "ethernet-phy-ieee802.3-c22";
> + clocks = <&rcc ETHCK_K>;
> + reset-gpios = <&gpioh 3 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <500>;
> + reset-deassert-us = <500>;
> interrupt-parent = <&gpioi>;
> interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> };
>
Applied on stm32-next.
Thanks.
Alex
_______________________________________________
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:[~2021-06-01 6:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 23:00 [PATCH] ARM: dts: stm32: Rework LAN8710Ai PHY reset on DHCOM SoM Marek Vasut
2021-06-01 6:50 ` Alexandre TORGUE [this message]
2021-06-28 10:44 ` Marek Vasut
2021-06-28 12:29 ` Greg KH
2021-06-28 12:32 ` Marek Vasut
2021-06-28 13:02 ` Greg KH
2021-06-28 13:10 ` Marek Vasut
2021-06-28 13:38 ` Greg KH
2021-06-28 13:58 ` Marek Vasut
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=bcac89b7-bcb8-0b84-3a42-0f93be89bd7d@foss.st.com \
--to=alexandre.torgue@foss.st.com \
--cc=alexandre.torgue@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=marex@denx.de \
--cc=patrice.chotard@st.com \
--cc=patrick.delaunay@st.com \
/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).