From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
netdev@vger.kernel.org, Sascha Hauer <s.hauer@pengutronix.de>,
linux-kernel@vger.kernel.org,
Philippe Schenker <philippe.schenker@toradex.com>,
linux-imx@nxp.com, kernel@pengutronix.de,
David Jander <david@protonic.nl>, Shawn Guo <shawnguo@kernel.org>,
Fabio Estevam <festevam@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH v1 5/7] ARM i.MX6q: remove Atheros AR8035 SmartEEE fixup
Date: Mon, 8 Feb 2021 14:21:09 +0000 [thread overview]
Message-ID: <20210208142107.GJ1463@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210208092038.cjmnycyctsapgy7w@pengutronix.de>
On Mon, Feb 08, 2021 at 10:20:38AM +0100, Oleksij Rempel wrote:
> On Wed, Feb 03, 2021 at 09:56:28AM +0000, Russell King - ARM Linux admin wrote:
> > That is the historical fix for this problem, but there is a better
> > solution now in net-next - configuring the Tw parameter for gigabit
> > connections. That solves the random link drop issue when EEE is
> > enabled.
>
> Do you mean this properties?
> qca,smarteee-tw-us-1g
> qca,smarteee-tw-us-100m
>
> Do you have some recommendations, which values can be here used? Are
> they same for all MACs? Or, can we calculate this values automatically?
I don't think there's a way to "calculate" them.
The AR8035 default is 17us for 1G and 23us for 100M. Increasing the
1G Tw to 26us or 27us fixes it on several different Solidrun platforms
(iMX6 Hummingboards and Cubox-i, and LX2160A based). The boards all
have differing layouts, so I don't think it's layout or SoC specific
(which is good news.)
These figures have been arrived at by repetitive long-term testing and
observing whether there are sporadic link drops over these platforms.
> Beside, I have seen this patch: "ARM: dts: imx6qdl-sr-som: fix some
> cubox-i platforms"
That's for a different problem: moving these settings to DT broke
some Cubox-i platforms because of the weird ways that the AR8035
configures the address bits, using the LED pin. Tying a LED to the
LED pin is not sufficient to guarantee that a board always configures
the PHY to a particular address, so it can appear on address 0 or 4
depending on noise, temperature, supply voltage, and PHY chip
thresholds.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2021-02-08 14:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 9:18 [PATCH v1 0/7] remove different PHY fixups Oleksij Rempel
2021-02-03 9:18 ` [PATCH v1 1/7] ARM i.MX6q: remove PHY fixup for KSZ9031 Oleksij Rempel
2021-02-03 10:24 ` Philippe Schenker
2021-02-03 9:18 ` [PATCH v1 2/7] ARM i.MX6q: remove TX clock delay of ar8031_phy_fixup() Oleksij Rempel
2021-02-03 9:18 ` [PATCH v1 3/7] ARM i.MX6q: remove hand crafted PHY power up in ar8035_phy_fixup() Oleksij Rempel
2021-02-03 9:18 ` [PATCH v1 4/7] ARM i.MX6q: remove clk-out fixup for the Atheros AR8031 and AR8035 PHYs Oleksij Rempel
2021-02-03 9:18 ` [PATCH v1 5/7] ARM i.MX6q: remove Atheros AR8035 SmartEEE fixup Oleksij Rempel
2021-02-03 9:56 ` Russell King - ARM Linux admin
2021-02-08 9:20 ` Oleksij Rempel
2021-02-08 14:21 ` Russell King - ARM Linux admin [this message]
2021-02-03 9:18 ` [PATCH v1 6/7] ARM: imx6sx: remove Atheros AR8031 PHY fixup Oleksij Rempel
2021-02-03 9:18 ` [PATCH v1 7/7] ARM: imx7d: " Oleksij Rempel
2021-02-03 9:28 ` [PATCH v1 0/7] remove different PHY fixups Russell King - ARM Linux admin
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=20210208142107.GJ1463@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=david@protonic.nl \
--cc=f.fainelli@gmail.com \
--cc=festevam@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=philippe.schenker@toradex.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@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).