Hello,
This series aims at reducing the waiting time between MDIO transactions
when using the MSCC MIIM MDIO controller.
I'm not sure we need patch 4/4 and we could reasonably drop it from the
series. I'm including the patch as it could help to ensure the system
is functional with a non optimal configuration.
We needed to improve the driver's performances as when using a PHY
requiring lots of registers accesses (such as the VSC85xx family),
delays would add up and ended up to be quite large which would cause
issues such as: a slow initialization of the PHY, and issues when using
timestamping operations (this feature will be sent quite soon to the
mailing lists).
Thanks,
Antoine
Antoine Tenart (4):
net: phy: mscc-miim: use more reasonable delays
net: phy: mscc-miim: remove redundant timeout check
net: phy: mscc-miim: improve waiting logic
net: phy: mscc-miim: read poll when high resolution timers are
disabled
drivers/net/phy/Kconfig | 3 ++-
drivers/net/phy/mdio-mscc-miim.c | 33 +++++++++++++++++++++++++-------
2 files changed, 28 insertions(+), 8 deletions(-)
--
2.26.2
The driver uses a read polling mechanism to check the status of the MDIO
bus, to know if it is ready to accept next commands. This polling
mechanism uses usleep_delay() under the hood between reads which is fine
as long as high resolution timers are enabled. Otherwise the delays will
end up to be much longer than expected.
This patch fixes this by using udelay() under the hood when
CONFIG_HIGH_RES_TIMERS isn't enabled. This increases CPU usage.
Signed-off-by: Antoine Tenart <[email protected]>
---
drivers/net/phy/Kconfig | 3 ++-
drivers/net/phy/mdio-mscc-miim.c | 22 +++++++++++++++++-----
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 2a32f26ead0b..047c27087b10 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -184,7 +184,8 @@ config MDIO_MSCC_MIIM
depends on HAS_IOMEM
help
This driver supports the MIIM (MDIO) interface found in the network
- switches of the Microsemi SoCs
+ switches of the Microsemi SoCs; it is recommended to switch on
+ CONFIG_HIGH_RES_TIMERS
config MDIO_MVUSB
tristate "Marvell USB to MDIO Adapter"
diff --git a/drivers/net/phy/mdio-mscc-miim.c b/drivers/net/phy/mdio-mscc-miim.c
index aed9afa1e8f1..11f583fd4611 100644
--- a/drivers/net/phy/mdio-mscc-miim.c
+++ b/drivers/net/phy/mdio-mscc-miim.c
@@ -39,13 +39,25 @@ struct mscc_miim_dev {
void __iomem *phy_regs;
};
+/* When high resolution timers aren't built-in: we can't use usleep_range() as
+ * we would sleep way too long. Use udelay() instead.
+ */
+#define mscc_readl_poll_timeout(addr, val, cond, delay_us, timeout_us) \
+({ \
+ if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS)) \
+ readl_poll_timeout_atomic(addr, val, cond, delay_us, \
+ timeout_us); \
+ readl_poll_timeout(addr, val, cond, delay_us, timeout_us); \
+})
+
static int mscc_miim_wait_ready(struct mii_bus *bus)
{
struct mscc_miim_dev *miim = bus->priv;
u32 val;
- return readl_poll_timeout(miim->regs + MSCC_MIIM_REG_STATUS, val,
- !(val & MSCC_MIIM_STATUS_STAT_BUSY), 50, 10000);
+ return mscc_readl_poll_timeout(miim->regs + MSCC_MIIM_REG_STATUS, val,
+ !(val & MSCC_MIIM_STATUS_STAT_BUSY), 50,
+ 10000);
}
static int mscc_miim_wait_pending(struct mii_bus *bus)
@@ -53,9 +65,9 @@ static int mscc_miim_wait_pending(struct mii_bus *bus)
struct mscc_miim_dev *miim = bus->priv;
u32 val;
- return readl_poll_timeout(miim->regs + MSCC_MIIM_REG_STATUS, val,
- !(val & MSCC_MIIM_STATUS_STAT_PENDING),
- 50, 10000);
+ return mscc_readl_poll_timeout(miim->regs + MSCC_MIIM_REG_STATUS, val,
+ !(val & MSCC_MIIM_STATUS_STAT_PENDING),
+ 50, 10000);
}
static int mscc_miim_read(struct mii_bus *bus, int mii_id, int regnum)
--
2.26.2
On Tue, May 26, 2020 at 06:22:52PM +0200, Antoine Tenart wrote:
> Hello,
>
> This series aims at reducing the waiting time between MDIO transactions
> when using the MSCC MIIM MDIO controller.
Hi Antoine
There are a couple of other things you can look at:
Can you disable the pre-amble on the MDIO transaction. It requires
that both the bus master and all devices on the bus support it, but
when it is usable, you half the number of bits sent over the wire.
Can you control the frequency of MDC? 802.3 says 2.5MHz, but many
devices support higher speeds. Again, you need all devices on the bus
to support the speed.
When accessing raw TDR data for cable tests i also have a lot of PHY
accesses. I implemented both of these for the FEC MDIO bus, and made
it a lot faster.
Andrew
On 5/26/2020 3:01 PM, Andrew Lunn wrote:
>>> +/* When high resolution timers aren't built-in: we can't use usleep_range() as
>>> + * we would sleep way too long. Use udelay() instead.
>>> + */
>>> +#define mscc_readl_poll_timeout(addr, val, cond, delay_us, timeout_us) \
>>> +({ \
>>> + if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS)) \
>>> + readl_poll_timeout_atomic(addr, val, cond, delay_us, \
>>> + timeout_us); \
>>> + readl_poll_timeout(addr, val, cond, delay_us, timeout_us); \
>>> +})
>>> +
>>
>> I would make this a regular function which would not harm the compiler's
>> ability to optimize it, but would give you type checking. With that fixed:
>
> Hi Florian
>
> cond makes that difficult, since it is not a parameter in the usual
> sense, but an expression to evaluate if the polling should terminate.
>
> readl_poll_timeout() and readl_poll_timeout_atomic() themselves are
> #define's, and there are more levels of macros under them.
Oh that's right, thanks for reminding me of this.
--
Florian
From: Antoine Tenart <[email protected]>
Date: Tue, 26 May 2020 18:22:52 +0200
> This series aims at reducing the waiting time between MDIO transactions
> when using the MSCC MIIM MDIO controller.
>
> I'm not sure we need patch 4/4 and we could reasonably drop it from the
> series. I'm including the patch as it could help to ensure the system
> is functional with a non optimal configuration.
>
> We needed to improve the driver's performances as when using a PHY
> requiring lots of registers accesses (such as the VSC85xx family),
> delays would add up and ended up to be quite large which would cause
> issues such as: a slow initialization of the PHY, and issues when using
> timestamping operations (this feature will be sent quite soon to the
> mailing lists).
Series applied, thank you.
On 5/26/2020 9:22 AM, Antoine Tenart wrote:
> The driver uses a read polling mechanism to check the status of the MDIO
> bus, to know if it is ready to accept next commands. This polling
> mechanism uses usleep_delay() under the hood between reads which is fine
> as long as high resolution timers are enabled. Otherwise the delays will
> end up to be much longer than expected.
>
> This patch fixes this by using udelay() under the hood when
> CONFIG_HIGH_RES_TIMERS isn't enabled. This increases CPU usage.
>
> Signed-off-by: Antoine Tenart <[email protected]>
> ---
> drivers/net/phy/Kconfig | 3 ++-
> drivers/net/phy/mdio-mscc-miim.c | 22 +++++++++++++++++-----
> 2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 2a32f26ead0b..047c27087b10 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -184,7 +184,8 @@ config MDIO_MSCC_MIIM
> depends on HAS_IOMEM
> help
> This driver supports the MIIM (MDIO) interface found in the network
> - switches of the Microsemi SoCs
> + switches of the Microsemi SoCs; it is recommended to switch on
> + CONFIG_HIGH_RES_TIMERS
>
> config MDIO_MVUSB
> tristate "Marvell USB to MDIO Adapter"
> diff --git a/drivers/net/phy/mdio-mscc-miim.c b/drivers/net/phy/mdio-mscc-miim.c
> index aed9afa1e8f1..11f583fd4611 100644
> --- a/drivers/net/phy/mdio-mscc-miim.c
> +++ b/drivers/net/phy/mdio-mscc-miim.c
> @@ -39,13 +39,25 @@ struct mscc_miim_dev {
> void __iomem *phy_regs;
> };
>
> +/* When high resolution timers aren't built-in: we can't use usleep_range() as
> + * we would sleep way too long. Use udelay() instead.
> + */
> +#define mscc_readl_poll_timeout(addr, val, cond, delay_us, timeout_us) \
> +({ \
> + if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS)) \
> + readl_poll_timeout_atomic(addr, val, cond, delay_us, \
> + timeout_us); \
> + readl_poll_timeout(addr, val, cond, delay_us, timeout_us); \
> +})
> +
I would make this a regular function which would not harm the compiler's
ability to optimize it, but would give you type checking. With that fixed:
Reviewed-by: Florian Fainelli <[email protected]>
--
Florian
> > +/* When high resolution timers aren't built-in: we can't use usleep_range() as
> > + * we would sleep way too long. Use udelay() instead.
> > + */
> > +#define mscc_readl_poll_timeout(addr, val, cond, delay_us, timeout_us) \
> > +({ \
> > + if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS)) \
> > + readl_poll_timeout_atomic(addr, val, cond, delay_us, \
> > + timeout_us); \
> > + readl_poll_timeout(addr, val, cond, delay_us, timeout_us); \
> > +})
> > +
>
> I would make this a regular function which would not harm the compiler's
> ability to optimize it, but would give you type checking. With that fixed:
Hi Florian
cond makes that difficult, since it is not a parameter in the usual
sense, but an expression to evaluate if the polling should terminate.
readl_poll_timeout() and readl_poll_timeout_atomic() themselves are
#define's, and there are more levels of macros under them.
Andrew
Hi Andrew,
Quoting Andrew Lunn (2020-05-26 19:01:00)
> On Tue, May 26, 2020 at 06:22:52PM +0200, Antoine Tenart wrote:
> >
> > This series aims at reducing the waiting time between MDIO transactions
> > when using the MSCC MIIM MDIO controller.
>
> There are a couple of other things you can look at:
>
> Can you disable the pre-amble on the MDIO transaction. It requires
> that both the bus master and all devices on the bus support it, but
> when it is usable, you half the number of bits sent over the wire.
>
> Can you control the frequency of MDC? 802.3 says 2.5MHz, but many
> devices support higher speeds. Again, you need all devices on the bus
> to support the speed.
>
> When accessing raw TDR data for cable tests i also have a lot of PHY
> accesses. I implemented both of these for the FEC MDIO bus, and made
> it a lot faster.
Thanks for the tips!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com