diff mbox series

[net-next,05/14] net: ethernet: mtk_eth_soc: reduce MDIO bus access latency

Message ID 20210422040914.47788-6-ilya.lipnitskiy@gmail.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series mtk_eth_soc: fixes and performance improvements | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net-next
netdev/subject_prefix success Link
netdev/cc_maintainers success CCed 10 of 10 maintainers
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 34 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link

Commit Message

Ilya Lipnitskiy April 22, 2021, 4:09 a.m. UTC 
From: Felix Fietkau <nbd@nbd.name>

usleep_range often ends up sleeping much longer than the 10-20us provided
as a range here. This causes significant latency in mdio bus acceses,
which easily adds multiple seconds to the boot time on MT7621 when polling
DSA slave ports.

Use udelay via readx_poll_timeout_atomic, since the MDIO access does not
take much time

Signed-off-by: Felix Fietkau <nbd@nbd.name>
[Ilya: use readx_poll_timeout_atomic instead of cond_resched]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 18 ++++++++----------
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  2 +-
 2 files changed, 9 insertions(+), 11 deletions(-)

Comments

Andrew Lunn April 22, 2021, 12:18 p.m. UTC | #1 
On Wed, Apr 21, 2021 at 09:09:05PM -0700, Ilya Lipnitskiy wrote:
> From: Felix Fietkau <nbd@nbd.name>
> 
> usleep_range often ends up sleeping much longer than the 10-20us provided
> as a range here. This causes significant latency in mdio bus acceses,

I found the same with the FEC driver, and make the same change.

> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> [Ilya: use readx_poll_timeout_atomic instead of cond_resched]
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>


Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew
Felix Fietkau April 22, 2021, 12:33 p.m. UTC | #2 
On 2021-04-22 06:09, Ilya Lipnitskiy wrote:
> From: Felix Fietkau <nbd@nbd.name>
> 
> usleep_range often ends up sleeping much longer than the 10-20us provided
> as a range here. This causes significant latency in mdio bus acceses,
> which easily adds multiple seconds to the boot time on MT7621 when polling
> DSA slave ports.
> 
> Use udelay via readx_poll_timeout_atomic, since the MDIO access does not
> take much time
> 
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> [Ilya: use readx_poll_timeout_atomic instead of cond_resched]
I still prefer the cond_resched() variant. On a fully loaded system, I'd
prefer to let the MDIO access take longer instead of wasting cycles on
udelay.

- Felix
Ilya Lipnitskiy April 23, 2021, 4:16 a.m. UTC | #3 
On Thu, Apr 22, 2021 at 5:33 AM Felix Fietkau <nbd@nbd.name> wrote:
>
>
> On 2021-04-22 06:09, Ilya Lipnitskiy wrote:
> > From: Felix Fietkau <nbd@nbd.name>
> >
> > usleep_range often ends up sleeping much longer than the 10-20us provided
> > as a range here. This causes significant latency in mdio bus acceses,
> > which easily adds multiple seconds to the boot time on MT7621 when polling
> > DSA slave ports.
> >
> > Use udelay via readx_poll_timeout_atomic, since the MDIO access does not
> > take much time
> >
> > Signed-off-by: Felix Fietkau <nbd@nbd.name>
> > [Ilya: use readx_poll_timeout_atomic instead of cond_resched]
> I still prefer the cond_resched() variant.
No problem, I will respin with your original change. Looks like we
can't take advantage of iopoll.h routine in this case, but that's not
the end of the world!

> On a fully loaded system, I'd
> prefer to let the MDIO access take longer instead of wasting cycles on
> udelay.
>
> - Felix

Ilya
diff mbox series

Patch

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 5cf64de3ddf8..a3958e99a29f 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -79,18 +79,16 @@  static u32 mtk_m32(struct mtk_eth *eth, u32 mask, u32 set, unsigned reg)
 
 static int mtk_mdio_busy_wait(struct mtk_eth *eth)
 {
-	unsigned long t_start = jiffies;
+	int ret;
+	u32 val;
 
-	while (1) {
-		if (!(mtk_r32(eth, MTK_PHY_IAC) & PHY_IAC_ACCESS))
-			return 0;
-		if (time_after(jiffies, t_start + PHY_IAC_TIMEOUT))
-			break;
-		usleep_range(10, 20);
-	}
+	ret = readx_poll_timeout_atomic(__raw_readl, eth->base + MTK_PHY_IAC,
+					val, !(val & PHY_IAC_ACCESS),
+					5, PHY_IAC_TIMEOUT_US);
+	if (ret)
+		dev_err(eth->dev, "mdio: MDIO timeout\n");
 
-	dev_err(eth->dev, "mdio: MDIO timeout\n");
-	return -1;
+	return ret;
 }
 
 static u32 _mtk_mdio_write(struct mtk_eth *eth, u32 phy_addr,
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 875e67b41561..989342a7ae4a 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -327,7 +327,7 @@ 
 #define PHY_IAC_START		BIT(16)
 #define PHY_IAC_ADDR_SHIFT	20
 #define PHY_IAC_REG_SHIFT	25
-#define PHY_IAC_TIMEOUT		HZ
+#define PHY_IAC_TIMEOUT_US	1000000
 
 #define MTK_MAC_MISC		0x1000c
 #define MTK_MUX_TO_ESW		BIT(0)