Re: [RFC PATCH] clk: qcom: hfpll: return lock timeout from enable paths
From: Antony Kurniawan Soemardi
Date: Sat Jul 04 2026 - 05:09:23 EST
On 7/1/2026 7:11 PM, Konrad Dybcio wrote:
On 6/29/26 5:14 PM, Antony Kurniawan Soemardi wrote:
On 6/29/2026 4:15 PM, Konrad Dybcio wrote:
On 6/28/26 8:07 PM, Antony Kurniawan Soemardi wrote:
On 6/24/2026 2:39 PM, Konrad Dybcio wrote:
On 6/24/26 3:57 AM, Antony Kurniawan Soemardi wrote:
On 6/23/2026 4:43 PM, Konrad Dybcio wrote:
On 6/23/26 8:05 AM, Pengpeng Hou wrote:
The HFPLL enable helper waits for the lock bit but ignores the
regmap_read_poll_timeout() result. The polling condition is also
inconsistent with clk_hfpll_init(), which treats the lock bit being set
as the locked state.
Wait for the lock bit to become set, return timeout errors from the
helper, and propagate those errors through clk_hfpll_enable() and
clk_hfpll_set_rate() instead of enabling the output unconditionally.
Signed-off-by: Pengpeng Hou <pengpeng@xxxxxxxxxxx>
---
This looks good on the surface..
+Herman, Anthony, Dmitry could you please give this a spin on 8x60?
Konrad
Just to clarify, this patch impacts cpufreq and gpufreq for Qualcomm
Krait era, is that correct?
Seems that way - cpu, L2, and GPU, maybe others
nope, tested on Sony Xperia SP (MSM8960T), the phone hangs
[...]
[ 2.679716] L2 @ Undefined rate. Forcing new rate
This seems odd. What's the reported rate there?
if you're asking clk_get_rate(clks[l2_mux]), it's 0 Hz.
Hm, are the parents registered?
pardon me for stupid question, but how do I verify the parent
registration?
I see:
p_data[0].fw_name = hfpll_name; // "hfpll_l2" lookup via clock-names
p_data[0].name = hfpll_name; // legacy global clk lookup for
// clk.name == 'hfpll_l2'
// (registered in gcc-msm8960.c)
p_data[1].hw = hfpll_div; // sourced from "hfpllN"
p_data[2].hw = sec_mux; // sourced from "acpuN_aux"
There's a fw_devlink between kraitcc and gcc already, since you
specify all the clocks (minus hfpll_l2):
https://lore.kernel.org/linux-arm-msm/20260514-expressatt_cpufreq-v1-3-487fd2d78859@xxxxxxxxx/
so it must have probed beforehand (unless you disable fw_devlink?)
I removed the fw_devlink kernel arg, the kraitcc is probed much later,
but still stuck with the same "L2 @ undefined rate"
Can you do `cat /sys/kernel/debug/clk/clk_summary` on a running system?
below is the mainline kernel, with cpufreq patch
sony-huashan:/home/user# cat /sys/kernel/debug/clk/clk_summary
enable prepare protect duty hardware connection
clock count count count rate accuracy phase cycle enable consumer id
---------------------------------------------------------------------------------------------------------------------------------------------
qsb 0 0 0 1 0 0 50000 Y deviceless no_connection_id
[...]
pxo_board 4 4 1 27000000 0 0 50000 Y deviceless no_connection_id
[...]
hfpll_l2 1 1 0 783000000 0 0 50000 Y deviceless no_connection_id
hfpll_l2_div 3 3 0 391500000 0 0 50000 Y deviceless no_connection_id
krait_l2_pri_mux 2 2 0 391500000 0 0 50000 Y deviceless no_connection_id
hfpll1 1 1 0 783000000 0 0 50000 Y deviceless no_connection_id
hfpll1_div 2 2 0 391500000 0 0 50000 Y deviceless no_connection_id
krait1_pri_mux 1 1 0 391500000 0 0 50000 Y cpu1 no_connection_id
cpu1 no_connection_id
deviceless no_connection_id
hfpll0 2 2 0 1512000000 0 0 50000 Y deviceless no_connection_id
krait0_pri_mux 1 1 0 1512000000 0 0 50000 Y cpu0 no_connection_id
cpu0 no_connection_id
deviceless no_connection_id
hfpll0_div 1 1 0 756000000 0 0 50000 Y deviceless no_connection_id
[...]
krait_l2_sec_mux 2 2 0 0 0 0 50000 Y deviceless no_connection_id
krait1_sec_mux 1 1 0 0 0 0 50000 Y deviceless no_connection_id
krait0_sec_mux 1 1 0 0 0 0 50000 Y deviceless no_connection_id
pll4_vote 0 0 0 0 0 0 50000 ? deviceless no_connection_id
below is the mainline kernel, without cpufreq patch
sony-huashan:/home/user# cat /sys/kernel/debug/clk/clk_summary
enable prepare protect duty hardware connection
clock count count count rate accuracy phase cycle enable consumer id
---------------------------------------------------------------------------------------------------------------------------------------------
[...]
pxo_board 1 1 1 27000000 0 0 50000 Y deviceless no_connection_id
[...]
hfpll_l2 0 0 0 0 0 0 50000 N deviceless no_connection_id
hfpll1 0 0 0 918000000 0 0 50000 N deviceless no_connection_id
hfpll0 0 0 0 918000000 0 0 50000 Y deviceless no_connection_id
[...]
pll4_vote 0 0 0 0 0 0 50000 ? deviceless no_connection_id
Do you have other idea how to solve this? I added some pr_err if the
read poll is timeout:
[ 11.164436] [pmOS-rd]: ❬❬ PMOS STAGE 2 ❭❭
[ 20.400232] krait_add_pri_mux: krait0_pri_mux, hfpll_name: hfpll0
[ 20.400793] Enabling HFPLL hfpll1
[ 20.455491] krait_add_pri_mux: krait1_pri_mux, hfpll_name: hfpll1
[ 20.456081] Enabling HFPLL hfpll_l2
[ 20.560623] HFPLL hfpll_l2 failed to lock (val=0x6, ret=-110, hd->lock_bit=0)
[ 20.758961] krait_add_pri_mux: krait_l2_pri_mux, hfpll_name: hfpll_l2
[ 20.759339] L2 @ 0 KHz. Forcing new rate.
[ 20.764520] L2 @ Undefined rate. Forcing new rate.
--
Thanks,
Antony K. S.