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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 8/4/26 1:03 PM, Jie Luo wrote:
> 
> 
> On 8/3/2026 5:10 PM, Stanislaw Pal wrote:
>>> The CMN PLL AHB/SYS clocks will remain enabled as long as a downstream
>>> consumer of the CMN PLL clocks is active — this behaviour was confirmed
>>> experimentally on the IPQ9574 platform as example.
>> That is exactly the mechanism - and it is exactly what IPQ5018 does not
>> have. On IPQ9574 the nsscc node consumes the CMN PLL outputs in DT:
>>
>>   ipq9574.dtsi:
>>     nsscc: clock-controller@39b00000 {
>>         clocks = <&xo_board_clk>,
>>                  <&cmn_pll NSS_1200MHZ_CLK>,
>>                  <&cmn_pll PPE_353MHZ_CLK>, ...
>>
>> so the device link holds the supplier active, which is what your
>> insmod/devmem experiment shows.
>>
>> On IPQ5018 there is no such consumer: nothing in ipq5018.dtsi references
>> any cmn_pll output clock - the only occurrences of the phandle are the
>> provider node itself and its own assigned-clocks. The actual users of
>> the CMN outputs on this SoC (the internal GE PHY and the uniphy blocks)
>> take them directly in hardware, with no DT linkage, so no device link
>> ever holds the provider active. A few ms after probe the autosuspend
>> gates the AHB/SYS clocks, and the box dies on the next bus access -
>> which is the measured behaviour the patch description quotes.
> 
> The CMN PLL output clocks do not depend on the AHB or SYS clocks. They
> continue to operate correctly at the fixed rates even when the AHB
> and SYS clocks are disabled. Therefore, once the CMN PLL module is
> loaded, its output clocks are expected to operate at the correct
> frequencies.

Linux sees there's no consumers for the clocks the CMN PLL provides
and gates them, subsequently also gating the PLL itself as all of
its children become offline.

I can't find the docs that would show me what IPs consume this block,
could you please help out here Jie?

Konrad