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

[Stephan Gerhold <stephan.gerhold@linaro.org>]

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@oss.qualcomm.com>
> >>> ---
> >>
> >> 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).

Thanks,
Stephan