linux-remoteproc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: Suman Anna <s-anna@ti.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Arnaud Pouliquen <arnaud.pouliquen@st.com>,
	od@zcrc.me, linux-remoteproc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Tero Kristo <t-kristo@ti.com>
Subject: Re: [PATCH v7 3/5] remoteproc: Add support for runtime PM
Date: Tue, 09 Jun 2020 00:46:21 +0200	[thread overview]
Message-ID: <9XPMBQ.UM94FDID8MZW@crapouillou.net> (raw)
In-Reply-To: <daa239fe-afd4-ff2e-3d5c-db09434cac95@ti.com>

Hi Suman,

>>> On 5/15/20 5:43 AM, Paul Cercueil wrote:
>>>> Call pm_runtime_get_sync() before the firmware is loaded, and
>>>> pm_runtime_put() after the remote processor has been stopped.
>>>> 
>>>> Even though the remoteproc device has no PM callbacks, this allows 
>>>> the
>>>> parent device's PM callbacks to be properly called.
>>> 
>>> I see this patch staged now for 5.8, and the latest -next branch 
>>> has \x7f\x7fbroken the pm-runtime autosuspend feature we have in the OMAP 
>>> \x7f\x7fremoteproc driver. See commit 5f31b232c674 ("remoteproc/omap: Add 
>>> \x7f\x7fsupport for runtime auto-suspend/resume").
>>> 
>>> What was the original purpose of this patch, because there can be 
>>> \x7f\x7fdiffering backends across different SoCs.
>> 
>> Did you try pm_suspend_ignore_children()? It looks like it was made 
>> for \x7fyour use-case.
> 
> Sorry for the delay in getting back. So, using 
> pm_suspend_ignore_children() does fix my current issue.
> 
> But I still fail to see the original purpose of this patch in the 
> remoteproc core especially given that the core itself does not have 
> any callbacks. If the sole intention was to call the parent pdev's 
> callbacks, then I feel that state-machine is better managed within 
> that particular platform driver itself, as the sequencing/device 
> management can vary with different platform drivers.

The problem is that with Ingenic SoCs some clocks must be enabled in 
order to load the firmware, and the core doesn't give you an option to 
register a callback to be called before loading it. The first version 
of my patchset added .prepare/.unprepare callbacks to the struct 
rproc_ops, but the feedback from the maintainers was that I should do 
it via runtime PM. However, it was not possible to keep it contained in 
the driver, since again the core doesn't provide a "prepare" callback, 
so no place to call pm_runtime_get_sync(). So we settled with having 
runtime PM in the core without callbacks, which will trigger the 
runtime PM callbacks of the driver at the right moment.

Sorry if that caused you trouble.

Cheers,
-Paul
>>> 

>>> 
>>>> 
>>>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>>>> ---
>>>> 
>>>> Notes:
>>>>      v2-v4: No change
>>>>      v5: Move calls to prepare/unprepare to 
>>>> rproc_fw_boot/rproc_shutdown
>>>>      v6: Instead of prepare/unprepare callbacks, use PM runtime 
>>>> \x7f\x7f\x7fcallbacks
>>>>      v7: Check return value of pm_runtime_get_sync()
>>>> 
>>>>   drivers/remoteproc/remoteproc_core.c | 17 ++++++++++++++++-
>>>>   1 file changed, 16 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/drivers/remoteproc/remoteproc_core.c 
>>>> \x7f\x7f\x7fb/drivers/remoteproc/remoteproc_core.c
>>>> index a7f96bc98406..e33d1ef27981 100644
>>>> --- a/drivers/remoteproc/remoteproc_core.c
>>>> +++ b/drivers/remoteproc/remoteproc_core.c
>>>> @@ -29,6 +29,7 @@
>>>>   #include <linux/devcoredump.h>
>>>>   #include <linux/rculist.h>
>>>>   #include <linux/remoteproc.h>
>>>> +#include <linux/pm_runtime.h>
>>>>   #include <linux/iommu.h>
>>>>   #include <linux/idr.h>
>>>>   #include <linux/elf.h>
>>>> @@ -1382,6 +1383,12 @@ static int rproc_fw_boot(struct rproc 
>>>> *rproc, \x7f\x7f\x7fconst struct firmware *fw)
>>>>       if (ret)
>>>>           return ret;
>>>>   \x7f+    ret = pm_runtime_get_sync(dev);
>>>> +    if (ret < 0) {
>>>> +        dev_err(dev, "pm_runtime_get_sync failed: %d\n", ret);
>>>> +        return ret;
>>>> +    }
>>>> +
>>>>       dev_info(dev, "Booting fw image %s, size %zd\n", name, 
>>>> fw->size);
>>>>   \x7f      /*
>>>> @@ -1391,7 +1398,7 @@ static int rproc_fw_boot(struct rproc 
>>>> *rproc, \x7f\x7f\x7fconst struct firmware *fw)
>>>>       ret = rproc_enable_iommu(rproc);
>>>>       if (ret) {
>>>>           dev_err(dev, "can't enable iommu: %d\n", ret);
>>>> -        return ret;
>>>> +        goto put_pm_runtime;
>>>>       }
>>>>   \x7f      rproc->bootaddr = rproc_get_boot_addr(rproc, fw);
>>>> @@ -1435,6 +1442,8 @@ static int rproc_fw_boot(struct rproc 
>>>> *rproc, \x7f\x7f\x7fconst struct firmware *fw)
>>>>       rproc->table_ptr = NULL;
>>>>   disable_iommu:
>>>>       rproc_disable_iommu(rproc);
>>>> +put_pm_runtime:
>>>> +    pm_runtime_put(dev);
>>>>       return ret;
>>>>   }
>>>>   \x7f@@ -1840,6 +1849,8 @@ void rproc_shutdown(struct rproc *rproc)
>>>>   \x7f      rproc_disable_iommu(rproc);
>>>>   \x7f+    pm_runtime_put(dev);
>>>> +
>>>>       /* Free the copy of the resource table */
>>>>       kfree(rproc->cached_table);
>>>>       rproc->cached_table = NULL;
>>>> @@ -2118,6 +2129,9 @@ struct rproc *rproc_alloc(struct device 
>>>> *dev, \x7f\x7f\x7fconst char *name,
>>>>   \x7f      rproc->state = RPROC_OFFLINE;
>>>>   \x7f+    pm_runtime_no_callbacks(&rproc->dev);
>>>> +    pm_runtime_enable(&rproc->dev);
>>>> +
>>>>       return rproc;
>>>>   }
>>>>   EXPORT_SYMBOL(rproc_alloc);
>>>> @@ -2133,6 +2147,7 @@ EXPORT_SYMBOL(rproc_alloc);
>>>>    */
>>>>   void rproc_free(struct rproc *rproc)
>>>>   {
>>>> +    pm_runtime_disable(&rproc->dev);
>>>>       put_device(&rproc->dev);
>>>>   }
>>>>   EXPORT_SYMBOL(rproc_free);
>>>> 
>>> 



  reply	other threads:[~2020-06-08 22:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15 10:43 [PATCH v7 1/5] dt-bindings: Document JZ47xx VPU auxiliary processor Paul Cercueil
2020-05-15 10:43 ` [PATCH v7 2/5] remoteproc: Add device-managed variants of rproc_alloc/rproc_add Paul Cercueil
2020-05-15 10:43 ` [PATCH v7 3/5] remoteproc: Add support for runtime PM Paul Cercueil
2020-05-22 16:47   ` Suman Anna
2020-05-22 17:11     ` Paul Cercueil
2020-06-08 22:03       ` Suman Anna
2020-06-08 22:46         ` Paul Cercueil [this message]
2020-06-08 23:10           ` Suman Anna
2020-06-10  9:40             ` Paul Cercueil
2020-06-11  4:39               ` Bjorn Andersson
2020-06-11 21:17                 ` Suman Anna
2020-06-22 17:51                   ` Arnaud POULIQUEN
2020-05-15 10:43 ` [PATCH v7 4/5] remoteproc: ingenic: Added remoteproc driver Paul Cercueil
2020-05-18 23:57   ` Bjorn Andersson
2020-06-11 21:47   ` Suman Anna
2020-06-11 22:21     ` Paul Cercueil
2020-06-12  0:21       ` Suman Anna
2020-06-12 11:47         ` Paul Cercueil
2020-06-12 14:47           ` Suman Anna
2020-06-21 19:30           ` Bjorn Andersson
2020-06-24 23:14             ` Mathieu Poirier
2020-05-15 10:43 ` [PATCH v7 5/5] MAINTAINERS: Add myself as reviewer for Ingenic rproc driver Paul Cercueil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9XPMBQ.UM94FDID8MZW@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=od@zcrc.me \
    --cc=ohad@wizery.com \
    --cc=s-anna@ti.com \
    --cc=t-kristo@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).