[PATCH] net: stmmac: Change the busy-wait loops timing

[PATCH] net: stmmac: Change the busy-wait loops timing

[Bartlomiej Dziag]

After writing a new value to the PTP_TAR or PTP_STSUR registers,
the driver waits for the addend/adjust operations to complete.
Sometimes, the first check operation fails, resulting in
a 10 milliseconds busy-loop before performing the next check.
Since updating the registers takes much less than 10 milliseconds,
the kernel gets stuck unnecessarily. This may increase the CPU usage.
Fix that with changing the busy-loop interval to 5 microseconds.
The registers will be checked more often.

Signed-off-by: Bartlomiej Dziag <bartlomiejdziag@gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index e2840fa241f2..f8e1278a1837 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -144,11 +144,11 @@ static int config_addend(void __iomem *ioaddr, u32 addend)
 	writel(value, ioaddr + PTP_TCR);
 
 	/* wait for present addend update to complete */
-	limit = 10;
+	limit = 10000;
 	while (limit--) {
 		if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSADDREG))
 			break;
-		mdelay(10);
+		udelay(5);
 	}
 	if (limit < 0)
 		return -EBUSY;
@@ -187,11 +187,11 @@ static int adjust_systime(void __iomem *ioaddr, u32 sec, u32 nsec,
 	writel(value, ioaddr + PTP_TCR);
 
 	/* wait for present system time adjust/update to complete */
-	limit = 10;
+	limit = 10000;
 	while (limit--) {
 		if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSUPDT))
 			break;
-		mdelay(10);
+		udelay(5);
 	}
 	if (limit < 0)
 		return -EBUSY;
-- 
2.49.0

Re: [PATCH] net: stmmac: Change the busy-wait loops timing

[Andrew Lunn]

On Fri, Jun 06, 2025 at 12:19:49PM +0200, Bartlomiej Dziag wrote:
> After writing a new value to the PTP_TAR or PTP_STSUR registers,
> the driver waits for the addend/adjust operations to complete.
> Sometimes, the first check operation fails, resulting in
> a 10 milliseconds busy-loop before performing the next check.
> Since updating the registers takes much less than 10 milliseconds,
> the kernel gets stuck unnecessarily. This may increase the CPU usage.
> Fix that with changing the busy-loop interval to 5 microseconds.
> The registers will be checked more often.
> 
> Signed-off-by: Bartlomiej Dziag <bartlomiejdziag@gmail.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> index e2840fa241f2..f8e1278a1837 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> @@ -144,11 +144,11 @@ static int config_addend(void __iomem *ioaddr, u32 addend)
>  	writel(value, ioaddr + PTP_TCR);
>  
>  	/* wait for present addend update to complete */
> -	limit = 10;
> +	limit = 10000;
>  	while (limit--) {
>  		if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSADDREG))
>  			break;
> -		mdelay(10);
> +		udelay(5);

I would actually suggest rewriting this using the macros from iopoll.h.

    Andrew

---
pw-bot: cr

Re: [PATCH] net: stmmac: Change the busy-wait loops timing

[Simon Horman]

On Fri, Jun 06, 2025 at 12:19:49PM +0200, Bartlomiej Dziag wrote:
> After writing a new value to the PTP_TAR or PTP_STSUR registers,
> the driver waits for the addend/adjust operations to complete.
> Sometimes, the first check operation fails, resulting in
> a 10 milliseconds busy-loop before performing the next check.
> Since updating the registers takes much less than 10 milliseconds,
> the kernel gets stuck unnecessarily. This may increase the CPU usage.
> Fix that with changing the busy-loop interval to 5 microseconds.
> The registers will be checked more often.

Hi Bartlomiej,

I am curious.

Does it always take much less than 10ms, or is that usually so.
If it is the former, then do we need to wait for in the order of
10000 x 5us = 50ms before giving up?

> 
> Signed-off-by: Bartlomiej Dziag <bartlomiejdziag@gmail.com>

...