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

[Stanislaw Pal <kuncy7@gmail.com>]

On 9/9/26 2:12 PM, Konrad Dybcio wrote:
> Is it only the UNIPHY consuming the 50 MHz one?
>
> What consumes the XO clock? What consumes the sleep clock?

Nothing in Linux consumes any of the three today.

grep -rn '&cmn_pll' arch/arm64/boot/dts/qcom/ on v6.18 gives, in full:

  ipq5018.dtsi:258:  assigned-clocks = <&cmn_pll IPQ5018_CMN_PLL_CLK>;
  ipq5424.dtsi:288:  assigned-clocks = <&cmn_pll IPQ5424_CMN_PLL_CLK>;
  ipq9574.dtsi:359:  assigned-clocks = <&cmn_pll CMN_PLL_CLK>;
  ipq9574.dtsi:1253:                   <&cmn_pll NSS_1200MHZ_CLK>,
  ipq9574.dtsi:1254:                   <&cmn_pll PPE_353MHZ_CLK>,

The first three are the provider setting its own VCO rate. The only
real consumer anywhere is the IPQ9574 NSS clock controller. No device
tree in the tree references XO_24MHZ_CLK or SLEEP_32KHZ_CLK, on any
SoC - and of the five compatibles the driver carries, only ipq5018,
ipq5424 and ipq9574 have a cmn_pll node in mainline at all.

On IPQ5018 specifically:

 - eth-50mhz: Jie is right that the UNIPHY takes it, and it will become
   a clk_get() consumer once IPQ5018 UNIPHY/PCS support lands. The node
   in the pending work has

	clocks = <&gcc GCC_UNIPHY_AHB_CLK>, <&gcc GCC_UNIPHY_SYS_CLK>,
		 <&gcc GCC_UNIPHY_RX_CLK>, <&gcc GCC_UNIPHY_TX_CLK>,
		 <&cmn_pll IPQ5018_ETH_50MHZ_CLK>;
	clock-names = "ahb", "sys", "port5_rx", "port5_tx", "ref";

   In mainline there is no such node yet - the only "uniphy" nodes on
   IPQ5018 are the two PCIe PHYs - so that 50 MHz path exists in
   silicon with nothing holding a handle on it from Linux.

 - xo-24mhz and sleep-32khz: I know of no consumer, in tree or out.
   Worth noting these are not what the rest of the SoC runs on: the
   platform's 24 MHz XO and 32 kHz sleep clock come from the board
   oscillators described separately in ipq5018.dtsi (xo_clk ->
   ref_96mhz_clk -> xo_board_clk, and sleep_clk), not from the CMN
   block. The CMN outputs at the same nominal rates look like
   re-exports for hard-wired internal use.

I would rather this did not decide the patch, though, because the
failure it fixes is not a later register access to the CMN block.
Mieczyslaw's summary in the v4 thread put it that way; the mechanism I
measured is narrower, and it is what the v4 commit message describes:

 - gating those same two clocks on an idle, fully booted GL-B3000
   (runtime PM autosuspend, gate landing ~75 s after probe) is
   harmless - runtime_status "suspended", both radios still serving
   clients;
 - with UNIPHY0 disabled in the device tree, so that no uniphy driver
   exists in that boot at all, the board still dies in 6 of 7 boots;
 - stretching the end of probe by 15 ms, or by a full 2 s, still ends
   in a watchdog reset, 8 of 8 boots each.

So what hangs the SoC is the gate transition landing amid early-boot
bus activity, not any consumer's access afterwards. That is also why
no consumer-side scheme can help: the window is between the CMN PLL
probe returning and the first clk_get() by anybody, whichever consumer
eventually turns up.

Thanks for the Ack on v4.

Best regards,
Stanislaw