On 2/2/26 7:36 AM, Abhinaba Rakshit wrote:

On Thu, Jan 29, 2026 at 01:17:51PM +0100, Konrad Dybcio wrote:

quoted

On 1/28/26 9:46 AM, Abhinaba Rakshit wrote:

quoted

Introduce support for dynamic clock scaling of the ICE (Inline Crypto Engine)
using the OPP framework. During ICE device probe, the driver now attempts to
parse an optional OPP table from the ICE-specific device tree node to
determine minimum and maximum supported frequencies for DVFS-aware operations.
API qcom_ice_scale_clk is exposed by ICE driver and is invoked by UFS host
controller driver in response to clock scaling requests, ensuring coordination
between ICE and host controller.

For MMC controllers that do not support clock scaling, the ICE clock frequency
is kept aligned with the MMC controller’s clock rate (TURBO) to ensure
consistent operation.

You skipped that bit, so I had to do a little digging..

This paragraph sounds scary on the surface, as leaving a TURBO vote hanging
would absolutely wreck the power/thermal profile of a running device,
however sdhci-msm's autosuspend functions quiesce the ICE by calling
qcom_ice_suspend()

I think you're missing a dev_pm_opp_set(dev, NULL) or so in that function
and a mirrored restore in _resume

Thanks for pointing this out, its an important piece which is missed.
We can use dev_pm_opp_set_rate(dev, 0/min_freq) in _suspend and restore the

FWIW

dev_pm_opp_set_rate(0) will drop the rpmh vote altogether and NOT
disable the clock or change its rate

dev_pm_opp_set_rate(min_freq) will *lower* the rpmh vote and DO
set_rate (the clock is also left on)

Konrad

suspended frequency in the _resume. Something similar which is used by sdhci-msm.