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

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

On 9/9/26 3:20 PM, Stanislaw Pal wrote:
> 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.

Yes, that's more than clear :)

I'm trying to ask Jie about the platform details, to which I
unfortunately don't have access at the moment..

or maybe +Kathiravan?

[...]


> 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.

I would be more inclined to believe it's racing against some other
driver enabling/disabling something else, perhaps a register that
depends on a clock derived from these two.

When that crash occurs does the device enter crashdump mode (USB
PID 0x900e)?

Konrad