From: Hiago De Franco <hiagofranco@gmail.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
linux-pm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Bjorn Andersson <andersson@kernel.org>,
Hiago De Franco <hiago.franco@toradex.com>,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Peng Fan <peng.fan@oss.nxp.com>,
daniel.baluta@nxp.com, iuliana.prodan@oss.nxp.com,
"Rafael J . Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v5 3/3] remoteproc: imx_rproc: detect and attach to pre-booted remote cores
Date: Tue, 24 Jun 2025 13:16:21 -0300 [thread overview]
Message-ID: <20250624161621.fezba5p3dmecnor6@hiagonb> (raw)
In-Reply-To: <aFly61yCMttkp12e@p14s>
On Mon, Jun 23, 2025 at 09:29:47AM -0600, Mathieu Poirier wrote:
> On Tue, Jun 17, 2025 at 04:34:50PM -0300, Hiago De Franco wrote:
> > From: Hiago De Franco <hiago.franco@toradex.com>
> >
> > When the remote core is started before Linux boots (e.g., by the
> > bootloader), the driver currently is not able to attach because it only
> > checks for cores running in different partitions. If the core was kicked
>
> Again, we have a nomenclature issue here with "If the core was kicked by the
> bootloader". What does "kicked" mean here? Is it just powered and held in
> reset or is it executing. And are you referring to the A core or the M core?
Ok, same here, I will improve this in the next revision. Thanks.
>
>
> > by the bootloader, it is in the same partition as Linux and it is
> > already up and running.
> >
> > This adds power mode verification through dev_pm_genpd_is_on(), enabling
> > the driver to detect when the remote core is already running and
> > properly attach to it if all the power domain devices are on.
> >
> > To accomplish this, we need to avoid passing any attach_data or flags to
> > dev_pm_domain_attach_list(), letting the platform device become a
> > consumer of the power domain provider. With that the current power state
> > of the genpds will not change, allowing the detection of the remote core
> > power state.
> >
> > We enable and sync the device runtime PM during probe to make sure the
> > power domains are correctly managed when the core is controlled by the
> > kernel.
> >
> > Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
> > Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
> > ---
> > v4 -> v5:
> > - pm_runtime_get_sync() removed in favor of
> > pm_runtime_resume_and_get(). Now it also checks the return value of
> > this function.
> > - Added pm_runtime_disable() and pm_runtime_put() to imx_rproc_remove()
> > function.
> > v3 -> v4:
> > - Changed to use the new dev_pm_genpd_is_on() function instead, as
> > suggested by Ulf. This will now get the power status of the two
> > remote cores power domains to decided if imx_rpoc needs to attach or
> > not. In order to do that, pm_runtime_enable() and
> > pm_runtime_get_sync() were introduced and pd_data was removed.
> > v2 -> v3:
> > - Unchanged.
> > v1 -> v2:
> > - Dropped unecessary include. Removed the imx_rproc_is_on function, as
> > suggested.
> > ---
> > drivers/remoteproc/imx_rproc.c | 37 +++++++++++++++++++++++++++++-----
> > 1 file changed, 32 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> > index 627e57a88db2..b53083f2553e 100644
> > --- a/drivers/remoteproc/imx_rproc.c
> > +++ b/drivers/remoteproc/imx_rproc.c
> > @@ -18,6 +18,7 @@
> > #include <linux/of_reserved_mem.h>
> > #include <linux/platform_device.h>
> > #include <linux/pm_domain.h>
> > +#include <linux/pm_runtime.h>
> > #include <linux/reboot.h>
> > #include <linux/regmap.h>
> > #include <linux/remoteproc.h>
> > @@ -890,10 +891,8 @@ static int imx_rproc_partition_notify(struct notifier_block *nb,
> > static int imx_rproc_attach_pd(struct imx_rproc *priv)
> > {
> > struct device *dev = priv->dev;
> > - int ret;
> > - struct dev_pm_domain_attach_data pd_data = {
> > - .pd_flags = PD_FLAG_DEV_LINK_ON,
> > - };
> > + int ret, i;
> > + bool detached = true;
> >
> > /*
> > * If there is only one power-domain entry, the platform driver framework
> > @@ -902,7 +901,22 @@ static int imx_rproc_attach_pd(struct imx_rproc *priv)
> > if (dev->pm_domain)
> > return 0;
> >
> > - ret = dev_pm_domain_attach_list(dev, &pd_data, &priv->pd_list);
> > + ret = dev_pm_domain_attach_list(dev, NULL, &priv->pd_list);
> > + /*
> > + * If all the power domain devices are already turned on, the remote
> > + * core is already up when the kernel booted (e.g. kicked by the
> > + * bootloader). In this case attach to it.
>
> Same comment as above. What got kicked? A core or M core. And what does
> "kicked" mean? I can guess what is happening but guessing rarely leads to
> anything positive.
>
> In the next revision, please use other words than "kicked".
Noted, thanks.
>
>
> > + */
> > + for (i = 0; i < ret; i++) {
> > + if (!dev_pm_genpd_is_on(priv->pd_list->pd_devs[i])) {
> > + detached = false;
> > + break;
> > + }
> > + }
> > +
> > + if (detached)
> > + priv->rproc->state = RPROC_DETACHED;
> > +
>
> Ok for the above.
>
> > return ret < 0 ? ret : 0;
> > }
> >
> > @@ -1146,6 +1160,15 @@ static int imx_rproc_probe(struct platform_device *pdev)
> > }
> > }
> >
> > + if (dcfg->method == IMX_RPROC_SCU_API) {
> > + pm_runtime_enable(dev);
> > + ret = pm_runtime_resume_and_get(dev);
> > + if (ret) {
> > + dev_err(dev, "pm_runtime get failed: %d\n", ret);
> > + goto err_put_clk;
> > + }
> > + }
> > +
> > ret = rproc_add(rproc);
> > if (ret) {
> > dev_err(dev, "rproc_add failed\n");
> > @@ -1171,6 +1194,10 @@ static void imx_rproc_remove(struct platform_device *pdev)
> > struct rproc *rproc = platform_get_drvdata(pdev);
> > struct imx_rproc *priv = rproc->priv;
> >
> > + if (priv->dcfg->method == IMX_RPROC_SCU_API) {
> > + pm_runtime_disable(priv->dev);
> > + pm_runtime_put(priv->dev);
> > + }
> > clk_disable_unprepare(priv->clk);
> > rproc_del(rproc);
> > imx_rproc_put_scu(rproc);
> > --
> > 2.39.5
> >
next prev parent reply other threads:[~2025-06-24 19:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-17 19:34 [PATCH v5 0/3] remoteproc: imx_rproc: allow attaching to running core kicked by the bootloader Hiago De Franco
2025-06-17 19:34 ` [PATCH v5 1/3] pmdomain: core: introduce dev_pm_genpd_is_on() Hiago De Franco
2025-06-18 3:01 ` Bjorn Andersson
2025-06-17 19:34 ` [PATCH v5 2/3] remoteproc: imx_rproc: skip clock enable when M-core is managed by the SCU Hiago De Franco
2025-06-23 15:15 ` Mathieu Poirier
2025-06-24 16:15 ` Hiago De Franco
2025-06-17 19:34 ` [PATCH v5 3/3] remoteproc: imx_rproc: detect and attach to pre-booted remote cores Hiago De Franco
2025-06-18 12:12 ` Ulf Hansson
2025-06-23 15:29 ` Mathieu Poirier
2025-06-24 16:16 ` Hiago De Franco [this message]
2025-06-19 8:44 ` [PATCH v5 0/3] remoteproc: imx_rproc: allow attaching to running core kicked by the bootloader Peng Fan
2025-06-23 15:32 ` Mathieu Poirier
2025-06-24 16:18 ` Hiago De Franco
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=20250624161621.fezba5p3dmecnor6@hiagonb \
--to=hiagofranco@gmail.com \
--cc=andersson@kernel.org \
--cc=daniel.baluta@nxp.com \
--cc=hiago.franco@toradex.com \
--cc=imx@lists.linux.dev \
--cc=iuliana.prodan@oss.nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=peng.fan@oss.nxp.com \
--cc=rafael@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=ulf.hansson@linaro.org \
/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