drivers/soc/qcom/ice.c | 68 +++++++++++++++++++++++++++++++++++++++++++++ drivers/ufs/host/ufs-qcom.c | 15 ++++++++++ include/soc/qcom/ice.h | 1 + 3 files changed, 84 insertions(+)
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.
Dynamic clock scaling based on OPP tables enables better power-performance
trade-offs. By adjusting ICE clock frequencies according to workload and power
constraints, the system can achieve higher throughput when needed and
reduce power consumption during idle or low-load conditions.
The OPP table remains optional, absence of the table will not cause
probe failure. However, in the absence of an OPP table, ICE clocks will
remain at their default rates, which may limit performance under
high-load scenarios or prevent performance optimizations during idle periods.
Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
---
Changes in v3:
- Avoid clock scaling in case of legacy bindings as suggested.
- Use of_device_is_compatible to distinguish between legacy and non-legacy bindings.
- Link to v2: https://lore.kernel.org/r/20251121-enable-ufs-ice-clock-scaling-v2-0-66cb72998041@oss.qualcomm.com
Changes in v2:
- Use OPP-table instead of freq-table-hz for clock scaling.
- Enable clock scaling for legacy targets as well, by fetching frequencies from storage opp-table.
- Introduce has_opp variable in qcom_ice structure to keep track, if ICE instance has dedicated OPP-table registered.
- Combined the changes for patch-series <20251001-set-ice-clock-to-turbo-v1-1-7b802cf61dda@oss.qualcomm.com> as suggested.
- Link to v1: https://lore.kernel.org/r/20251001-enable-ufs-ice-clock-scaling-v1-0-ec956160b696@oss.qualcomm.com
---
Abhinaba Rakshit (3):
soc: qcom: ice: Add OPP-based clock scaling support for ICE
ufs: host: Add ICE clock scaling during UFS clock changes
soc: qcom: ice: Set ICE clk to TURBO on probe
drivers/soc/qcom/ice.c | 68 +++++++++++++++++++++++++++++++++++++++++++++
drivers/ufs/host/ufs-qcom.c | 15 ++++++++++
include/soc/qcom/ice.h | 1 +
3 files changed, 84 insertions(+)
---
base-commit: fe4d0dea039f2befb93f27569593ec209843b0f5
change-id: 20251120-enable-ufs-ice-clock-scaling-b063caf3e6f9
Best regards,
--
Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
On Fri, Jan 23, 2026 at 12:42:11PM +0530, Abhinaba Rakshit wrote: > 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. > > Dynamic clock scaling based on OPP tables enables better power-performance > trade-offs. By adjusting ICE clock frequencies according to workload and power > constraints, the system can achieve higher throughput when needed and > reduce power consumption during idle or low-load conditions. > > The OPP table remains optional, absence of the table will not cause > probe failure. However, in the absence of an OPP table, ICE clocks will > remain at their default rates, which may limit performance under > high-load scenarios or prevent performance optimizations during idle periods. > > Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com> > --- > Changes in v3: > - Avoid clock scaling in case of legacy bindings as suggested. > - Use of_device_is_compatible to distinguish between legacy and non-legacy bindings. > - Link to v2: https://lore.kernel.org/r/20251121-enable-ufs-ice-clock-scaling-v2-0-66cb72998041@oss.qualcomm.com > > Changes in v2: > - Use OPP-table instead of freq-table-hz for clock scaling. > - Enable clock scaling for legacy targets as well, by fetching frequencies from storage opp-table. > - Introduce has_opp variable in qcom_ice structure to keep track, if ICE instance has dedicated OPP-table registered. > - Combined the changes for patch-series <20251001-set-ice-clock-to-turbo-v1-1-7b802cf61dda@oss.qualcomm.com> as suggested. > - Link to v1: https://lore.kernel.org/r/20251001-enable-ufs-ice-clock-scaling-v1-0-ec956160b696@oss.qualcomm.com > > --- > Abhinaba Rakshit (3): DT binding changes should be a part of the same series. > soc: qcom: ice: Add OPP-based clock scaling support for ICE > ufs: host: Add ICE clock scaling during UFS clock changes > soc: qcom: ice: Set ICE clk to TURBO on probe > > drivers/soc/qcom/ice.c | 68 +++++++++++++++++++++++++++++++++++++++++++++ > drivers/ufs/host/ufs-qcom.c | 15 ++++++++++ > include/soc/qcom/ice.h | 1 + > 3 files changed, 84 insertions(+) > --- > base-commit: fe4d0dea039f2befb93f27569593ec209843b0f5 > change-id: 20251120-enable-ufs-ice-clock-scaling-b063caf3e6f9 > > Best regards, > -- > Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com> > -- With best wishes Dmitry
On Fri, Jan 23, 2026 at 09:18:36PM +0200, Dmitry Baryshkov wrote: > On Fri, Jan 23, 2026 at 12:42:11PM +0530, Abhinaba Rakshit wrote: > > 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. > > > > Dynamic clock scaling based on OPP tables enables better power-performance > > trade-offs. By adjusting ICE clock frequencies according to workload and power > > constraints, the system can achieve higher throughput when needed and > > reduce power consumption during idle or low-load conditions. > > > > The OPP table remains optional, absence of the table will not cause > > probe failure. However, in the absence of an OPP table, ICE clocks will > > remain at their default rates, which may limit performance under > > high-load scenarios or prevent performance optimizations during idle periods. > > > > Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com> > > --- > > Changes in v3: > > - Avoid clock scaling in case of legacy bindings as suggested. > > - Use of_device_is_compatible to distinguish between legacy and non-legacy bindings. > > - Link to v2: https://lore.kernel.org/r/20251121-enable-ufs-ice-clock-scaling-v2-0-66cb72998041@oss.qualcomm.com > > > > Changes in v2: > > - Use OPP-table instead of freq-table-hz for clock scaling. > > - Enable clock scaling for legacy targets as well, by fetching frequencies from storage opp-table. > > - Introduce has_opp variable in qcom_ice structure to keep track, if ICE instance has dedicated OPP-table registered. > > - Combined the changes for patch-series <20251001-set-ice-clock-to-turbo-v1-1-7b802cf61dda@oss.qualcomm.com> as suggested. > > - Link to v1: https://lore.kernel.org/r/20251001-enable-ufs-ice-clock-scaling-v1-0-ec956160b696@oss.qualcomm.com > > > > --- > > Abhinaba Rakshit (3): > > DT binding changes should be a part of the same series. Sure, will bring the dt-bindings change to this patchseries.
© 2016 - 2026 Red Hat, Inc.