Re: [RFC PATCH] clk: qcom: hfpll: return lock timeout from enable paths
From: Antony Kurniawan Soemardi
Date: Mon Jun 29 2026 - 11:32:45 EST
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.
without Pengpeng Hou's patch, the kernel continues with the
following logs:
[ 2.442850] ledtrig-cpu: registered to indicate activity on CPUs
[ 2.516664] L2 @ Undefined rate. Forcing new rate.
[ 2.516870] L2 @ 391500 KHz
[ 2.527751] CPU0 @ 918000 KHz
[ 2.527813] CPU1 @ Undefined rate. Forcing new rate.
[ 2.529921] CPU1 @ 391500 KHz
[ 2.613351] gsbi 1a000000.gsbi: GSBI port protocol: 6 crci: 0
--
Thanks,
Antony K. S.