Re: [RFC PATCH] clk: qcom: hfpll: return lock timeout from enable paths

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

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@iscas.ac.cn>
>>> ---
>>
>> 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

> I could try this over the weekend on top of Rudraksha Gupta's cpufreq
> patch for msm8960 [1]. We don't have a gpu patch for msm8960 on LKML
> yet...

That's fine

> (also my name doesn't have an "h" :D )

My mistake!

Konrad

> 
> [1] https://lore.kernel.org/all/20260527-expressatt_cpufreq-v2-0-b9b7726ccb6d@gmail.com/
>