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

[Jie Luo]

On 8/22/2026 7:19 PM, Mieczyslaw Nalewaj wrote:
> On Thu, Aug 20, 2026 at 01:39:52PM +0800, Jie Luo wrote:
>> 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.
> 
> The PLL outputs keep running, but the AHB register interface does not.
> Once autosuspend gates AHB/SYS, any later register access to the CMN
> block hangs the bus. That is the bug we are fixing.

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.

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

> 
>> On IPQ5018, the CMN PLL provides a 50 MHz output clock that is used as
>> the reference clock for the connected Ethernet device.
> 
> Correct, and that consumer is hardwired in silicon — the internal GE
> PHY and uniphy blocks take proxied this clock without any Linux driver
> calling clk_get() on it. Therefore no device link exists to keep the
> provider active, and CCF rightfully gates the bus clocks after probe.

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.

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.

UNIPHY register offset: 0x74

Bit 1: Clock divider control
0: no divide-by-2
1: divide by 2 enabled

Bit 0: Clock gate control
0: clock disabled
1: clock enabled

> 
> Adding DT consumers would require touching PHY and datapath drivers
> across multiple subsystems just to create artificial clk references.
> That is not a stable material. The v4 driver fix is minimal, correct,
> and self-contained.
> 
> Reviewed-by: Mieczyslaw Nalewaj <namiltd@xxxxxxxxx>
>