Re: [PATCH v11 1/6] soc: qcom: ice: Add OPP-based clock scaling support for ICE

On Mon, Jun 29, 2026 at 01:08:08PM +0200, Konrad Dybcio wrote:
> On 6/22/26 9:34 AM, Abhinaba Rakshit wrote:
> > On Thu, Jun 18, 2026 at 03:01:54PM +0200, Konrad Dybcio wrote:
> >> On 6/8/26 11:47 PM, Abhinaba Rakshit wrote:
> >>> Register optional operation-points-v2 table for ICE device
> >>> during device probe. Attach the OPP-table with only the ICE
> >>> core clock. Since, dtbinding is on a transition phase to include
> >>> iface clock and clock-names, attaching the opp-table to core clock
> >>> remains optional such that it does not cause probe failures.
> >>>
> >>> Introduce clock scaling API qcom_ice_scale_clk which scale ICE
> >>> core clock based on the target frequency provided and if a valid
> >>> OPP-table is registered. Use round_ceil passed to decide on the
> >>> rounding of the clock freq against OPP-table. Clock scaling is
> >>> disabled when a valid OPP-table is not registered.
> >>>
> >>> This ensures when an ICE-device specific OPP table is available,
> >>> use the PM OPP framework to manage frequency scaling and maintain
> >>> proper power-domain constraints.
> >>>
> >>> Also, ensure to drop the votes in suspend to prevent power/thermal
> >>> retention. Subsequently restore the frequency in resume from
> >>> core_clk_freq which stores the last ICE core clock operating frequency.
> >>>
> >>> Reviewed-by: Harshal Dev <[email protected]>
> >>> Signed-off-by: Abhinaba Rakshit <[email protected]>
> >>> ---
> >>
> >> [...]
> >>
> >>> @@ -335,6 +342,11 @@ int qcom_ice_suspend(struct qcom_ice *ice)
> >>>  {
> >>>  	clk_disable_unprepare(ice->iface_clk);
> >>>  	clk_disable_unprepare(ice->core_clk);
> >>> +
> >>> +	/* Drop the clock votes while suspend */
> >>> +	if (ice->has_opp)
> >>> +		dev_pm_opp_set_rate(ice->dev, 0);
> >>
> >> The PM core will quiesce the vote as the device suspends, this is
> >> unnecessary. Similarly, the rate restore logic will become unnecessary.
> >> Especially since dev_pm_opp_set_rate(0) does not actually do any rate
> >> setting.
> > 
> > This section was earlier discussed in the patchset v4:
> > https://lore.kernel.org/all/[email protected]/
> > The intention here was to drop the RPMh votes once the device goes to suspend same
> > as the storage drivers such as mmc drivers does:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mmc/host/sdhci-msm.c#n2946
> > This was done to leave the hanging votes *on* for unused clocks.
> > 
> > However, I get your point, due to mean to say that once device goes to suspend
> > and GDSC power-domain will be turned OFF, it will automatically quiesce the
> > performance votes?
> 
> When the device's runtime state goes to 'suspended', all votes are
> dropped (which then propagates up the power domain tree, effectively
> lowering the vote which passes through the GDSC to the parent CX domain)
> 
> i.e. "yes"
> 

Ack, will drop this in next patchseries.

Abhinaba Rakshit