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

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

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@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
> 
> 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?

Konrad