On sc7280, to reliably blow fuses, we need an additional vote
on max performance state of 'MX' power-domain.
Add support for power-domain performance state voting in the
driver.
Signed-off-by: Rajendra Nayak <[email protected]>
---
drivers/nvmem/qfprom.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
index 81fbad5..b5f27df 100644
--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -12,6 +12,8 @@
#include <linux/mod_devicetable.h>
#include <linux/nvmem-provider.h>
#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
#include <linux/property.h>
#include <linux/regulator/consumer.h>
@@ -139,6 +141,9 @@ static void qfprom_disable_fuse_blowing(const struct qfprom_priv *priv,
{
int ret;
+ dev_pm_genpd_set_performance_state(priv->dev, 0);
+ pm_runtime_put(priv->dev);
+
/*
* This may be a shared rail and may be able to run at a lower rate
* when we're not blowing fuses. At the moment, the regulator framework
@@ -212,6 +217,14 @@ static int qfprom_enable_fuse_blowing(const struct qfprom_priv *priv,
goto err_clk_rate_set;
}
+ ret = pm_runtime_get_sync(priv->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(priv->dev);
+ dev_err(priv->dev, "Failed to enable power-domain\n");
+ goto err_reg_enable;
+ }
+ dev_pm_genpd_set_performance_state(priv->dev, INT_MAX);
+
old->timer_val = readl(priv->qfpconf + QFPROM_BLOW_TIMER_OFFSET);
old->accel_val = readl(priv->qfpconf + QFPROM_ACCEL_OFFSET);
writel(priv->soc_data->qfprom_blow_timer_value,
@@ -221,6 +234,8 @@ static int qfprom_enable_fuse_blowing(const struct qfprom_priv *priv,
return 0;
+err_reg_enable:
+ regulator_disable(priv->vcc);
err_clk_rate_set:
clk_set_rate(priv->secclk, old->clk_rate);
err_clk_prepared:
@@ -320,6 +335,11 @@ static int qfprom_reg_read(void *context,
return 0;
}
+static void qfprom_runtime_disable(void *data)
+{
+ pm_runtime_disable(data);
+}
+
static const struct qfprom_soc_data qfprom_7_8_data = {
.accel_value = 0xD10,
.qfprom_blow_timer_value = 25,
@@ -420,6 +440,12 @@ static int qfprom_probe(struct platform_device *pdev)
econfig.reg_write = qfprom_reg_write;
}
+ ret = devm_add_action_or_reset(dev, qfprom_runtime_disable, dev);
+ if (ret)
+ return ret;
+
+ pm_runtime_enable(dev);
+
nvmem = devm_nvmem_register(dev, &econfig);
return PTR_ERR_OR_ZERO(nvmem);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Hi,
On Thu, Jul 29, 2021 at 5:01 AM Rajendra Nayak <[email protected]> wrote:
>
> On sc7280, to reliably blow fuses, we need an additional vote
> on max performance state of 'MX' power-domain.
> Add support for power-domain performance state voting in the
> driver.
>
> Signed-off-by: Rajendra Nayak <[email protected]>
> ---
> drivers/nvmem/qfprom.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
> index 81fbad5..b5f27df 100644
> --- a/drivers/nvmem/qfprom.c
> +++ b/drivers/nvmem/qfprom.c
> @@ -12,6 +12,8 @@
> #include <linux/mod_devicetable.h>
> #include <linux/nvmem-provider.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
> #include <linux/property.h>
> #include <linux/regulator/consumer.h>
>
> @@ -139,6 +141,9 @@ static void qfprom_disable_fuse_blowing(const struct qfprom_priv *priv,
> {
> int ret;
>
> + dev_pm_genpd_set_performance_state(priv->dev, 0);
> + pm_runtime_put(priv->dev);
To me it feels as if this should be at the end of the function rather
than the beginning. I guess it doesn't matter (?), but it feels wrong
that we have writes to the register space after we're don't a
pm_runtime_put().
> @@ -420,6 +440,12 @@ static int qfprom_probe(struct platform_device *pdev)
> econfig.reg_write = qfprom_reg_write;
> }
>
> + ret = devm_add_action_or_reset(dev, qfprom_runtime_disable, dev);
> + if (ret)
> + return ret;
> +
> + pm_runtime_enable(dev);
> +
Swap the order of the two. IOW first pm_runtime_enable(), then
devm_add_action_or_reset(). Specifically the "_or_reset" means that if
you fail to add the action (AKA devm_add_action() fails to allocate
the tiny amount of memory it needs) it will actually _call_ the
action. That means that in your code if the memory allocation fails
you'll call pm_runtime_disable() without the corresponding
pm_runtime_enable().
Other than those two issues this looks good to me. Feel free to add my
Reviewed-by when you fix them.
-Doug
On 7/29/2021 9:37 PM, Doug Anderson wrote:
> Hi,
>
> On Thu, Jul 29, 2021 at 5:01 AM Rajendra Nayak <[email protected]> wrote:
>>
>> On sc7280, to reliably blow fuses, we need an additional vote
>> on max performance state of 'MX' power-domain.
>> Add support for power-domain performance state voting in the
>> driver.
>>
>> Signed-off-by: Rajendra Nayak <[email protected]>
>> ---
>> drivers/nvmem/qfprom.c | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
>> index 81fbad5..b5f27df 100644
>> --- a/drivers/nvmem/qfprom.c
>> +++ b/drivers/nvmem/qfprom.c
>> @@ -12,6 +12,8 @@
>> #include <linux/mod_devicetable.h>
>> #include <linux/nvmem-provider.h>
>> #include <linux/platform_device.h>
>> +#include <linux/pm_domain.h>
>> +#include <linux/pm_runtime.h>
>> #include <linux/property.h>
>> #include <linux/regulator/consumer.h>
>>
>> @@ -139,6 +141,9 @@ static void qfprom_disable_fuse_blowing(const struct qfprom_priv *priv,
>> {
>> int ret;
>>
>> + dev_pm_genpd_set_performance_state(priv->dev, 0);
>> + pm_runtime_put(priv->dev);
>
> To me it feels as if this should be at the end of the function rather
> than the beginning. I guess it doesn't matter (?), but it feels wrong
> that we have writes to the register space after we're don't a
> pm_runtime_put().
Right, I was confused with this too when I saw that the other resources
(regulator/clocks) were also turned off before we write into the
register space. And then looking into the driver I realized its perhaps because
the resources are needed only for the 'raw' writes and the 'conf'
read/writes can happen regardless. I'll just fix that up and put the register
writes before we really turn off any resources to avoid confusion.
>
>
>> @@ -420,6 +440,12 @@ static int qfprom_probe(struct platform_device *pdev)
>> econfig.reg_write = qfprom_reg_write;
>> }
>>
>> + ret = devm_add_action_or_reset(dev, qfprom_runtime_disable, dev);
>> + if (ret)
>> + return ret;
>> +
>> + pm_runtime_enable(dev);
>> +
>
> Swap the order of the two. IOW first pm_runtime_enable(), then
> devm_add_action_or_reset(). Specifically the "_or_reset" means that if
> you fail to add the action (AKA devm_add_action() fails to allocate
> the tiny amount of memory it needs) it will actually _call_ the
> action.
Ah, I didn't know that, thanks, I'll fix the order up and repost.
> That means that in your code if the memory allocation fails
> you'll call pm_runtime_disable() without the corresponding
> pm_runtime_enable().
>
>
> Other than those two issues this looks good to me. Feel free to add my
> Reviewed-by when you fix them.
Thanks.
>
> -Doug
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation