[PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Linlin Zhang]

The QCOM ICE driver manages the ICE core clock through direct calls to
clk_prepare_enable() and clk_disable_unprepare(), which limits integration
with platforms that rely on firmware-managed resources or platform-specific
power management mechanisms.

Replace direct clock management with runtime PM support by moving clock
enable and disable into runtime PM callbacks. Use
pm_runtime_resume_and_get() and pm_runtime_put_sync() in qcom_ice_resume()
and qcom_ice_suspend() to drive power state transitions, and enable runtime
PM in qcom_ice_probe().

Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
Reviewed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
---
 drivers/soc/qcom/ice.c | 58 ++++++++++++++++++++++++++++++++++++++----
 1 file changed, 53 insertions(+), 5 deletions(-)

diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index b203bc685cad..6f9d679b530c 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_runtime.h>
 
 #include <linux/firmware/qcom/qcom_scm.h>
 
@@ -310,8 +311,8 @@ int qcom_ice_resume(struct qcom_ice *ice)
 	struct device *dev = ice->dev;
 	int err;
 
-	err = clk_prepare_enable(ice->core_clk);
-	if (err) {
+	err = pm_runtime_resume_and_get(dev);
+	if (err < 0) {
 		dev_err(dev, "failed to enable core clock (%d)\n",
 			err);
 		return err;
@@ -323,7 +324,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
 
 int qcom_ice_suspend(struct qcom_ice *ice)
 {
-	clk_disable_unprepare(ice->core_clk);
+	pm_runtime_put_sync(ice->dev);
 	ice->hwkm_init_complete = false;
 
 	return 0;
@@ -716,24 +717,69 @@ EXPORT_SYMBOL_GPL(devm_of_qcom_ice_get);
 
 static int qcom_ice_probe(struct platform_device *pdev)
 {
+	struct device *dev = &pdev->dev;
 	struct qcom_ice *engine;
 	void __iomem *base;
+	int ret;
 
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(base)) {
-		dev_warn(&pdev->dev, "ICE registers not found\n");
+		dev_warn(dev, "ICE registers not found\n");
 		return PTR_ERR(base);
 	}
 
-	engine = qcom_ice_create(&pdev->dev, base);
+	engine = qcom_ice_create(dev, base);
 	if (IS_ERR(engine))
 		return PTR_ERR(engine);
 
 	platform_set_drvdata(pdev, engine);
 
+	ret = devm_pm_runtime_enable(dev);
+	if (ret) {
+		dev_warn(dev, "Enable runtime PM failed, ret: %d\n", ret);
+		return ret;
+	}
+
+	ret = pm_runtime_resume_and_get(dev);
+	if (ret < 0) {
+		dev_warn(dev, "Runtime PM fails to resume, ret: %d\n", ret);
+		return ret;
+	}
+
 	return 0;
 }
 
+static void qcom_ice_remove(struct platform_device *pdev)
+{
+	pm_runtime_put_sync(&pdev->dev);
+}
+
+static int ice_runtime_resume(struct device *dev)
+{
+	struct qcom_ice *ice = dev_get_drvdata(dev);
+	int err = 0;
+
+	err = clk_prepare_enable(ice->core_clk);
+	if (err) {
+		dev_err(dev, "failed to enable core clock (%d)\n",
+			err);
+	}
+
+	return err;
+}
+
+static int ice_runtime_suspend(struct device *dev)
+{
+	struct qcom_ice *ice = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(ice->core_clk);
+	return 0;
+}
+
+static const struct dev_pm_ops ice_pm_ops = {
+	SET_RUNTIME_PM_OPS(ice_runtime_suspend, ice_runtime_resume, NULL)
+};
+
 static const struct of_device_id qcom_ice_of_match_table[] = {
 	{ .compatible = "qcom,inline-crypto-engine" },
 	{ },
@@ -742,8 +788,10 @@ MODULE_DEVICE_TABLE(of, qcom_ice_of_match_table);
 
 static struct platform_driver qcom_ice_driver = {
 	.probe	= qcom_ice_probe,
+	.remove = qcom_ice_remove,
 	.driver = {
 		.name = "qcom-ice",
+		.pm = &ice_pm_ops,
 		.of_match_table = qcom_ice_of_match_table,
 	},
 };
-- 
2.34.1

[PATCH v2 3/3] soc: qcom: ice: Add SCMI support for sa8255p based targets

[Linlin Zhang]

The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power
and performance protocols.

The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power states(on/off).

The SCMI performance protocol manages ICE clock, with a power domain
set for ICE clock. The driver uses runtime PM framework APIs to
request power on/off status of the clock.

Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
Reviewed-by: Deepti Jaggi <quic_djaggi@quicinc.com>
Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
---
 drivers/soc/qcom/ice.c | 64 ++++++++++++++++++++++++++++--------------
 1 file changed, 43 insertions(+), 21 deletions(-)

diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index 6f9d679b530c..cf185a6e1973 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -68,6 +68,10 @@ union crypto_cfg {
 	};
 };
 
+struct engine_desc {
+	bool fw_managed;
+};
+
 /* QCOM ICE HWKM (Hardware Key Manager) registers */
 
 #define HWKM_OFFSET				0x8000
@@ -554,6 +558,7 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
 					void __iomem *base)
 {
 	struct qcom_ice *engine;
+	const struct engine_desc *engine_cfg = NULL;
 
 	if (!qcom_scm_is_available())
 		return ERR_PTR(-EPROBE_DEFER);
@@ -570,20 +575,23 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
 	engine->dev = dev;
 	engine->base = base;
 
-	/*
-	 * Legacy DT binding uses different clk names for each consumer,
-	 * so lets try those first. If none of those are a match, it means
-	 * the we only have one clock and it is part of the dedicated DT node.
-	 * Also, enable the clock before we check what HW version the driver
-	 * supports.
-	 */
-	engine->core_clk = devm_clk_get_optional_enabled(dev, "ice_core_clk");
-	if (!engine->core_clk)
-		engine->core_clk = devm_clk_get_optional_enabled(dev, "ice");
-	if (!engine->core_clk)
-		engine->core_clk = devm_clk_get_enabled(dev, NULL);
-	if (IS_ERR(engine->core_clk))
-		return ERR_CAST(engine->core_clk);
+	engine_cfg = device_get_match_data(dev);
+	if (!engine_cfg || !engine_cfg->fw_managed) {
+		/*
+		 * Legacy DT binding uses different clk names for each consumer,
+		 * so lets try those first. If none of those are a match, it means
+		 * the we only have one clock and it is part of the dedicated DT node.
+		 * Also, enable the clock before we check what HW version the driver
+		 * supports.
+		 */
+		engine->core_clk = devm_clk_get_optional_enabled(dev, "ice_core_clk");
+		if (!engine->core_clk)
+			engine->core_clk = devm_clk_get_optional_enabled(dev, "ice");
+		if (!engine->core_clk)
+			engine->core_clk = devm_clk_get_enabled(dev, NULL);
+		if (IS_ERR(engine->core_clk))
+			return ERR_CAST(engine->core_clk);
+	}
 
 	if (!qcom_ice_check_supported(engine))
 		return ERR_PTR(-EOPNOTSUPP);
@@ -756,13 +764,17 @@ static void qcom_ice_remove(struct platform_device *pdev)
 
 static int ice_runtime_resume(struct device *dev)
 {
-	struct qcom_ice *ice = dev_get_drvdata(dev);
+	struct engine_desc *engine_cfg = device_get_match_data(dev);
 	int err = 0;
 
-	err = clk_prepare_enable(ice->core_clk);
-	if (err) {
-		dev_err(dev, "failed to enable core clock (%d)\n",
-			err);
+	if (!engine_cfg || !engine_cfg->fw_managed) {
+		struct qcom_ice *ice = dev_get_drvdata(dev);
+
+		err = clk_prepare_enable(ice->core_clk);
+		if (err) {
+			dev_err(dev, "failed to enable core clock (%d)\n",
+				err);
+		}
 	}
 
 	return err;
@@ -770,9 +782,14 @@ static int ice_runtime_resume(struct device *dev)
 
 static int ice_runtime_suspend(struct device *dev)
 {
-	struct qcom_ice *ice = dev_get_drvdata(dev);
+	const struct engine_desc *engine_cfg = device_get_match_data(dev);
+
+	if (!engine_cfg || !engine_cfg->fw_managed) {
+		struct qcom_ice *ice = dev_get_drvdata(dev);
+
+		clk_disable_unprepare(ice->core_clk);
+	}
 
-	clk_disable_unprepare(ice->core_clk);
 	return 0;
 }
 
@@ -780,8 +797,13 @@ static const struct dev_pm_ops ice_pm_ops = {
 	SET_RUNTIME_PM_OPS(ice_runtime_suspend, ice_runtime_resume, NULL)
 };
 
+static const struct engine_desc cfg_fw_managed = {
+	.fw_managed = true,
+};
+
 static const struct of_device_id qcom_ice_of_match_table[] = {
 	{ .compatible = "qcom,inline-crypto-engine" },
+	{ .compatible = "qcom,sa8255p-inline-crypto-engine", .data = &cfg_fw_managed },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, qcom_ice_of_match_table);
-- 
2.34.1

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Bjorn Andersson]

On Thu, May 07, 2026 at 04:26:24AM -0700, Linlin Zhang wrote:

I only got 2 of the 3 patches, and no cover letter. I can see in the
mail headers that you have:

 X-Mailer: git-send-email 2.25.1

Use b4 to avoid this kind of mistakes.

Regards,
Bjorn

> The QCOM ICE driver manages the ICE core clock through direct calls to
> clk_prepare_enable() and clk_disable_unprepare(), which limits integration
> with platforms that rely on firmware-managed resources or platform-specific
> power management mechanisms.
> 
> Replace direct clock management with runtime PM support by moving clock
> enable and disable into runtime PM callbacks. Use
> pm_runtime_resume_and_get() and pm_runtime_put_sync() in qcom_ice_resume()
> and qcom_ice_suspend() to drive power state transitions, and enable runtime
> PM in qcom_ice_probe().
> 
> Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
> Reviewed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> ---
>  drivers/soc/qcom/ice.c | 58 ++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 53 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index b203bc685cad..6f9d679b530c 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_runtime.h>
>  
>  #include <linux/firmware/qcom/qcom_scm.h>
>  
> @@ -310,8 +311,8 @@ int qcom_ice_resume(struct qcom_ice *ice)
>  	struct device *dev = ice->dev;
>  	int err;
>  
> -	err = clk_prepare_enable(ice->core_clk);
> -	if (err) {
> +	err = pm_runtime_resume_and_get(dev);
> +	if (err < 0) {
>  		dev_err(dev, "failed to enable core clock (%d)\n",
>  			err);
>  		return err;
> @@ -323,7 +324,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
>  
>  int qcom_ice_suspend(struct qcom_ice *ice)
>  {
> -	clk_disable_unprepare(ice->core_clk);
> +	pm_runtime_put_sync(ice->dev);
>  	ice->hwkm_init_complete = false;
>  
>  	return 0;
> @@ -716,24 +717,69 @@ EXPORT_SYMBOL_GPL(devm_of_qcom_ice_get);
>  
>  static int qcom_ice_probe(struct platform_device *pdev)
>  {
> +	struct device *dev = &pdev->dev;
>  	struct qcom_ice *engine;
>  	void __iomem *base;
> +	int ret;
>  
>  	base = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(base)) {
> -		dev_warn(&pdev->dev, "ICE registers not found\n");
> +		dev_warn(dev, "ICE registers not found\n");
>  		return PTR_ERR(base);
>  	}
>  
> -	engine = qcom_ice_create(&pdev->dev, base);
> +	engine = qcom_ice_create(dev, base);
>  	if (IS_ERR(engine))
>  		return PTR_ERR(engine);
>  
>  	platform_set_drvdata(pdev, engine);
>  
> +	ret = devm_pm_runtime_enable(dev);
> +	if (ret) {
> +		dev_warn(dev, "Enable runtime PM failed, ret: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = pm_runtime_resume_and_get(dev);
> +	if (ret < 0) {
> +		dev_warn(dev, "Runtime PM fails to resume, ret: %d\n", ret);
> +		return ret;
> +	}
> +
>  	return 0;
>  }
>  
> +static void qcom_ice_remove(struct platform_device *pdev)
> +{
> +	pm_runtime_put_sync(&pdev->dev);
> +}
> +
> +static int ice_runtime_resume(struct device *dev)
> +{
> +	struct qcom_ice *ice = dev_get_drvdata(dev);
> +	int err = 0;
> +
> +	err = clk_prepare_enable(ice->core_clk);
> +	if (err) {
> +		dev_err(dev, "failed to enable core clock (%d)\n",
> +			err);
> +	}
> +
> +	return err;
> +}
> +
> +static int ice_runtime_suspend(struct device *dev)
> +{
> +	struct qcom_ice *ice = dev_get_drvdata(dev);
> +
> +	clk_disable_unprepare(ice->core_clk);
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops ice_pm_ops = {
> +	SET_RUNTIME_PM_OPS(ice_runtime_suspend, ice_runtime_resume, NULL)
> +};
> +
>  static const struct of_device_id qcom_ice_of_match_table[] = {
>  	{ .compatible = "qcom,inline-crypto-engine" },
>  	{ },
> @@ -742,8 +788,10 @@ MODULE_DEVICE_TABLE(of, qcom_ice_of_match_table);
>  
>  static struct platform_driver qcom_ice_driver = {
>  	.probe	= qcom_ice_probe,
> +	.remove = qcom_ice_remove,
>  	.driver = {
>  		.name = "qcom-ice",
> +		.pm = &ice_pm_ops,
>  		.of_match_table = qcom_ice_of_match_table,
>  	},
>  };
> -- 
> 2.34.1
> 

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Linlin Zhang]

On 5/8/2026 5:19 AM, Bjorn Andersson wrote:
> On Thu, May 07, 2026 at 04:26:24AM -0700, Linlin Zhang wrote:
> 
> I only got 2 of the 3 patches, and no cover letter. I can see in the
> mail headers that you have:
> 
>  X-Mailer: git-send-email 2.25.1
> 
> Use b4 to avoid this kind of mistakes.

Thank you for the clarification.

I followed an incorrect suggestion to split the original patch series,
intending to send different patches to different maintainers. It turns out
this was a mistake and resulted in an incomplete series being delivered.

The missing cover letter and the other patch are available here:
https://lore.kernel.org/all/20260507112454.2527088-1-linlin.zhang@oss.qualcomm.com/

I will resend the full series (cover letter and all patches) together as a
single patch set.

Sorry for the confusion, and thanks for your patience.

> 
> Regards,
> Bjorn
> 
>> The QCOM ICE driver manages the ICE core clock through direct calls to
>> clk_prepare_enable() and clk_disable_unprepare(), which limits integration
>> with platforms that rely on firmware-managed resources or platform-specific
>> power management mechanisms.
>>
>> Replace direct clock management with runtime PM support by moving clock
>> enable and disable into runtime PM callbacks. Use
>> pm_runtime_resume_and_get() and pm_runtime_put_sync() in qcom_ice_resume()
>> and qcom_ice_suspend() to drive power state transitions, and enable runtime
>> PM in qcom_ice_probe().
>>
>> Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
>> Reviewed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>> ---
>>  drivers/soc/qcom/ice.c | 58 ++++++++++++++++++++++++++++++++++++++----
>>  1 file changed, 53 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
>> index b203bc685cad..6f9d679b530c 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_runtime.h>
>>  
>>  #include <linux/firmware/qcom/qcom_scm.h>
>>  
>> @@ -310,8 +311,8 @@ int qcom_ice_resume(struct qcom_ice *ice)
>>  	struct device *dev = ice->dev;
>>  	int err;
>>  
>> -	err = clk_prepare_enable(ice->core_clk);
>> -	if (err) {
>> +	err = pm_runtime_resume_and_get(dev);
>> +	if (err < 0) {
>>  		dev_err(dev, "failed to enable core clock (%d)\n",
>>  			err);
>>  		return err;
>> @@ -323,7 +324,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
>>  
>>  int qcom_ice_suspend(struct qcom_ice *ice)
>>  {
>> -	clk_disable_unprepare(ice->core_clk);
>> +	pm_runtime_put_sync(ice->dev);
>>  	ice->hwkm_init_complete = false;
>>  
>>  	return 0;
>> @@ -716,24 +717,69 @@ EXPORT_SYMBOL_GPL(devm_of_qcom_ice_get);
>>  
>>  static int qcom_ice_probe(struct platform_device *pdev)
>>  {
>> +	struct device *dev = &pdev->dev;
>>  	struct qcom_ice *engine;
>>  	void __iomem *base;
>> +	int ret;
>>  
>>  	base = devm_platform_ioremap_resource(pdev, 0);
>>  	if (IS_ERR(base)) {
>> -		dev_warn(&pdev->dev, "ICE registers not found\n");
>> +		dev_warn(dev, "ICE registers not found\n");
>>  		return PTR_ERR(base);
>>  	}
>>  
>> -	engine = qcom_ice_create(&pdev->dev, base);
>> +	engine = qcom_ice_create(dev, base);
>>  	if (IS_ERR(engine))
>>  		return PTR_ERR(engine);
>>  
>>  	platform_set_drvdata(pdev, engine);
>>  
>> +	ret = devm_pm_runtime_enable(dev);
>> +	if (ret) {
>> +		dev_warn(dev, "Enable runtime PM failed, ret: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	ret = pm_runtime_resume_and_get(dev);
>> +	if (ret < 0) {
>> +		dev_warn(dev, "Runtime PM fails to resume, ret: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>>  	return 0;
>>  }
>>  
>> +static void qcom_ice_remove(struct platform_device *pdev)
>> +{
>> +	pm_runtime_put_sync(&pdev->dev);
>> +}
>> +
>> +static int ice_runtime_resume(struct device *dev)
>> +{
>> +	struct qcom_ice *ice = dev_get_drvdata(dev);
>> +	int err = 0;
>> +
>> +	err = clk_prepare_enable(ice->core_clk);
>> +	if (err) {
>> +		dev_err(dev, "failed to enable core clock (%d)\n",
>> +			err);
>> +	}
>> +
>> +	return err;
>> +}
>> +
>> +static int ice_runtime_suspend(struct device *dev)
>> +{
>> +	struct qcom_ice *ice = dev_get_drvdata(dev);
>> +
>> +	clk_disable_unprepare(ice->core_clk);
>> +	return 0;
>> +}
>> +
>> +static const struct dev_pm_ops ice_pm_ops = {
>> +	SET_RUNTIME_PM_OPS(ice_runtime_suspend, ice_runtime_resume, NULL)
>> +};
>> +
>>  static const struct of_device_id qcom_ice_of_match_table[] = {
>>  	{ .compatible = "qcom,inline-crypto-engine" },
>>  	{ },
>> @@ -742,8 +788,10 @@ MODULE_DEVICE_TABLE(of, qcom_ice_of_match_table);
>>  
>>  static struct platform_driver qcom_ice_driver = {
>>  	.probe	= qcom_ice_probe,
>> +	.remove = qcom_ice_remove,
>>  	.driver = {
>>  		.name = "qcom-ice",
>> +		.pm = &ice_pm_ops,
>>  		.of_match_table = qcom_ice_of_match_table,
>>  	},
>>  };
>> -- 
>> 2.34.1
>>

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Krzysztof Kozlowski]

On 18/08/2026 09:35, Linlin Zhang wrote:
> 
> 
> On 8/18/2026 3:30 PM, Linlin Zhang wrote:
>>
>>
>> On 5/15/2026 10:48 PM, Krzysztof Kozlowski wrote:
>>> On 15/05/2026 16:22, Linlin Zhang wrote:
>>>>
>>>> Hi Krzysztof,
>>>>
>>>> Thanks for the review.
>>>>
>>>> For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
>>>> clocks are not controlled directly by the ICE driver. Instead, they are
>>>> managed by remote firmware and exposed to Linux via power domains. As a
>>>> result, the ICE driver cannot use clk_prepare_enable() directly to
>>>> control the hardware clock.
>>>>
>>>> The intention of moving the clock handling into runtime PM callbacks is
>>>> to align the ICE driver with the power domain framework used on these
>>>> platforms. When the ICE device is attached to a power domain, invoking
>>>> pm_runtime_resume_and_get() will trigger the provider (remote firmware
>>>> via SCMI) to power up the device, which in turn enables the underlying
>>>> clock and other resources.
>>>>
>>>> This design follows the guidance where the runtime PM framework is
>>>> used as the common mechanism to abstract both:
>>>>   - direct clock control on non-SCMI platforms, and
>>>>   - firmware-controlled resources via power domains on SCMI platforms.
>>>>
>>>> In both cases, the runtime PM callbacks are responsible for performing
>>>> the actual resource enable/disable:
>>>>   - for legacy platforms: clk_prepare_enable()/disable_unprepare()
>>>>   - for SCMI platforms: power domain on/off handled by firmware
>>>>
>>>> So while it may look like an additional layer on legacy platforms, this
>>>> approach provides a unified mechanism without requiring separate driver
>>>> entry points or special handling in the upper layers (e.g. UFS driver).
>>>>
>>>> That said, I understand your concern that introducing runtime PM solely
>>>> for clock gating can be seen as unnecessary overhead on existing
>>>> platforms. I will revisit the implementation to ensure that:
>>>>   - the runtime PM integration does not introduce regressions for legacy
>>>>     platforms, and
>>>>   - the design clearly justifies the common abstraction for both SCMI
>>>>     and non-SCMI cases.
>>>>
>>>> In addition, I rewrite the commit message as the following to make the
>>>> intention more clear.
>>>>
>>>>   On some platforms the ICE device is placed in a firmware-managed power
>>>>   domain. In those cases the ICE core resources (including the clock) are
>>>>   not directly controllable by Linux and are instead toggled by the power
>>>>   domain provider (e.g. remote firmware via SCMI).
>>>>
>>>>   Wire the ICE device into runtime PM so that a single pm_runtime
>>>>   transition is used to bring the ICE device up/down. When the device is
>>>>   attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
>>>>   will invoke the PM domain callbacks and let the provider manage the
>>>>   resources. On platforms without a PM domain the runtime PM callbacks
>>>>   continue to perform the existing clock enable/disable locally.
>>>>
>>>>   No functional change is intended for non-firmware-managed platforms; the
>>>>   change provides a common control point that allows ICE to operate when
>>>>   resources are owned by a PM domain provider.
>>>>
>>>
>>>
>>> Nothing here resolves the comments. Also, it's top posted. Honestly, I
>>> won't be talking through you with LLM, so consider patch NAKed.
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Sorry for the late due to personal matters. 
>>
>> At that time, I reviewed your comments one by one and provided answers, then
>> let AI polish the answer.
>>
>> I'll add new replies after your comments point by point.
>>
>> Thanks for the review.
>>
> 
> Alternatively, if you would prefer to review a revised patch series that
> incorporates the changes we have already agreed upon for patches 0/3 and 1/3,
> please let me know and I would be happy to prepare it.

You received review which you did not implement. Reviewing such code
again is waste of time. Pasting excessively long, unparseable LLM
outputs is just another way to waste time of reviewers. Pasting here
result, intention or instructions for LLM is another thing not to do,
recently there is plague of this. We are not your LLM. We are not going
to talk with your LLM through you. We are not going to receive your prompts.

NAK

Best regards,
Krzysztof

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Linlin Zhang]

On 8/18/2026 3:30 PM, Linlin Zhang wrote:
> 
> 
> On 5/15/2026 10:48 PM, Krzysztof Kozlowski wrote:
>> On 15/05/2026 16:22, Linlin Zhang wrote:
>>>
>>> Hi Krzysztof,
>>>
>>> Thanks for the review.
>>>
>>> For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
>>> clocks are not controlled directly by the ICE driver. Instead, they are
>>> managed by remote firmware and exposed to Linux via power domains. As a
>>> result, the ICE driver cannot use clk_prepare_enable() directly to
>>> control the hardware clock.
>>>
>>> The intention of moving the clock handling into runtime PM callbacks is
>>> to align the ICE driver with the power domain framework used on these
>>> platforms. When the ICE device is attached to a power domain, invoking
>>> pm_runtime_resume_and_get() will trigger the provider (remote firmware
>>> via SCMI) to power up the device, which in turn enables the underlying
>>> clock and other resources.
>>>
>>> This design follows the guidance where the runtime PM framework is
>>> used as the common mechanism to abstract both:
>>>   - direct clock control on non-SCMI platforms, and
>>>   - firmware-controlled resources via power domains on SCMI platforms.
>>>
>>> In both cases, the runtime PM callbacks are responsible for performing
>>> the actual resource enable/disable:
>>>   - for legacy platforms: clk_prepare_enable()/disable_unprepare()
>>>   - for SCMI platforms: power domain on/off handled by firmware
>>>
>>> So while it may look like an additional layer on legacy platforms, this
>>> approach provides a unified mechanism without requiring separate driver
>>> entry points or special handling in the upper layers (e.g. UFS driver).
>>>
>>> That said, I understand your concern that introducing runtime PM solely
>>> for clock gating can be seen as unnecessary overhead on existing
>>> platforms. I will revisit the implementation to ensure that:
>>>   - the runtime PM integration does not introduce regressions for legacy
>>>     platforms, and
>>>   - the design clearly justifies the common abstraction for both SCMI
>>>     and non-SCMI cases.
>>>
>>> In addition, I rewrite the commit message as the following to make the
>>> intention more clear.
>>>
>>>   On some platforms the ICE device is placed in a firmware-managed power
>>>   domain. In those cases the ICE core resources (including the clock) are
>>>   not directly controllable by Linux and are instead toggled by the power
>>>   domain provider (e.g. remote firmware via SCMI).
>>>
>>>   Wire the ICE device into runtime PM so that a single pm_runtime
>>>   transition is used to bring the ICE device up/down. When the device is
>>>   attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
>>>   will invoke the PM domain callbacks and let the provider manage the
>>>   resources. On platforms without a PM domain the runtime PM callbacks
>>>   continue to perform the existing clock enable/disable locally.
>>>
>>>   No functional change is intended for non-firmware-managed platforms; the
>>>   change provides a common control point that allows ICE to operate when
>>>   resources are owned by a PM domain provider.
>>>
>>
>>
>> Nothing here resolves the comments. Also, it's top posted. Honestly, I
>> won't be talking through you with LLM, so consider patch NAKed.
>>
>> Best regards,
>> Krzysztof
> 
> Sorry for the late due to personal matters. 
> 
> At that time, I reviewed your comments one by one and provided answers, then
> let AI polish the answer.
> 
> I'll add new replies after your comments point by point.
> 
> Thanks for the review.
> 

Alternatively, if you would prefer to review a revised patch series that
incorporates the changes we have already agreed upon for patches 0/3 and 1/3,
please let me know and I would be happy to prepare it.

Thanks

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Linlin Zhang]

On 5/15/2026 10:48 PM, Krzysztof Kozlowski wrote:
> On 15/05/2026 16:22, Linlin Zhang wrote:
>>
>> Hi Krzysztof,
>>
>> Thanks for the review.
>>
>> For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
>> clocks are not controlled directly by the ICE driver. Instead, they are
>> managed by remote firmware and exposed to Linux via power domains. As a
>> result, the ICE driver cannot use clk_prepare_enable() directly to
>> control the hardware clock.
>>
>> The intention of moving the clock handling into runtime PM callbacks is
>> to align the ICE driver with the power domain framework used on these
>> platforms. When the ICE device is attached to a power domain, invoking
>> pm_runtime_resume_and_get() will trigger the provider (remote firmware
>> via SCMI) to power up the device, which in turn enables the underlying
>> clock and other resources.
>>
>> This design follows the guidance where the runtime PM framework is
>> used as the common mechanism to abstract both:
>>   - direct clock control on non-SCMI platforms, and
>>   - firmware-controlled resources via power domains on SCMI platforms.
>>
>> In both cases, the runtime PM callbacks are responsible for performing
>> the actual resource enable/disable:
>>   - for legacy platforms: clk_prepare_enable()/disable_unprepare()
>>   - for SCMI platforms: power domain on/off handled by firmware
>>
>> So while it may look like an additional layer on legacy platforms, this
>> approach provides a unified mechanism without requiring separate driver
>> entry points or special handling in the upper layers (e.g. UFS driver).
>>
>> That said, I understand your concern that introducing runtime PM solely
>> for clock gating can be seen as unnecessary overhead on existing
>> platforms. I will revisit the implementation to ensure that:
>>   - the runtime PM integration does not introduce regressions for legacy
>>     platforms, and
>>   - the design clearly justifies the common abstraction for both SCMI
>>     and non-SCMI cases.
>>
>> In addition, I rewrite the commit message as the following to make the
>> intention more clear.
>>
>>   On some platforms the ICE device is placed in a firmware-managed power
>>   domain. In those cases the ICE core resources (including the clock) are
>>   not directly controllable by Linux and are instead toggled by the power
>>   domain provider (e.g. remote firmware via SCMI).
>>
>>   Wire the ICE device into runtime PM so that a single pm_runtime
>>   transition is used to bring the ICE device up/down. When the device is
>>   attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
>>   will invoke the PM domain callbacks and let the provider manage the
>>   resources. On platforms without a PM domain the runtime PM callbacks
>>   continue to perform the existing clock enable/disable locally.
>>
>>   No functional change is intended for non-firmware-managed platforms; the
>>   change provides a common control point that allows ICE to operate when
>>   resources are owned by a PM domain provider.
>>
> 
> 
> Nothing here resolves the comments. Also, it's top posted. Honestly, I
> won't be talking through you with LLM, so consider patch NAKed.
> 
> Best regards,
> Krzysztof

Sorry for the late due to personal matters. 

At that time, I reviewed your comments one by one and provided answers, then
let AI polish the answer.

I'll add new replies after your comments point by point.

Thanks for the review.

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Krzysztof Kozlowski]

On 15/05/2026 16:48, Krzysztof Kozlowski wrote:
> On 15/05/2026 16:22, Linlin Zhang wrote:
>>
>> Hi Krzysztof,
>>
>> Thanks for the review.
>>
>> For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
>> clocks are not controlled directly by the ICE driver. Instead, they are
>> managed by remote firmware and exposed to Linux via power domains. As a
>> result, the ICE driver cannot use clk_prepare_enable() directly to
>> control the hardware clock.
>>
>> The intention of moving the clock handling into runtime PM callbacks is
>> to align the ICE driver with the power domain framework used on these
>> platforms. When the ICE device is attached to a power domain, invoking
>> pm_runtime_resume_and_get() will trigger the provider (remote firmware
>> via SCMI) to power up the device, which in turn enables the underlying
>> clock and other resources.
>>
>> This design follows the guidance where the runtime PM framework is
>> used as the common mechanism to abstract both:
>>   - direct clock control on non-SCMI platforms, and
>>   - firmware-controlled resources via power domains on SCMI platforms.
>>
>> In both cases, the runtime PM callbacks are responsible for performing
>> the actual resource enable/disable:
>>   - for legacy platforms: clk_prepare_enable()/disable_unprepare()
>>   - for SCMI platforms: power domain on/off handled by firmware
>>
>> So while it may look like an additional layer on legacy platforms, this
>> approach provides a unified mechanism without requiring separate driver
>> entry points or special handling in the upper layers (e.g. UFS driver).
>>
>> That said, I understand your concern that introducing runtime PM solely
>> for clock gating can be seen as unnecessary overhead on existing
>> platforms. I will revisit the implementation to ensure that:
>>   - the runtime PM integration does not introduce regressions for legacy
>>     platforms, and
>>   - the design clearly justifies the common abstraction for both SCMI
>>     and non-SCMI cases.
>>
>> In addition, I rewrite the commit message as the following to make the
>> intention more clear.
>>
>>   On some platforms the ICE device is placed in a firmware-managed power
>>   domain. In those cases the ICE core resources (including the clock) are
>>   not directly controllable by Linux and are instead toggled by the power
>>   domain provider (e.g. remote firmware via SCMI).
>>
>>   Wire the ICE device into runtime PM so that a single pm_runtime
>>   transition is used to bring the ICE device up/down. When the device is
>>   attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
>>   will invoke the PM domain callbacks and let the provider manage the
>>   resources. On platforms without a PM domain the runtime PM callbacks
>>   continue to perform the existing clock enable/disable locally.
>>
>>   No functional change is intended for non-firmware-managed platforms; the
>>   change provides a common control point that allows ICE to operate when
>>   resources are owned by a PM domain provider.
>>
> 
> 
> Nothing here resolves the comments. Also, it's top posted. Honestly, I
> won't be talking through you with LLM, so consider patch NAKed.

Plus you completely ignored all the comments I posted in review. Great.

Best regards,
Krzysztof

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Krzysztof Kozlowski]

On 15/05/2026 16:22, Linlin Zhang wrote:
> 
> Hi Krzysztof,
> 
> Thanks for the review.
> 
> For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
> clocks are not controlled directly by the ICE driver. Instead, they are
> managed by remote firmware and exposed to Linux via power domains. As a
> result, the ICE driver cannot use clk_prepare_enable() directly to
> control the hardware clock.
> 
> The intention of moving the clock handling into runtime PM callbacks is
> to align the ICE driver with the power domain framework used on these
> platforms. When the ICE device is attached to a power domain, invoking
> pm_runtime_resume_and_get() will trigger the provider (remote firmware
> via SCMI) to power up the device, which in turn enables the underlying
> clock and other resources.
> 
> This design follows the guidance where the runtime PM framework is
> used as the common mechanism to abstract both:
>   - direct clock control on non-SCMI platforms, and
>   - firmware-controlled resources via power domains on SCMI platforms.
> 
> In both cases, the runtime PM callbacks are responsible for performing
> the actual resource enable/disable:
>   - for legacy platforms: clk_prepare_enable()/disable_unprepare()
>   - for SCMI platforms: power domain on/off handled by firmware
> 
> So while it may look like an additional layer on legacy platforms, this
> approach provides a unified mechanism without requiring separate driver
> entry points or special handling in the upper layers (e.g. UFS driver).
> 
> That said, I understand your concern that introducing runtime PM solely
> for clock gating can be seen as unnecessary overhead on existing
> platforms. I will revisit the implementation to ensure that:
>   - the runtime PM integration does not introduce regressions for legacy
>     platforms, and
>   - the design clearly justifies the common abstraction for both SCMI
>     and non-SCMI cases.
> 
> In addition, I rewrite the commit message as the following to make the
> intention more clear.
> 
>   On some platforms the ICE device is placed in a firmware-managed power
>   domain. In those cases the ICE core resources (including the clock) are
>   not directly controllable by Linux and are instead toggled by the power
>   domain provider (e.g. remote firmware via SCMI).
> 
>   Wire the ICE device into runtime PM so that a single pm_runtime
>   transition is used to bring the ICE device up/down. When the device is
>   attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
>   will invoke the PM domain callbacks and let the provider manage the
>   resources. On platforms without a PM domain the runtime PM callbacks
>   continue to perform the existing clock enable/disable locally.
> 
>   No functional change is intended for non-firmware-managed platforms; the
>   change provides a common control point that allows ICE to operate when
>   resources are owned by a PM domain provider.
> 


Nothing here resolves the comments. Also, it's top posted. Honestly, I
won't be talking through you with LLM, so consider patch NAKed.

Best regards,
Krzysztof

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Linlin Zhang]

Hi Krzysztof,

Thanks for the review.

For the SCMI-based platforms (e.g. sa8255p), the ICE resources such as
clocks are not controlled directly by the ICE driver. Instead, they are
managed by remote firmware and exposed to Linux via power domains. As a
result, the ICE driver cannot use clk_prepare_enable() directly to
control the hardware clock.

The intention of moving the clock handling into runtime PM callbacks is
to align the ICE driver with the power domain framework used on these
platforms. When the ICE device is attached to a power domain, invoking
pm_runtime_resume_and_get() will trigger the provider (remote firmware
via SCMI) to power up the device, which in turn enables the underlying
clock and other resources.

This design follows the guidance where the runtime PM framework is
used as the common mechanism to abstract both:
  - direct clock control on non-SCMI platforms, and
  - firmware-controlled resources via power domains on SCMI platforms.

In both cases, the runtime PM callbacks are responsible for performing
the actual resource enable/disable:
  - for legacy platforms: clk_prepare_enable()/disable_unprepare()
  - for SCMI platforms: power domain on/off handled by firmware

So while it may look like an additional layer on legacy platforms, this
approach provides a unified mechanism without requiring separate driver
entry points or special handling in the upper layers (e.g. UFS driver).

That said, I understand your concern that introducing runtime PM solely
for clock gating can be seen as unnecessary overhead on existing
platforms. I will revisit the implementation to ensure that:
  - the runtime PM integration does not introduce regressions for legacy
    platforms, and
  - the design clearly justifies the common abstraction for both SCMI
    and non-SCMI cases.

In addition, I rewrite the commit message as the following to make the
intention more clear.

  On some platforms the ICE device is placed in a firmware-managed power
  domain. In those cases the ICE core resources (including the clock) are
  not directly controllable by Linux and are instead toggled by the power
  domain provider (e.g. remote firmware via SCMI).

  Wire the ICE device into runtime PM so that a single pm_runtime
  transition is used to bring the ICE device up/down. When the device is
  attached to a PM domain, pm_runtime_resume_and_get()/pm_runtime_put_sync()
  will invoke the PM domain callbacks and let the provider manage the
  resources. On platforms without a PM domain the runtime PM callbacks
  continue to perform the existing clock enable/disable locally.

  No functional change is intended for non-firmware-managed platforms; the
  change provides a common control point that allows ICE to operate when
  resources are owned by a PM domain provider.

Thanks again for the feedback. I would appreciate your further review
and comments.

Best regards,
Linlin

On 5/14/2026 10:06 PM, Krzysztof Kozlowski wrote:
> On 12/05/2026 05:37, Linlin Zhang wrote:
>> The QCOM ICE driver manages the ICE core clock through direct calls to
>> clk_prepare_enable() and clk_disable_unprepare(), which limits integration
> 
> No, it does not limit any integration.
> 
>> with platforms that rely on firmware-managed resources or platform-specific
>> power management mechanisms.
> 
> Nope. It's perfectly correct way of managing clocks. Adding runtime PM
> ONLY to toggle clocks is absolute killer, pointless overhead without
> benefits.
> 
>>
>> Replace direct clock management with runtime PM support by moving clock
>> enable and disable into runtime PM callbacks. Use
>> pm_runtime_resume_and_get() and pm_runtime_put_sync() in qcom_ice_resume()
>> and qcom_ice_suspend() to drive power state transitions, and enable runtime
>> PM in qcom_ice_probe().
>>
>> Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
>> Reviewed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>> ---
>>  drivers/soc/qcom/ice.c | 58 ++++++++++++++++++++++++++++++++++++++----
>>  1 file changed, 53 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
>> index b203bc685cad..6f9d679b530c 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_runtime.h>
>>  
>>  #include <linux/firmware/qcom/qcom_scm.h>
>>  
>> @@ -310,8 +311,8 @@ int qcom_ice_resume(struct qcom_ice *ice)
>>  	struct device *dev = ice->dev;
>>  	int err;
>>  
>> -	err = clk_prepare_enable(ice->core_clk);
>> -	if (err) {
>> +	err = pm_runtime_resume_and_get(dev);
>> +	if (err < 0) {
>>  		dev_err(dev, "failed to enable core clock (%d)\n",
>>  			err);
>>  		return err;
>> @@ -323,7 +324,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
>>  
>>  int qcom_ice_suspend(struct qcom_ice *ice)
>>  {
>> -	clk_disable_unprepare(ice->core_clk);
>> +	pm_runtime_put_sync(ice->dev);
>>  	ice->hwkm_init_complete = false;
>>  
>>  	return 0;
> 
> 
> This is pretty pointless change. At least by quick glance. You changed
> nothing here for PM, except adding indirection layer and more locks.
> Clocks will be gated the same way, no energy savings. But on the other
> hand introducing runtime PM subsystem is huge bunch of code with its own
> locks, completely unnecessary here.
> 
> This itself is poor choice and has NEGATIVE impact on all existing
> platforms without any benefit.
> 
> I am surprised you went through SIX internal reviews, collected two
> internal review tags and no one suggested that using runtime PM ONLY to
> toggle clocks is pretty pointless and undesired.> 
> Best regards,
> Krzysztof

Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Krzysztof Kozlowski]

On 12/05/2026 05:37, Linlin Zhang wrote:
> The QCOM ICE driver manages the ICE core clock through direct calls to
> clk_prepare_enable() and clk_disable_unprepare(), which limits integration

No, it does not limit any integration.

> with platforms that rely on firmware-managed resources or platform-specific
> power management mechanisms.

Nope. It's perfectly correct way of managing clocks. Adding runtime PM
ONLY to toggle clocks is absolute killer, pointless overhead without
benefits.

> 
> Replace direct clock management with runtime PM support by moving clock
> enable and disable into runtime PM callbacks. Use
> pm_runtime_resume_and_get() and pm_runtime_put_sync() in qcom_ice_resume()
> and qcom_ice_suspend() to drive power state transitions, and enable runtime
> PM in qcom_ice_probe().
> 
> Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
> Reviewed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> ---
>  drivers/soc/qcom/ice.c | 58 ++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 53 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index b203bc685cad..6f9d679b530c 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_runtime.h>
>  
>  #include <linux/firmware/qcom/qcom_scm.h>
>  
> @@ -310,8 +311,8 @@ int qcom_ice_resume(struct qcom_ice *ice)
>  	struct device *dev = ice->dev;
>  	int err;
>  
> -	err = clk_prepare_enable(ice->core_clk);
> -	if (err) {
> +	err = pm_runtime_resume_and_get(dev);
> +	if (err < 0) {
>  		dev_err(dev, "failed to enable core clock (%d)\n",
>  			err);
>  		return err;
> @@ -323,7 +324,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
>  
>  int qcom_ice_suspend(struct qcom_ice *ice)
>  {
> -	clk_disable_unprepare(ice->core_clk);
> +	pm_runtime_put_sync(ice->dev);
>  	ice->hwkm_init_complete = false;
>  
>  	return 0;


This is pretty pointless change. At least by quick glance. You changed
nothing here for PM, except adding indirection layer and more locks.
Clocks will be gated the same way, no energy savings. But on the other
hand introducing runtime PM subsystem is huge bunch of code with its own
locks, completely unnecessary here.

This itself is poor choice and has NEGATIVE impact on all existing
platforms without any benefit.

I am surprised you went through SIX internal reviews, collected two
internal review tags and no one suggested that using runtime PM ONLY to
toggle clocks is pretty pointless and undesired.

Best regards,
Krzysztof

[PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver

[Linlin Zhang]

The QCOM ICE driver manages the ICE core clock through direct calls to
clk_prepare_enable() and clk_disable_unprepare(), which limits integration
with platforms that rely on firmware-managed resources or platform-specific
power management mechanisms.

Replace direct clock management with runtime PM support by moving clock
enable and disable into runtime PM callbacks. Use
pm_runtime_resume_and_get() and pm_runtime_put_sync() in qcom_ice_resume()
and qcom_ice_suspend() to drive power state transitions, and enable runtime
PM in qcom_ice_probe().

Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
Reviewed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
---
 drivers/soc/qcom/ice.c | 58 ++++++++++++++++++++++++++++++++++++++----
 1 file changed, 53 insertions(+), 5 deletions(-)

diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index b203bc685cad..6f9d679b530c 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_runtime.h>
 
 #include <linux/firmware/qcom/qcom_scm.h>
 
@@ -310,8 +311,8 @@ int qcom_ice_resume(struct qcom_ice *ice)
 	struct device *dev = ice->dev;
 	int err;
 
-	err = clk_prepare_enable(ice->core_clk);
-	if (err) {
+	err = pm_runtime_resume_and_get(dev);
+	if (err < 0) {
 		dev_err(dev, "failed to enable core clock (%d)\n",
 			err);
 		return err;
@@ -323,7 +324,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
 
 int qcom_ice_suspend(struct qcom_ice *ice)
 {
-	clk_disable_unprepare(ice->core_clk);
+	pm_runtime_put_sync(ice->dev);
 	ice->hwkm_init_complete = false;
 
 	return 0;
@@ -716,24 +717,69 @@ EXPORT_SYMBOL_GPL(devm_of_qcom_ice_get);
 
 static int qcom_ice_probe(struct platform_device *pdev)
 {
+	struct device *dev = &pdev->dev;
 	struct qcom_ice *engine;
 	void __iomem *base;
+	int ret;
 
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(base)) {
-		dev_warn(&pdev->dev, "ICE registers not found\n");
+		dev_warn(dev, "ICE registers not found\n");
 		return PTR_ERR(base);
 	}
 
-	engine = qcom_ice_create(&pdev->dev, base);
+	engine = qcom_ice_create(dev, base);
 	if (IS_ERR(engine))
 		return PTR_ERR(engine);
 
 	platform_set_drvdata(pdev, engine);
 
+	ret = devm_pm_runtime_enable(dev);
+	if (ret) {
+		dev_warn(dev, "Enable runtime PM failed, ret: %d\n", ret);
+		return ret;
+	}
+
+	ret = pm_runtime_resume_and_get(dev);
+	if (ret < 0) {
+		dev_warn(dev, "Runtime PM fails to resume, ret: %d\n", ret);
+		return ret;
+	}
+
 	return 0;
 }
 
+static void qcom_ice_remove(struct platform_device *pdev)
+{
+	pm_runtime_put_sync(&pdev->dev);
+}
+
+static int ice_runtime_resume(struct device *dev)
+{
+	struct qcom_ice *ice = dev_get_drvdata(dev);
+	int err = 0;
+
+	err = clk_prepare_enable(ice->core_clk);
+	if (err) {
+		dev_err(dev, "failed to enable core clock (%d)\n",
+			err);
+	}
+
+	return err;
+}
+
+static int ice_runtime_suspend(struct device *dev)
+{
+	struct qcom_ice *ice = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(ice->core_clk);
+	return 0;
+}
+
+static const struct dev_pm_ops ice_pm_ops = {
+	SET_RUNTIME_PM_OPS(ice_runtime_suspend, ice_runtime_resume, NULL)
+};
+
 static const struct of_device_id qcom_ice_of_match_table[] = {
 	{ .compatible = "qcom,inline-crypto-engine" },
 	{ },
@@ -742,8 +788,10 @@ MODULE_DEVICE_TABLE(of, qcom_ice_of_match_table);
 
 static struct platform_driver qcom_ice_driver = {
 	.probe	= qcom_ice_probe,
+	.remove = qcom_ice_remove,
 	.driver = {
 		.name = "qcom-ice",
+		.pm = &ice_pm_ops,
 		.of_match_table = qcom_ice_of_match_table,
 	},
 };
-- 
2.34.1