| Message ID | 20210422040914.47788-6-ilya.lipnitskiy@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mtk_eth_soc: fixes and performance improvements | expand |
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
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
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 --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)