ARM Sunxi Platform Development
 help / color / mirror / Atom feed
* [PATCH] clk: sunxi-ng: ccu_common: Replace ktime-dependent lock wait loop with udelay
@ 2026-09-16  4:11 Alastair D'Silva
  2026-09-16  4:22 ` sashiko-bot
  2026-09-16  4:29 ` [PATCH v2] clk: sunxi-ng: ccu_common: Use readl_relaxed_poll_timeout_atomic for PLL lock Alastair D'Silva
  0 siblings, 2 replies; 4+ messages in thread
From: Alastair D'Silva @ 2026-09-16  4:11 UTC (permalink / raw)
  To: Chen-Yu Tsai, Jernej Skrabec, Stephen Boyd
  Cc: linux-clk, linux-sunxi, linux-arm-kernel, linux-kernel,
	Brian Masney, Jerome Brunet, Samuel Holland, Alastair D'Silva

The Allwinner sunxi-ng CCU driver uses readl_relaxed_poll_timeout() in
ccu_helper_wait_for_lock() to wait for PLLs to lock.

This poll macro relies on ktime_get() and the kernel timekeeping
infrastructure. During early boot or sensitive clock transitions
(such as CPUfreq DVFS scaling) where timer interrupts or timekeeping may
be suspended or unstable, ktime_get() fails to increment. This turns the
timeout calculation into an infinite busy-wait loop, causing RCU stalls
and system freezes if the PLL lock bit does not assert immediately.

Decouple the PLL lock wait loop from the timekeeping framework by replacing
readl_relaxed_poll_timeout() with an iteration loop using udelay(1) up to
100ms.

Assisted-by: LLM
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---

Notes:
    Tested on Allwinner H618 (Mellow Fly-C5) and H616 boards in Armbian, resolving intermittent boot freezes and CPUfreq DVFS scaling lockups when timekeeping interrupts were suspended.

 drivers/clk/sunxi-ng/ccu_common.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
index 43d8eca6abee..00daedadb5c8 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -7,6 +7,7 @@
 
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
+#include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/iopoll.h>
 #include <linux/module.h>
@@ -25,7 +26,7 @@ struct sunxi_ccu {
 void ccu_helper_wait_for_lock(struct ccu_common *common, u32 lock)
 {
 	void __iomem *addr;
-	u32 reg;
+	int i;
 
 	if (!lock)
 		return;
@@ -35,7 +36,14 @@ void ccu_helper_wait_for_lock(struct ccu_common *common, u32 lock)
 	else
 		addr = common->base + common->reg;
 
-	WARN_ON(readl_relaxed_poll_timeout(addr, reg, reg & lock, 100, 70000));
+	for (i = 0; i < 100000; i++) {
+		if (readl_relaxed(addr) & lock)
+			return;
+		udelay(1);
+	}
+
+	if (!(readl_relaxed(addr) & lock))
+		pr_warn("%s: clock lock timeout\n", clk_hw_get_name(&common->hw));
 }
 EXPORT_SYMBOL_NS_GPL(ccu_helper_wait_for_lock, "SUNXI_CCU");
 
-- 
2.53.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] clk: sunxi-ng: ccu_common: Replace ktime-dependent lock wait loop with udelay
  2026-09-16  4:11 [PATCH] clk: sunxi-ng: ccu_common: Replace ktime-dependent lock wait loop with udelay Alastair D'Silva
@ 2026-09-16  4:22 ` sashiko-bot
  2026-09-16  4:29 ` [PATCH v2] clk: sunxi-ng: ccu_common: Use readl_relaxed_poll_timeout_atomic for PLL lock Alastair D'Silva
  1 sibling, 0 replies; 4+ messages in thread
From: sashiko-bot @ 2026-09-16  4:22 UTC (permalink / raw)
  To: Alastair D'Silva; +Cc: linux-clk, linux-sunxi

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] clk: sunxi-ng: custom udelay loop instead of readl_relaxed_poll_timeout_atomic()
--

commit 303433ce9fcf08821cef4553ec1030effcdd3fb9
Author: Alastair D'Silva <alastair@d-silva.org>

    clk: sunxi-ng: ccu_common: Replace ktime-dependent lock wait loop with udelay

This commit replaces the use of readl_relaxed_poll_timeout() in the sunxi-ng
CCU driver with a custom udelay() loop. The goal is to avoid system freezes
caused by timekeeping suspensions during early boot or CPUfreq DVFS scaling
when waiting for PLLs to lock.

> diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
> index 43d8eca6abeed..00daedadb5c83 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.c
> +++ b/drivers/clk/sunxi-ng/ccu_common.c

[ ... ]

> @@ -35,7 +36,14 @@ void ccu_helper_wait_for_lock(struct ccu_common *common, u32 lock)
>  	else
>  		addr = common->base + common->reg;
>  
> -	WARN_ON(readl_relaxed_poll_timeout(addr, reg, reg & lock, 100, 70000));
> +	for (i = 0; i < 100000; i++) {
> +		if (readl_relaxed(addr) & lock)
> +			return;
> +		udelay(1);
> +	}

[Severity: Low]
Does this custom busy-wait loop unnecessarily reinvent the kernel's standard
polling abstractions?

Since ccu_helper_wait_for_lock() executes whenever a PLL lock is waited upon
during clock configuration, such as early boot or CPUfreq transitions, avoiding
ktime dependencies is definitely necessary. However, the kernel already natively
provides readl_relaxed_poll_timeout_atomic() in <linux/iopoll.h> which is
designed specifically to perform timekeeping-independent hardware polling.

Would it be better to use readl_relaxed_poll_timeout_atomic() here instead of
circumventing the standard I/O polling macros with a hand-rolled loop?

> +
> +	if (!(readl_relaxed(addr) & lock))
> +		pr_warn("%s: clock lock timeout\n", clk_hw_get_name(&common->hw));
>  }
>  EXPORT_SYMBOL_NS_GPL(ccu_helper_wait_for_lock, "SUNXI_CCU");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916041104.239999-1-alastair@d-silva.org?part=1

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH v2] clk: sunxi-ng: ccu_common: Use readl_relaxed_poll_timeout_atomic for PLL lock
  2026-09-16  4:11 [PATCH] clk: sunxi-ng: ccu_common: Replace ktime-dependent lock wait loop with udelay Alastair D'Silva
  2026-09-16  4:22 ` sashiko-bot
@ 2026-09-16  4:29 ` Alastair D'Silva
  2026-09-21 15:52   ` Chen-Yu Tsai
  1 sibling, 1 reply; 4+ messages in thread
From: Alastair D'Silva @ 2026-09-16  4:29 UTC (permalink / raw)
  To: Chen-Yu Tsai, Jernej Skrabec, Stephen Boyd
  Cc: linux-clk, linux-sunxi, linux-arm-kernel, linux-kernel,
	Brian Masney, Jerome Brunet, Samuel Holland, Alastair D'Silva

The Allwinner sunxi-ng CCU driver currently uses
readl_relaxed_poll_timeout() in ccu_helper_wait_for_lock() to wait for
PLLs to lock.

This non-atomic poll macro relies on ktime_get() and the kernel
timekeeping infrastructure. During early boot or sensitive clock
transitions (such as CPUfreq DVFS scaling) where timer interrupts or
timekeeping may be suspended or unstable, ktime_get() fails to advance.
This turns the timeout calculation into an infinite busy-wait loop,
causing RCU stalls and system freezes if the PLL lock bit does not
assert immediately.

Switch to readl_relaxed_poll_timeout_atomic(). This atomic variant relies
on udelay() rather than timekeeping, making it safe to execute even when
timekeeping is suspended or uninitialized.

Assisted-by: LLM
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---

Notes:
    v2:
    - Replace custom udelay loop with readl_relaxed_poll_timeout_atomic()
      as suggested by review.
    
    Tested on Allwinner H618 (Mellow Fly-C5) and H616 boards in Armbian, resolving intermittent boot freezes and CPUfreq DVFS scaling lockups when timekeeping interrupts were suspended.

 drivers/clk/sunxi-ng/ccu_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
index 43d8eca6abee..248e58c9562d 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -35,7 +35,7 @@ void ccu_helper_wait_for_lock(struct ccu_common *common, u32 lock)
 	else
 		addr = common->base + common->reg;
 
-	WARN_ON(readl_relaxed_poll_timeout(addr, reg, reg & lock, 100, 70000));
+	WARN_ON(readl_relaxed_poll_timeout_atomic(addr, reg, reg & lock, 100, 70000));
 }
 EXPORT_SYMBOL_NS_GPL(ccu_helper_wait_for_lock, "SUNXI_CCU");
 
-- 
2.53.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] clk: sunxi-ng: ccu_common: Use readl_relaxed_poll_timeout_atomic for PLL lock
  2026-09-16  4:29 ` [PATCH v2] clk: sunxi-ng: ccu_common: Use readl_relaxed_poll_timeout_atomic for PLL lock Alastair D'Silva
@ 2026-09-21 15:52   ` Chen-Yu Tsai
  0 siblings, 0 replies; 4+ messages in thread
From: Chen-Yu Tsai @ 2026-09-21 15:52 UTC (permalink / raw)
  To: Jernej Skrabec, Stephen Boyd, Alastair D'Silva
  Cc: linux-clk, linux-sunxi, linux-arm-kernel, linux-kernel,
	Brian Masney, Jerome Brunet, Samuel Holland

On Wed, 16 Sep 2026 14:29:10 +1000, Alastair D'Silva wrote:
> The Allwinner sunxi-ng CCU driver currently uses
> readl_relaxed_poll_timeout() in ccu_helper_wait_for_lock() to wait for
> PLLs to lock.
> 
> This non-atomic poll macro relies on ktime_get() and the kernel
> timekeeping infrastructure. During early boot or sensitive clock
> transitions (such as CPUfreq DVFS scaling) where timer interrupts or
> timekeeping may be suspended or unstable, ktime_get() fails to advance.
> This turns the timeout calculation into an infinite busy-wait loop,
> causing RCU stalls and system freezes if the PLL lock bit does not
> assert immediately.
> 
> [...]

Applied to sunxi/clk-for-7.4 in sunxi, thanks!

[1/1] clk: sunxi-ng: ccu_common: Use readl_relaxed_poll_timeout_atomic for PLL lock
      https://git.kernel.org/sunxi/linux/c/9ef62592b80c

Best regards,
-- 
Chen-Yu Tsai <wens@kernel.org>


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-09-21 15:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-16  4:11 [PATCH] clk: sunxi-ng: ccu_common: Replace ktime-dependent lock wait loop with udelay Alastair D'Silva
2026-09-16  4:22 ` sashiko-bot
2026-09-16  4:29 ` [PATCH v2] clk: sunxi-ng: ccu_common: Use readl_relaxed_poll_timeout_atomic for PLL lock Alastair D'Silva
2026-09-21 15:52   ` Chen-Yu Tsai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox