[PATCH v6 0/4] Enable ICE clock scaling

[PATCH v6 0/4] Enable ICE clock scaling

[Abhinaba Rakshit]

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 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 v6:
- Remove scale_up parameter from qcom_ice_scale_clk API.
- Remove having max_freq and min_freq as the checks for overclocking and underclocking is no-longer needed.
- UFS driver passes rounding flags depending on scale_up value.
- Ensure UFS driver does not fail devfreq requests if ICE OPP is not supported.
- Link to v5: https://lore.kernel.org/r/3ecb8d08-64cb-4fe1-bebd-1532dc5a86af@oss.qualcomm.com

Changes in v5:
- Update operating-points-v2 property in dtbindings as suggested.
- Fix comment styles.
- Add argument in qcom_ice_create to distinguish between legacy bindings and newer bindings.
- Ensure to drop votes in suspend and enable the last vote in resume.
- Link to v4: https://lore.kernel.org/r/20260128-enable-ufs-ice-clock-scaling-v4-0-260141e8fce6@oss.qualcomm.com

Changes in v4:
- Enable multiple frequency scaling based OPP-entries as suggested in v3 patchset.
- Include bindings change: https://lore.kernel.org/all/20260123-add-operating-points-v2-property-for-qcom-ice-bindings-v1-1-2155f7aacc28@oss.qualcomm.com/.
- Link to v3: https://lore.kernel.org/r/20260123-enable-ufs-ice-clock-scaling-v3-0-d0d8532abd98@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 (4):
      dt-bindings: crypto: ice: add operating-points-v2 property for QCOM ICE
      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

 .../bindings/crypto/qcom,inline-crypto-engine.yaml | 26 ++++++
 drivers/soc/qcom/ice.c                             | 95 +++++++++++++++++++++-
 drivers/ufs/host/ufs-qcom.c                        | 21 ++++-
 include/soc/qcom/ice.h                             |  5 ++
 4 files changed, 143 insertions(+), 4 deletions(-)
---
base-commit: fe4d0dea039f2befb93f27569593ec209843b0f5
change-id: 20251120-enable-ufs-ice-clock-scaling-b063caf3e6f9

Best regards,
-- 
Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>

[PATCH v6 1/4] dt-bindings: crypto: ice: add operating-points-v2 property for QCOM ICE

[Abhinaba Rakshit]

Add support for specifying OPPs for the Qualcomm Inline Crypto Engine
by allowing the use of the standard "operating-points-v2" property in
the ICE device node.

ICE clock management was handled by the storage drivers in legacy
bindings, so the ICE driver itself had no mechanism for clock scaling.
With the introduction of the new standalone ICE device node, clock
control must now be performed directly by the ICE driver. Enabling
operating-points-v2 allows the driver to describe and manage the
frequency and voltage requirements for proper DVFS operation.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
---
 .../bindings/crypto/qcom,inline-crypto-engine.yaml | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index c3408dcf5d2057270a732fe0e6744f4aa6496e06..50bcf3309b9fa0a3f727f010301670e5de58366f 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -30,6 +30,11 @@ properties:
   clocks:
     maxItems: 1
 
+  operating-points-v2: true
+
+  opp-table:
+    type: object
+
 required:
   - compatible
   - reg
@@ -46,5 +51,26 @@ examples:
                    "qcom,inline-crypto-engine";
       reg = <0x01d88000 0x8000>;
       clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+
+      operating-points-v2 = <&ice_opp_table>;
+
+      ice_opp_table: opp-table {
+        compatible = "operating-points-v2";
+
+        opp-100000000 {
+          opp-hz = /bits/ 64 <100000000>;
+          required-opps = <&rpmhpd_opp_low_svs>;
+        };
+
+        opp-201500000 {
+          opp-hz = /bits/ 64 <201500000>;
+          required-opps = <&rpmhpd_opp_svs_l1>;
+        };
+
+        opp-403000000 {
+          opp-hz = /bits/ 64 <403000000>;
+          required-opps = <&rpmhpd_opp_nom>;
+        };
+      };
     };
 ...

-- 
2.34.1

[PATCH v6 2/4] soc: qcom: ice: Add OPP-based clock scaling support for ICE

[Abhinaba Rakshit]

Register optional operation-points-v2 table for ICE device
during device probe.

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 flags (if provided) to decide on
the rounding of the clock freq against OPP-table. Disable clock
scaling if OPP-table is not registered.

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.

Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
---
 drivers/soc/qcom/ice.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++--
 include/soc/qcom/ice.h |  5 +++
 2 files changed, 90 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index b203bc685cadd21d6f96eb1799963a13db4b2b72..1372dc4a4a4d0df982ea3a174df8779a37ce07c6 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -16,6 +16,7 @@
 #include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
+#include <linux/pm_opp.h>
 
 #include <linux/firmware/qcom/qcom_scm.h>
 
@@ -111,6 +112,8 @@ struct qcom_ice {
 	bool use_hwkm;
 	bool hwkm_init_complete;
 	u8 hwkm_version;
+	unsigned long core_clk_freq;
+	bool has_opp;
 };
 
 static bool qcom_ice_check_supported(struct qcom_ice *ice)
@@ -310,12 +313,17 @@ int qcom_ice_resume(struct qcom_ice *ice)
 	struct device *dev = ice->dev;
 	int err;
 
+	/* Restore the ICE core clk freq */
+	if (ice->has_opp && ice->core_clk_freq)
+		dev_pm_opp_set_rate(ice->dev, ice->core_clk_freq);
+
 	err = clk_prepare_enable(ice->core_clk);
 	if (err) {
 		dev_err(dev, "failed to enable core clock (%d)\n",
 			err);
 		return err;
 	}
+
 	qcom_ice_hwkm_init(ice);
 	return qcom_ice_wait_bist_status(ice);
 }
