On Wed, Jul 16, 2025 at 08:56:37PM +0200, Ulf Hansson wrote:
> On Wed, 16 Jul 2025 at 19:23, Hiago De Franco <hiagofra...@gmail.com> wrote:
> >
> > On Wed, Jul 16, 2025 at 10:50:08AM -0600, Mathieu Poirier wrote:
> > > On Wed, Jul 16, 2025 at 10:25:52AM -0300, Hiago De Franco wrote:
> > > > Hi Mathieu, Ulf,
> > > >
> > > > On Tue, Jul 15, 2025 at 09:32:44AM -0600, Mathieu Poirier wrote:
> > > > > On Sun, Jun 29, 2025 at 02:25:12PM -0300, Hiago De Franco wrote:
> > > > > > From: Hiago De Franco <hiago.fra...@toradex.com>
> > > > > >
> > > > > > When the Cortex-M remote core is started and already running before
> > > > > > Linux boots (typically by the Cortex-A bootloader using a command
> > > > > > like
> > > > > > bootaux), the current driver is unable to attach to it. This is
> > > > > > because
> > > > > > the driver only checks for remote cores running in different SCFW
> > > > > > partitions. However in this case, the M-core is in the same
> > > > > > partition as
> > > > > > Linux and is already powered up and running by the bootloader.
> > > > > >
> > > > > > This patch adds a check using dev_pm_genpd_is_on() to verify
> > > > > > whether the
> > > > > > M-core's power domains are already on. If all power domain devices
> > > > > > are
> > > > > > on, the driver assumes the M-core is running and proceed to attach
> > > > > > to
> > > > > > it.
> > > > > >
> > > > > > To accomplish this, we need to avoid passing any attach_data or
> > > > > > flags to
> > > > > > dev_pm_domain_attach_list(), allowing the platform device become a
> > > > > > consumer of the power domain provider without changing its current
> > > > > > state.
> > > > > >
> > > > > > During probe, also enable and sync the device runtime PM to make
> > > > > > sure
> > > > > > the power domains are correctly managed when the core is controlled
> > > > > > by
> > > > > > the kernel.
> > > > > >
> > > > > > Suggested-by: Ulf Hansson <ulf.hans...@linaro.org>
> > > > > > Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>
> > > > > > Reviewed-by: Peng Fan <peng....@nxp.com>
> > > > > > Signed-off-by: Hiago De Franco <hiago.fra...@toradex.com>
> > > > > > ---
> > > > > > v6 -> v7:
> > > > > > - Added Peng reviewed-by.
> > > > > > v5 -> v6:
> > > > > > - Commit description improved, as suggested. Added Ulf Hansson
> > > > > > reviewed
> > > > > > by. Comment on imx-rproc.c improved.
> > > > > > 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..24597b60c5b0 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 powered up and running when the kernel
> > > > > > booted (e.g.,
> > > > > > + * started by U-Boot's bootaux command). In this case
> > > > > > attach to it.
> > > > > > + */
> > > > > > + for (i = 0; i < ret; i++) {
> > > > > > + if (!dev_pm_genpd_is_on(priv->pd_list->pd_devs[i]))
> > > > > > {
> > > > > > + detached = false;
> > > > > > + break;
> > > > > > + }
> > > > > > + }
> > > > >
> > > > > I was doing one final review of this work when I noticed the return
> > > > > code for
> > > > > dev_pm_domain_attach_list() is never checked for error.
> > > >
> > > > As Ulf pointed out, the 'return' a few lines below will return the
> > > > negative value to the caller of 'imx_rproc_attach_pd', which ultimately
> > > > will fail 'imx_rproc_detect_mode' and fail the probe of imx_rproc.
> > > >
> > > > Please notice that even tough 'dev_pm_domain_attach_list' fails, the
> > > > rproc->state will still be set as RPROC_DETACHED because we are starting
> > > > 'detached' as true, but I am not seeing this as an issue because as
> > > > mentioned above the probe will fail anyway. Please let me know if you
> > > > see this as an issue.
> > >
> > > Two things to consider here:
> > >
> > > (1) It is only a matter of time before someone with a cleaver coccinelle
> > > script
> > > sends me a patch that adds the missing error check.
> > >
> > > (2) I think that @rproc->state being changed on error conditions is a bug
> > > waiting to happen. This kind of implicit error handling is difficult to
> > > maintain and even more difficult for people to make enhancements to the
> > > driver.
> > >
> > > Adding a simple error check will make sure neither of the above will
> > > happen. It
> > > is a simple change and we are at rc6 - this work can still go in the merge
> > > window.
> >
> > Sure, I can submit a new revision with this error check. Sorry I did not
> > see this before, I only had a close look at this '->state' now that you
> > asked on the previous email.
>
> Alright. To avoid having you to resend patch1 and patch2 I have
> applied them on my next branch and added Mathieu's ack for patch2.
>
> Note that my vacation is around the corner, so if you want patch3 for
> v6.17 you better be quick. :-)
Thanks Ulf, as requested I resend only patch 3.
https://lore.kernel.org/all/20250716194638.113115-1-hiagofra...@gmail.com/
Have a nice vacation =)
Best Regards,
Hiago.
>
> [...]
>
> Thanks and kind regards
> Uffe
