linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@oss.nxp.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Hiago De Franco <hiagofranco@gmail.com>,
	Mathieu Poirier <mathieu.poirier@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, daniel.baluta@nxp.com,
	iuliana.prodan@oss.nxp.com, Fabio Estevam <festevam@gmail.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH v2 3/3] remoteproc: imx_rproc: add power mode check for remote core attachment
Date: Mon, 12 May 2025 11:33:30 +0800	[thread overview]
Message-ID: <20250512033330.GA31197@nxa18884-linux> (raw)
In-Reply-To: <CAPDyKFrHD1hVCfOK-JV5FJM+Cd9DoKKZGKcC94fxx6_9Bsri1g@mail.gmail.com>

Hi Ulf,

On Thu, May 08, 2025 at 12:03:33PM +0200, Ulf Hansson wrote:
>On Wed, 7 May 2025 at 18:02, Hiago De Franco <hiagofranco@gmail.com> 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
>> by the bootloader, it is in the same partition as Linux and it is
>> already up and running.
>>
>> This adds power mode verification through the SCU interface, enabling
>> the driver to detect when the remote core is already running and
>> properly attach to it.
>>
>> Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
>> Suggested-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> v2: Dropped unecessary include. Removed the imx_rproc_is_on function, as
>> suggested.
>> ---
>>  drivers/remoteproc/imx_rproc.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
>> index 627e57a88db2..9b6e9e41b7fc 100644
>> --- a/drivers/remoteproc/imx_rproc.c
>> +++ b/drivers/remoteproc/imx_rproc.c
>> @@ -949,6 +949,19 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>>                         if (of_property_read_u32(dev->of_node, "fsl,entry-address", &priv->entry))
>>                                 return -EINVAL;
>>
>> +                       /*
>> +                        * If remote core is already running (e.g. kicked by
>> +                        * the bootloader), attach to it.
>> +                        */
>> +                       ret = imx_sc_pm_get_resource_power_mode(priv->ipc_handle,
>> +                                                               priv->rsrc_id);
>> +                       if (ret < 0)
>> +                               dev_err(dev, "failed to get power resource %d mode, ret %d\n",
>> +                                       priv->rsrc_id, ret);
>> +
>> +                       if (ret == IMX_SC_PM_PW_MODE_ON)
>> +                               priv->rproc->state = RPROC_DETACHED;
>> +
>>                         return imx_rproc_attach_pd(priv);
>
>Why is it important to potentially set "priv->rproc->state =
>RPROC_DETACHED" before calling imx_rproc_attach_pd()?
>
>Would it be possible to do it the other way around? First calling
>imx_rproc_attach_pd() then get the power-mode to know if
>RPROC_DETACHED should be set or not?

If M4 is not powered up by bootloader, attach_pd is to power
up the related power domains. And the rproc->state should be OFFLINE.

If M4 is powered up by bootloader, the rproc->state should be set as
DETACHED, then attach_pd here will not touch the real pd, because
scu-pd driver set is_off as false when doing pm_genpd_init.
In this case, we still need attach_pd to avoid power shutdown when
pd_ignore_unused and also need to support linux stop/start m4 even
it is started by bootloader.


So we could not reverse the logic.

Regards,
Peng

>
>The main reason why I ask, is because of how we handle the single PM
>domain case. In that case, the PM domain has already been attached
>(and powered-on) before we reach this point.
>
>>                 }
>>
>> --
>> 2.39.5
>>
>
>Kind regards
>Uffe


      parent reply	other threads:[~2025-05-12  2:28 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07 16:00 [PATCH v2 0/3] remoteproc: imx_rproc: allow attaching to running core kicked by the bootloader Hiago De Franco
2025-05-07 16:00 ` [PATCH v2 1/3] firmware: imx: move get power mode function from scu-pd.c to misc.c Hiago De Franco
2025-05-13  7:43   ` Peng Fan
2025-05-13 21:05     ` Hiago De Franco
2025-05-07 16:00 ` [PATCH v2 2/3] remoteproc: imx_rproc: skip clock enable when M-core is managed by the SCU Hiago De Franco
2025-05-07 16:00 ` [PATCH v2 3/3] remoteproc: imx_rproc: add power mode check for remote core attachment Hiago De Franco
2025-05-08 10:03   ` Ulf Hansson
2025-05-08 20:28     ` Hiago De Franco
2025-05-09 10:37       ` Ulf Hansson
2025-05-09 19:13         ` Hiago De Franco
2025-05-12  4:56           ` Peng Fan
2025-05-12 14:13             ` Hiago De Franco
2025-05-19 14:39             ` Ulf Hansson
2025-05-19 14:44               ` Ulf Hansson
2025-05-19 14:33           ` Ulf Hansson
2025-05-19 17:23             ` Hiago De Franco
2025-05-20 12:21               ` Ulf Hansson
2025-05-21  4:13                 ` Peng Fan
2025-05-21  4:18                   ` Peng Fan
2025-05-21 12:11                     ` Ulf Hansson
2025-05-23 19:17                       ` Hiago De Franco
2025-05-26 10:07                         ` Ulf Hansson
2025-05-27  0:05                           ` Hiago De Franco
2025-05-27  2:39                             ` Peng Fan
2025-05-27 11:58                               ` Ulf Hansson
2025-05-27 13:45                                 ` Hiago De Franco
2025-05-28 17:38                                   ` Hiago De Franco
2025-05-29  3:54                                     ` Peng Fan
2025-05-29 20:15                                       ` Hiago De Franco
2025-05-30  9:45                                         ` Ulf Hansson
2025-05-12  3:33     ` Peng Fan [this message]

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=20250512033330.GA31197@nxa18884-linux \
    --to=peng.fan@oss.nxp.com \
    --cc=andersson@kernel.org \
    --cc=daniel.baluta@nxp.com \
    --cc=festevam@gmail.com \
    --cc=hiago.franco@toradex.com \
    --cc=hiagofranco@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=iuliana.prodan@oss.nxp.com \
    --cc=kernel@pengutronix.de \
    --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@nxp.com \
    --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;
as well as URLs for NNTP newsgroup(s).