@@ -324,6 +332,11 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
 int qcom_ice_suspend(struct qcom_ice *ice)
 {
 	clk_disable_unprepare(ice->core_clk);
+
+	/* Drop the clock votes while suspend */
+	if (ice->has_opp)
+		dev_pm_opp_set_rate(ice->dev, 0);
+
 	ice->hwkm_init_complete = false;
 
 	return 0;
@@ -549,10 +562,59 @@ int qcom_ice_import_key(struct qcom_ice *ice,
 }
 EXPORT_SYMBOL_GPL(qcom_ice_import_key);
 
+/**
+ * qcom_ice_scale_clk() - Scale ICE clock for DVFS-aware operations
+ * @ice: ICE driver data
+ * @target_freq: requested frequency in Hz
+ * @flags: Rounding policy (ICE_CLOCK_ROUND_*)
+ *
+ * Selects an OPP frequency based on @target_freq and the rounding mode in
+ * @flags, then programs it using dev_pm_opp_set_rate(), including any
+ * voltage or power-domain transitions handled by the OPP framework.
+ * Updates ice->core_clk_freq on success.
+ *
+ * Return: 0 on success; -EOPNOTSUPP if no OPP table; -EINVAL in-case of
+ *         incorrect flags; or error from dev_pm_opp_set_rate()/OPP lookup.
+ */
+int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
+		       unsigned int flags)
+{
+	unsigned long ice_freq = target_freq;
+	struct dev_pm_opp *opp;
+	int ret;
+
+	if (!ice->has_opp)
+		return -EOPNOTSUPP;
+
+	switch (flags) {
+	case ICE_CLOCK_ROUND_CEIL:
+		opp = dev_pm_opp_find_freq_ceil(ice->dev, &ice_freq);
+		break;
+	case ICE_CLOCK_ROUND_FLOOR:
+		opp = dev_pm_opp_find_freq_floor(ice->dev, &ice_freq);
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	if (IS_ERR(opp))
+		return PTR_ERR(opp);
+	dev_pm_opp_put(opp);
+
+	ret = dev_pm_opp_set_rate(ice->dev, ice_freq);
+	if (!ret)
+		ice->core_clk_freq = ice_freq;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(qcom_ice_scale_clk);
+
 static struct qcom_ice *qcom_ice_create(struct device *dev,
-					void __iomem *base)
+					void __iomem *base,
+					bool is_legacy_binding)
 {
 	struct qcom_ice *engine;
+	int err;
 
 	if (!qcom_scm_is_available())
 		return ERR_PTR(-EPROBE_DEFER);
@@ -584,6 +646,26 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
 	if (IS_ERR(engine->core_clk))
 		return ERR_CAST(engine->core_clk);
 
+	/*
+	 * Register the OPP table only when ICE is described as a standalone
+	 * device node. Older platforms place ICE inside the storage controller
+	 * node, so they don't need an OPP table here, as they are handled in
+	 * storage controller.
+	 */
+	if (!is_legacy_binding) {
+		/* OPP table is optional */
+		err = devm_pm_opp_of_add_table(dev);
+		if (err && err != -ENODEV) {
+			dev_err(dev, "Invalid OPP table in Device tree\n");
+			return ERR_PTR(err);
+		}
+		engine->has_opp = (err == 0);
+
+		if (!engine->has_opp)
+			dev_info(dev, "ICE OPP table is not registered\n");
+	}
+
+	engine->core_clk_freq = clk_get_rate(engine->core_clk);
 	if (!qcom_ice_check_supported(engine))
 		return ERR_PTR(-EOPNOTSUPP);
 
@@ -628,7 +710,7 @@ static struct qcom_ice *of_qcom_ice_get(struct device *dev)
 			return ERR_CAST(base);
 
 		/* create ICE instance using consumer dev */
-		return qcom_ice_create(&pdev->dev, base);
+		return qcom_ice_create(&pdev->dev, base, true);
 	}
 
 	/*
@@ -725,7 +807,7 @@ static int qcom_ice_probe(struct platform_device *pdev)
 		return PTR_ERR(base);
 	}
 
-	engine = qcom_ice_create(&pdev->dev, base);
+	engine = qcom_ice_create(&pdev->dev, base, false);
 	if (IS_ERR(engine))
 		return PTR_ERR(engine);
 
diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
index 4bee553f0a59d86ec6ce20f7c7b4bce28a706415..962454b85ccd994aeeb373729d4b39a2e0b40069 100644
--- a/include/soc/qcom/ice.h
+++ b/include/soc/qcom/ice.h
@@ -9,6 +9,9 @@
 #include <linux/blk-crypto.h>
 #include <linux/types.h>
 
+#define ICE_CLOCK_ROUND_CEIL	BIT(1)
+#define ICE_CLOCK_ROUND_FLOOR	BIT(2)
+
 struct qcom_ice;
 
 int qcom_ice_enable(struct qcom_ice *ice);
@@ -30,5 +33,7 @@ int qcom_ice_import_key(struct qcom_ice *ice,
 			const u8 *raw_key, size_t raw_key_size,
 			u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
 struct qcom_ice *devm_of_qcom_ice_get(struct device *dev);
+int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
+		       unsigned int flags);
 
 #endif /* __QCOM_ICE_H__ */

-- 
2.34.1

[PATCH v6 3/4] ufs: host: Add ICE clock scaling during UFS clock changes

[Abhinaba Rakshit]

Implement ICE (Inline Crypto Engine) clock scaling in sync with
UFS controller clock scaling. This ensures that the ICE operates at
an appropriate frequency when the UFS clocks are scaled up or down,
improving performance and maintaining stability for crypto operations.

Incase of OPP scaling is not supported by ICE, ensure to not prevent
devfreq for UFS, as ICE OPP-table is optional.

Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
---
 drivers/ufs/host/ufs-qcom.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 8d119b3223cbdaa3297d2beabced0962a1a847d5..d85640028b567d2084683f237e3110c682a08ddb 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -305,6 +305,15 @@ static int ufs_qcom_ice_prepare_key(struct blk_crypto_profile *profile,
 	return qcom_ice_prepare_key(host->ice, lt_key, lt_key_size, eph_key);
 }
 
+static int ufs_qcom_ice_scale_clk(struct ufs_qcom_host *host, unsigned long target_freq,
+				  unsigned int flags)
+{
+	if (host->hba->caps & UFSHCD_CAP_CRYPTO)
+		return qcom_ice_scale_clk(host->ice, target_freq, flags);
+
+	return 0;
+}
+
 static const struct blk_crypto_ll_ops ufs_qcom_crypto_ops = {
 	.keyslot_program	= ufs_qcom_ice_keyslot_program,
 	.keyslot_evict		= ufs_qcom_ice_keyslot_evict,
@@ -339,6 +348,12 @@ static void ufs_qcom_config_ice_allocator(struct ufs_qcom_host *host)
 {
 }
 
+static int ufs_qcom_ice_scale_clk(struct ufs_qcom_host *host, unsigned long target_freq,
+				  unsigned int flags)
+{
+	return 0;
+}
+
 #endif
 
 static void ufs_qcom_disable_lane_clks(struct ufs_qcom_host *host)
@@ -1646,8 +1661,12 @@ static int ufs_qcom_clk_scale_notify(struct ufs_hba *hba, bool scale_up,
 		else
 			err = ufs_qcom_clk_scale_down_post_change(hba, target_freq);
 
+		if (!err)
+			err = ufs_qcom_ice_scale_clk(host, target_freq,
+						     scale_up ? ICE_CLOCK_ROUND_FLOOR
+							      : ICE_CLOCK_ROUND_CEIL);
 
-		if (err) {
+		if (err && err != -EOPNOTSUPP) {
 			ufshcd_uic_hibern8_exit(hba);
 			return err;
 		}

-- 
2.34.1

[PATCH v6 4/4] soc: qcom: ice: Set ICE clk to TURBO on probe

[Abhinaba Rakshit]

MMC controller lacks a clock scaling mechanism, unlike the UFS
controller. By default, the MMC controller is set to TURBO mode
during probe, but the ICE clock remains at XO frequency,
leading to read/write performance degradation on eMMC.

To address this, set the ICE clock to TURBO during probe to
align it with the controller clock. This ensures consistent
performance and avoids mismatches between the controller
and ICE clock frequencies.

For platforms where ICE is represented as a separate device,
use the OPP framework to vote for TURBO mode, maintaining
proper voltage and power domain constraints.

Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
---
 drivers/soc/qcom/ice.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index 1372dc4a4a4d0df982ea3a174df8779a37ce07c6..a60a793f9c230e08ebd7cae89a828980e762db27 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -665,6 +665,13 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
 			dev_info(dev, "ICE OPP table is not registered\n");
 	}
 
+	if (engine->has_opp) {
+		/* Vote for maximum clock rate for maximum performance */
+		err = dev_pm_opp_set_rate(dev, INT_MAX);
+		if (err)
+			dev_warn(dev, "Failed boosting the ICE clk to TURBO\n");
+	}
+
 	engine->core_clk_freq = clk_get_rate(engine->core_clk);
 	if (!qcom_ice_check_supported(engine))
 		return ERR_PTR(-EOPNOTSUPP);

-- 
2.34.1

Re: [PATCH v6 2/4] soc: qcom: ice: Add OPP-based clock scaling support for ICE

[Konrad Dybcio]

On 2/19/26 10:39 AM, Abhinaba Rakshit wrote:
> Register optional operation-points-v2 table for ICE device
> during device probe.
> 
> 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 flags (if provided) to decide on
> the rounding of the clock freq against OPP-table. Disable clock
> scaling if OPP-table is not registered.
> 
> 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.
> 
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---

[...]

> +int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
> +		       unsigned int flags)

If you're not going to add more flags, 'bool round_ceil' would do just fine,
without introducing new custom defines

[...]

> +	/*
> +	 * Register the OPP table only when ICE is described as a standalone
> +	 * device node. Older platforms place ICE inside the storage controller
> +	 * node, so they don't need an OPP table here, as they are handled in
> +	 * storage controller.
> +	 */
> +	if (!is_legacy_binding) {
> +		/* OPP table is optional */
> +		err = devm_pm_opp_of_add_table(dev);
> +		if (err && err != -ENODEV) {
> +			dev_err(dev, "Invalid OPP table in Device tree\n");
> +			return ERR_PTR(err);
> +		}
> +		engine->has_opp = (err == 0);
> +
> +		if (!engine->has_opp)
> +			dev_info(dev, "ICE OPP table is not registered\n");

dev_warn(dev, "ICE OPP table is not registered, please update your DT")

Konrad

Re: [PATCH v6 4/4] soc: qcom: ice: Set ICE clk to TURBO on probe

[Konrad Dybcio]

On 2/19/26 10:39 AM, Abhinaba Rakshit wrote:
> MMC controller lacks a clock scaling mechanism, unlike the UFS
> controller. By default, the MMC controller is set to TURBO mode
> during probe, but the ICE clock remains at XO frequency,
> leading to read/write performance degradation on eMMC.
> 
> To address this, set the ICE clock to TURBO during probe to
> align it with the controller clock. This ensures consistent
> performance and avoids mismatches between the controller
> and ICE clock frequencies.
> 
> For platforms where ICE is represented as a separate device,
> use the OPP framework to vote for TURBO mode, maintaining
> proper voltage and power domain constraints.
> 
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
>  drivers/soc/qcom/ice.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index 1372dc4a4a4d0df982ea3a174df8779a37ce07c6..a60a793f9c230e08ebd7cae89a828980e762db27 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -665,6 +665,13 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
>  			dev_info(dev, "ICE OPP table is not registered\n");
>  	}
>  
> +	if (engine->has_opp) {
> +		/* Vote for maximum clock rate for maximum performance */
> +		err = dev_pm_opp_set_rate(dev, INT_MAX);
> +		if (err)
> +			dev_warn(dev, "Failed boosting the ICE clk to TURBO\n");

I suppose this isn't exactly critical, but should never happen either

Nonetheless, it's fine

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH v6 2/4] soc: qcom: ice: Add OPP-based clock scaling support for ICE

[Abhinaba Rakshit]

On Thu, Feb 19, 2026 at 03:16:33PM +0100, Konrad Dybcio wrote:
> On 2/19/26 10:39 AM, Abhinaba Rakshit wrote:
> > Register optional operation-points-v2 table for ICE device
> > during device probe.
> > 
> > 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 flags (if provided) to decide on
> > the rounding of the clock freq against OPP-table. Disable clock
> > scaling if OPP-table is not registered.
> > 
> > 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.
> > 
> > Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> > ---
> 
> [...]
> 
> > +int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
> > +		       unsigned int flags)
> 
> If you're not going to add more flags, 'bool round_ceil' would do just fine,
> without introducing new custom defines

I guess, the defines I am currently using are mutually exclusive and not intend
to extend it. Hence, can replace using 'bool round_ceil'.
Ack, will send a new patchset with the update.
 
> [...]
> 
> > +	/*
> > +	 * Register the OPP table only when ICE is described as a standalone
> > +	 * device node. Older platforms place ICE inside the storage controller
> > +	 * node, so they don't need an OPP table here, as they are handled in
> > +	 * storage controller.
> > +	 */
> > +	if (!is_legacy_binding) {
> > +		/* OPP table is optional */
> > +		err = devm_pm_opp_of_add_table(dev);
> > +		if (err && err != -ENODEV) {
> > +			dev_err(dev, "Invalid OPP table in Device tree\n");
> > +			return ERR_PTR(err);
> > +		}
> > +		engine->has_opp = (err == 0);
> > +
> > +		if (!engine->has_opp)
> > +			dev_info(dev, "ICE OPP table is not registered\n");
> 
> dev_warn(dev, "ICE OPP table is not registered, please update your DT")

Ack, will send a new patchset with the update.

Abhinaba Rakshit

Re: [PATCH v6 3/4] ufs: host: Add ICE clock scaling during UFS clock changes

[Krzysztof Kozlowski]

On 19/02/2026 10:39, Abhinaba Rakshit wrote:
> Implement ICE (Inline Crypto Engine) clock scaling in sync with
> UFS controller clock scaling. This ensures that the ICE operates at
> an appropriate frequency when the UFS clocks are scaled up or down,
> improving performance and maintaining stability for crypto operations.
> 
> Incase of OPP scaling is not supported by ICE, ensure to not prevent
> devfreq for UFS, as ICE OPP-table is optional.
> 
> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
>  drivers/ufs/host/ufs-qcom.c | 21 ++++++++++++++++++++-


SCSI/UFS is not respecting subsystem boundaries, thus you must not
combine multiple subsystem when targeting UFS.

Please split your patches.

Best regards,
Krzysztof

Re: [PATCH v6 3/4] ufs: host: Add ICE clock scaling during UFS clock changes

[Abhinaba Rakshit]

On Wed, Feb 25, 2026 at 10:00:12AM +0100, Krzysztof Kozlowski wrote:
> On 19/02/2026 10:39, Abhinaba Rakshit wrote:
> > Implement ICE (Inline Crypto Engine) clock scaling in sync with
> > UFS controller clock scaling. This ensures that the ICE operates at
> > an appropriate frequency when the UFS clocks are scaled up or down,
> > improving performance and maintaining stability for crypto operations.
> > 
> > Incase of OPP scaling is not supported by ICE, ensure to not prevent
> > devfreq for UFS, as ICE OPP-table is optional.
> > 
> > Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> > Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> > ---
> >  drivers/ufs/host/ufs-qcom.c | 21 ++++++++++++++++++++-
> 
> 
> SCSI/UFS is not respecting subsystem boundaries, thus you must not
> combine multiple subsystem when targeting UFS.
> 
> Please split your patches.

Sorry, if I fail to understand the context here.
This patch-series is already split into 4 patches based on the subsystem.

If the concern is the UFS patch mixing subsystem explanations,
I can refine the commit message.

Otherwise, if you expect the UFS patch to be sent as a separate patch-series,
please let me know — though I feel these patches are more appropriate to
land together as they are quite related.

Abhinaba Rakshit

Re: [PATCH v6 3/4] ufs: host: Add ICE clock scaling during UFS clock changes

[Krzysztof Kozlowski]

On 25/02/2026 13:58, Abhinaba Rakshit wrote:
> On Wed, Feb 25, 2026 at 10:00:12AM +0100, Krzysztof Kozlowski wrote:
>> On 19/02/2026 10:39, Abhinaba Rakshit wrote:
>>> Implement ICE (Inline Crypto Engine) clock scaling in sync with
>>> UFS controller clock scaling. This ensures that the ICE operates at
>>> an appropriate frequency when the UFS clocks are scaled up or down,
>>> improving performance and maintaining stability for crypto operations.
>>>
>>> Incase of OPP scaling is not supported by ICE, ensure to not prevent
>>> devfreq for UFS, as ICE OPP-table is optional.
>>>
>>> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
>>> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
>>> ---
>>>  drivers/ufs/host/ufs-qcom.c | 21 ++++++++++++++++++++-
>>
>>
>> SCSI/UFS is not respecting subsystem boundaries, thus you must not
>> combine multiple subsystem when targeting UFS.
>>
>> Please split your patches.
> 
> Sorry, if I fail to understand the context here.
> This patch-series is already split into 4 patches based on the subsystem.

s/patches/patchset/
Please split the patchset to not combine independent patches targeting
different subsystem into one patchset.

Best regards,
Krzysztof

Re: [PATCH v6 3/4] ufs: host: Add ICE clock scaling during UFS clock changes

[Abhinaba Rakshit]

On Wed, Feb 25, 2026 at 03:12:18PM +0100, Krzysztof Kozlowski wrote:
> On 25/02/2026 13:58, Abhinaba Rakshit wrote:
> > On Wed, Feb 25, 2026 at 10:00:12AM +0100, Krzysztof Kozlowski wrote:
> >> On 19/02/2026 10:39, Abhinaba Rakshit wrote:
> >>> Implement ICE (Inline Crypto Engine) clock scaling in sync with
> >>> UFS controller clock scaling. This ensures that the ICE operates at
> >>> an appropriate frequency when the UFS clocks are scaled up or down,
> >>> improving performance and maintaining stability for crypto operations.
> >>>
> >>> Incase of OPP scaling is not supported by ICE, ensure to not prevent
> >>> devfreq for UFS, as ICE OPP-table is optional.
> >>>
> >>> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> >>> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> >>> ---
> >>>  drivers/ufs/host/ufs-qcom.c | 21 ++++++++++++++++++++-
> >>
> >>
> >> SCSI/UFS is not respecting subsystem boundaries, thus you must not
> >> combine multiple subsystem when targeting UFS.
> >>
> >> Please split your patches.
> > 
> > Sorry, if I fail to understand the context here.
> > This patch-series is already split into 4 patches based on the subsystem.
> 
> s/patches/patchset/
> Please split the patchset to not combine independent patches targeting
> different subsystem into one patchset.

In this series, the UFS subsystem patch depends on the new ICE clock-scaling
API introduced in the crypto/ICE patch. Without that ICE change, the UFS
driver cannot call the scaling helper, so the UFS subsystem patch cannot
be applied *independently*.

Given this dependency, splitting the series into separate, standalone
patchsets would break bisectability and lead to build/runtime failures
if they are not merged together.

Please let me know what is the preferred approach in such instance.

Abhinaba Rakshit

Re: [PATCH v6 3/4] ufs: host: Add ICE clock scaling during UFS clock changes

[Krzysztof Kozlowski]

On 26/02/2026 07:14, Abhinaba Rakshit wrote:
> On Wed, Feb 25, 2026 at 03:12:18PM +0100, Krzysztof Kozlowski wrote:
>> On 25/02/2026 13:58, Abhinaba Rakshit wrote:
>>> On Wed, Feb 25, 2026 at 10:00:12AM +0100, Krzysztof Kozlowski wrote:
>>>> On 19/02/2026 10:39, Abhinaba Rakshit wrote:
>>>>> Implement ICE (Inline Crypto Engine) clock scaling in sync with
>>>>> UFS controller clock scaling. This ensures that the ICE operates at
>>>>> an appropriate frequency when the UFS clocks are scaled up or down,
>>>>> improving performance and maintaining stability for crypto operations.
>>>>>
>>>>> Incase of OPP scaling is not supported by ICE, ensure to not prevent
>>>>> devfreq for UFS, as ICE OPP-table is optional.
>>>>>
>>>>> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
>>>>> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
>>>>> ---
>>>>>  drivers/ufs/host/ufs-qcom.c | 21 ++++++++++++++++++++-
>>>>
>>>>
>>>> SCSI/UFS is not respecting subsystem boundaries, thus you must not
>>>> combine multiple subsystem when targeting UFS.
>>>>
>>>> Please split your patches.
>>>
>>> Sorry, if I fail to understand the context here.
>>> This patch-series is already split into 4 patches based on the subsystem.
>>
>> s/patches/patchset/
>> Please split the patchset to not combine independent patches targeting
>> different subsystem into one patchset.
> 
> In this series, the UFS subsystem patch depends on the new ICE clock-scaling
> API introduced in the crypto/ICE patch. Without that ICE change, the UFS
> driver cannot call the scaling helper, so the UFS subsystem patch cannot
> be applied *independently*.

What? Where is this explained in the cover letter? Where is merging
dependencies/order mentioned?
> 
> Given this dependency, splitting the series into separate, standalone
> patchsets would break bisectability and lead to build/runtime failures
> if they are not merged together.
> 
> Please let me know what is the preferred approach in such instance.
> 
> Abhinaba Rakshit


Best regards,
Krzysztof

Re: [PATCH v6 3/4] ufs: host: Add ICE clock scaling during UFS clock changes

[Abhinaba Rakshit]

On Thu, Feb 26, 2026 at 07:40:04AM +0100, Krzysztof Kozlowski wrote:
> On 26/02/2026 07:14, Abhinaba Rakshit wrote:
> > On Wed, Feb 25, 2026 at 03:12:18PM +0100, Krzysztof Kozlowski wrote:
> >> On 25/02/2026 13:58, Abhinaba Rakshit wrote:
> >>> On Wed, Feb 25, 2026 at 10:00:12AM +0100, Krzysztof Kozlowski wrote:
> >>>> On 19/02/2026 10:39, Abhinaba Rakshit wrote:
> >>>>> Implement ICE (Inline Crypto Engine) clock scaling in sync with
> >>>>> UFS controller clock scaling. This ensures that the ICE operates at
> >>>>> an appropriate frequency when the UFS clocks are scaled up or down,
> >>>>> improving performance and maintaining stability for crypto operations.
> >>>>>
> >>>>> Incase of OPP scaling is not supported by ICE, ensure to not prevent
> >>>>> devfreq for UFS, as ICE OPP-table is optional.
> >>>>>
> >>>>> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> >>>>> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> >>>>> ---
> >>>>>  drivers/ufs/host/ufs-qcom.c | 21 ++++++++++++++++++++-
> >>>>
> >>>>
> >>>> SCSI/UFS is not respecting subsystem boundaries, thus you must not
> >>>> combine multiple subsystem when targeting UFS.
> >>>>
> >>>> Please split your patches.
> >>>
> >>> Sorry, if I fail to understand the context here.
> >>> This patch-series is already split into 4 patches based on the subsystem.
> >>
> >> s/patches/patchset/
> >> Please split the patchset to not combine independent patches targeting
> >> different subsystem into one patchset.
> > 
> > In this series, the UFS subsystem patch depends on the new ICE clock-scaling
> > API introduced in the crypto/ICE patch. Without that ICE change, the UFS
> > driver cannot call the scaling helper, so the UFS subsystem patch cannot
> > be applied *independently*.
> 
> What? Where is this explained in the cover letter? Where is merging
> dependencies/order mentioned?

Get it.
Will ensure to add the details on patch dependencies and merge order
in the next patchset.

Abhinaba Rakshit

Re: [PATCH v6 1/4] dt-bindings: crypto: ice: add operating-points-v2 property for QCOM ICE

[Herbert Xu]

On Thu, Feb 19, 2026 at 03:09:13PM +0530, Abhinaba Rakshit wrote:
> Add support for specifying OPPs for the Qualcomm Inline Crypto Engine
> by allowing the use of the standard "operating-points-v2" property in
> the ICE device node.
> 
> ICE clock management was handled by the storage drivers in legacy
> bindings, so the ICE driver itself had no mechanism for clock scaling.
> With the introduction of the new standalone ICE device node, clock
> control must now be performed directly by the ICE driver. Enabling
> operating-points-v2 allows the driver to describe and manage the
> frequency and voltage requirements for proper DVFS operation.
> 
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
>  .../bindings/crypto/qcom,inline-crypto-engine.yaml | 26 ++++++++++++++++++++++
>  1 file changed, 26 insertions(+)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt