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

On 8/6/2026 4:33 AM, Jie Luo wrote:
> 
> 
> On 8/5/2026 4:12 PM, Stanislaw Pal wrote:
>> On 8/5/2026 Jie Luo wrote:
>>> Is there any use case that requires accessing the CMN PLL registers when
>>> no downstream consumer is active? If not, I don't think a fix is needed
>>> here. As you may have observed, debugfs clk_summary can still display
>>> the clock rate correctly even when there is no downstream consumer and
>>> the AHB and SYS clocks are disabled.
>>
>> The clk_summary observation does not show what it seems to show, and I
>> have to correct my own previous mail on the same point: this driver does
>> not set CLK_GET_RATE_NOCACHE, and clk_core_get_rate_recalc() only calls
>> .recalc_rate for clocks that have that flag. So clk_summary (and
>> clk_get_rate()) return the rate cached at registration time, when probe
>> still held the bus clocks enabled - no register access happens at all.
>> It displaying correct rates with the clocks gated is exactly the cached
>> value; it says nothing about whether an actual access would survive.
>>
>> As for the use case: on IPQ5018 it is booting the SoC. With the clocks
>> gated after probe, boards hang within milliseconds - 100% reproducible
>> on some builds, before userspace exists, with no consumer anywhere - and
>> the only variable that changes the outcome is holding this reference.
>> That is also why I do not think moving runtime PM references into the
>> clk ops would help this platform: by your own argument nothing calls the
>> ops at that point, yet the SoC still dies. Whatever the fatal access is
>> - a CCF path we have not pinned down, or something else in the same
>> clock domain - the platform demonstrably does not survive the gate
>> itself.
> 
> Once the CMN PLL module has been loaded, there should be no further need
> to access its registers during normal operation. The CMN PLL provides
> fixed-rate clocks, and its output clocks should be initialized and
> operating at the correct fixed rates after the module is loaded for the
> IPQ5018 platform.
> 
> Regarding the hang issue you mentioned, it should not be related to the
> inability to access the CMN PLL registers. The actual root cause of the
> hang should be investigated separately.
> 
Following along here - just want to make sure this doesn't get lost:
Stanislaw pointed out earlier that clk_summary can't actually be used
as evidence here, since this driver doesn't set CLK_GET_RATE_NOCACHE
and so never reads the registers live; it just returns the cached
registration-time rate. That seems like a fairly load-bearing point
for the discussion and I haven't seen it addressed yet.

Given the hang is reportedly 100% reproducible pre-userspace, is there
a concrete next step to root-cause it, or is v3 the right call for now
with a follow-up tracked separately?