All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: ext Tony Lindgren <tony@atomide.com>,
	Siddharth Vadapalli <s-vadapalli@ti.com>,
	"open list:TI ETHERNET SWITCH DRIVER (CPSW)"
	<linux-omap@vger.kernel.org>, netdev <netdev@vger.kernel.org>,
	Matti Vaittinen <mazziesaccount@gmail.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: BeagleBone Black Ethernet PHY issues
Date: Thu, 31 Oct 2024 11:06:50 +0200	[thread overview]
Message-ID: <cd120c6b-e469-46d9-95b5-71a8cc6513cf@kernel.org> (raw)
In-Reply-To: <CAMuHMdVN_xNLTvy9u6FvK=agSAUzSHxEuyBS37sOA7jpGLwddw@mail.gmail.com>



On 30/10/2024 17:08, Geert Uytterhoeven wrote:
> Hi Roger,
> 
> On Wed, Oct 30, 2024 at 1:58 PM Roger Quadros <rogerq@kernel.org> wrote:
>> On 29/10/2024 19:18, Geert Uytterhoeven wrote:
>>> During the last few months, booting kernels on BeagleBone Black
>>> sometimes fails with:
>>>
>>>     +SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
>>> LAN8710/LAN8720 failed with error -5
> 
> [...]
> 
>> Just wondering if the Reset is happening correctly and it has settled
>> before PHY access.
>>
>> From arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
>>
>> &davinci_mdio_sw {
>>         pinctrl-names = "default", "sleep";
>>         pinctrl-0 = <&davinci_mdio_default>;
>>         pinctrl-1 = <&davinci_mdio_sleep>;
>>
>>         ethphy0: ethernet-phy@0 {
>>                 reg = <0>;
>>                 /* Support GPIO reset on revision C3 boards */
>>                 reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
>>                 reset-assert-us = <300>;
>>                 reset-deassert-us = <13000>;
>>         };
>> };
>>
>> Do we need to increase reset-deassert-us for some reason?
> 
> Thanks for the hint!
> 
> This is indeed on Rev. C3 (my other boards are Rev. A5C or C, but
> I don't test boot recent kernels on them, as they are in active use).
> 
> Multiplying reset-deassert-us by 10 gives me a booting board.
> More experiments reveal that I need a delay of 14 ms to boot
> successfully, and 15 ms to avoid the early __mdiobus_read()
> failure, too.
> 
>> I couldn't find MII ready time after reset de-assert information form the
>> PHY datasheet. except the following line [1].
>> "For the first 16us after coming out of reset, the MII/RMII interface will run at 2.5 MHz. After this time, it will
>> switch to 25 MHz if auto-negotiation is enabled"
>>
>> [1] 3.8.5 RESETS
>> https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN8710A-LAN8710Ai-Data-Sheet-DS00002164.pdf
> 
> 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.6.3, "Power-On nRST & Configuration Strap Timing," on page
>  60 to ensure a proper transceiver reset."
> 
> 5.6.3 POWER-ON NRST & CONFIGURATION STRAP TIMING
> "For proper operation, nRST must be asserted for no less than trstia."
> 
> TABLE 5-8: POWER-ON NRST & CONFIGURATION STRAP TIMING VALUES
> "trstia nRST input assertion time min. 100 µS"
> 
> On Rev. C3, ETH_RESETn is controlled by an open-drain AND gate.
> It is pulled high by a 10K resistor, and has a 4.7µF capacitor to
> ground.  That gives an RC constant of 47ms.  As you need 0.7RC to charge
> the capacitor above the threshold voltage of a CMOS input (VDD/2),
> reset-deassert-us should be at least 33ms. Considering the typical
> tolerance of 20% on capacitors, 40ms would be safer. Or perhaps
> even 50ms?

Super! Yes, I agree 50ms would be a good setting.

> 
> If you agree, I can send a patch.
> Thanks!

Much appreciated, thanks!

-- 
cheers,
-roger


  reply	other threads:[~2024-10-31  9:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-29 17:18 BeagleBone Black Ethernet PHY issues Geert Uytterhoeven
2024-10-30 12:58 ` Roger Quadros
2024-10-30 15:08   ` Geert Uytterhoeven
2024-10-31  9:06     ` Roger Quadros [this message]
2024-10-31  9:30       ` Geert Uytterhoeven
2024-10-30 15:00 ` Robert Nelson
2024-10-30 15:17   ` Geert Uytterhoeven

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=cd120c6b-e469-46d9-95b5-71a8cc6513cf@kernel.org \
    --to=rogerq@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=s-vadapalli@ti.com \
    --cc=tony@atomide.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.