Re: [PATCH] clk: qcom: ipq-cmn-pll: keep the CMN block bus clocks enabled

[Stanislaw Pal <kuncy7@gmail.com>]

On 8/24/26 12:28 PM, Jie Luo wrote:
> As far as I understand, there is no expectation that the CMN PLL
> registers need to be accessed after the CMN PLL driver has finished
> loading on IPQ5018.

Agreed, and measured: with the AHB/SYS pair gated on a fully booted
GL-B3000 (runtime PM autosuspend, gate landing ~75 s after probe,
runtime_status "suspended"), the board keeps running, both radios keep
serving clients, nothing complains. Nothing in Linux needs those
registers after probe, and the v4 commit message says so. The fix is
not about post-probe register access.

To Mieczyslaw's point on clk_summary: that read does not reach the
hardware either way. The provider ops are wrapped in
clk_pm_runtime_get()/put() by the framework (clk.c: recalc_rate at
~1923, prepare at ~1110, set_rate at ~2415/2539 in 6.18), so a debugfs
read would resume the block before touching it - and the outputs are
registered without CLK_GET_RATE_NOCACHE, so clk_summary reports the
cached rate without recalc at all. Accesses through CCF are safe with
or without this patch; the argument for it never rested on them.

> Could we identify which module is blocked after the CMN PLL driver
> probe completes?

None gets the chance. This is not a driver hanging on a register - the
SoC dies and the watchdog resets it, silently, with no console output
after the CMN PLL probe. Georg's timing on the Cudy P5: probe completes
in ~628 us, pm_runtime_put() returns, and the board is dead before the
next initcall starts. So the question "which module" has no answer in
the form of a stuck driver; what exists is a window right after probe
in which the asynchronous gate is fatal, and outside of which (idle
system, above) the very same gate is harmless.

> The UNIPHY block is the consumer of this 50 MHz clock. It divides and
> gates the 50 MHz clock, then routes it to the connected PHY or switch
> on the IPQ5018 platform.

Thank you - that confirms the picture from the DT side (the GE PHY
clocks are fixed-clock stubs in ipq5018.dtsi and no node references
&cmn_pll, so Linux sees a provider with zero consumers while the
consumer is wired in silicon). The 0x74 divider/gate description is
useful and I have noted it.

> Would you be able to try this approach in your code workspace? Since
> the UNIPHY driver is not currently available in the upstream kernel,
> this may be a practical way to validate whether keeping the relevant
> clock path active through the UNIPHY side resolves the issue.

Two measurements already bracket this, so let me put them on the table
before anyone spends time on it:

 - GL-B3000, UNIPHY0 disabled in DT (no uniphy driver ever probes),
   vanilla put: 6 of 7 boots die. The failure does not need the uniphy
   driver, or its clock path, to exist.
 - Cudy P5: the board dies before the next initcall after the CMN PLL
   probe - i.e. before any uniphy driver could run at all.

So the fatal window opens and closes before the uniphy side gets to
execute anything, upstream driver or not. A fix on the uniphy side can
only start acting after that window, which is why holding the reference
in the provider - the one place that exists at that moment - is what
boots deterministically on all three boards. That said, the gating
behaviour of 0x74 is worth understanding for the uniphy driver that will
eventually come upstream, and I will keep it in mind for that work.

The full set of numbers (per-block isolation, the 15 ms / 2 s delay
experiments on two boards, the idle-gate result) is in v4:
https://lore.kernel.org/linux-clk/20260813093351.178419-1-kuncy7@gmail.com/