Re: [PATCH] clk: qcom: smd-rpm: Skip proxy votes on clocks for QCM2290

[Konrad Dybcio]

On 10/5/26 2:35 PM, Stephan Gerhold wrote:
> On Mon, Sep 21, 2026 at 10:53:40AM +0200, Konrad Dybcio wrote:
>> On 9/16/26 1:05 PM, Imran Shaik wrote:
>>>
>>>
>>> On 11-09-2026 02:36 pm, Konrad Dybcio wrote:
>>>> On 9/10/26 3:44 PM, Imran Shaik wrote:
>>>>> clk_smd_rpm_handoff() votes both active and sleep RPM resource states for
>>>>> every clock, keeping them non-zero until a consumer takes over. If there
>>>>> is no consumer, those clocks will remain active in the idle scenario as
>>>>> well, and the sleep vote is never cleared, blocking XO shutdown.
>>>>>
>>>>> Introduce the skip_clks_handoff flag to handle this on QCM2290 clocks,
>>>>> keeping other targets unaffected.
>>>>>
>>>>> Fixes: 00f64b58874e ("clk: qcom: Add support for SMD-RPM Clocks")
>>>>> Signed-off-by: Imran Shaik <imran.shaik@xxxxxxxxxxxxxxxx>
>>>>> ---
>>>>
>>>> Are you booting with clk_ignore_unused?
>>>>
>>>
>>> No Konrad, clk_ignore_unused is not present.
>>>
>>> Irrespective of clk_ignore_unused, the proxy votes are placed to RPM
>>> during handoff. If no consumer takes over, those votes remain active,
>>> keeping the resource ON in idle and preventing XO shutdown.
>>
>> I re-read this and yeah you're right
>>
>> Is the handoff functionality necessary at all for non-icc clocks?
>> I'm suspecting that this was just a port of the ancient msm-3.10
>> logic where the (modified) clock framework had a handoff mechanism
>> similar to today's sync_state, except the toning-down of these
>> clocks was never added
>>
> 
> The purpose of the handoff functionality is to sync the RPM vote state
> with the Linux vote state. Since we don't have any "read status"
> implemented, we do need to make a vote for every RPM clock to guarantee
> it is in the expected state.
> 
> Simply skipping the proxy/handover votes does not fully solve the
> problem, since you will still leave unused clocks enabled by the boot
> firmware always-on.
> 
> I don't think we need to force on all clocks though, we could probably
> also unconditionally send a "disable clock" after sync_state (once/if
> the clock unused cleanup is actually managed by sync_state).

Yeah this sounds like a solution too.. And it seems like sync_state is
coming?

https://lore.kernel.org/linux-arm-msm/20260626-clk-sync-state-v1-0-4156d8196dc8@xxxxxxxxxx/

Konrad