linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: bjorn.andersson@linaro.org, shawnguo@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, linux-imx@nxp.com,
	linux-remoteproc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH 7/9] remoteproc: imx_rproc: support kicking Mcore from Linux for i.MX8QXP
Date: Wed, 19 Jan 2022 11:58:52 -0700	[thread overview]
Message-ID: <20220119185852.GB1284752@p14s> (raw)
In-Reply-To: <20220111033333.403448-10-peng.fan@oss.nxp.com>

On Tue, Jan 11, 2022 at 11:33:31AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> When M4 is in the same hardware partition with Cortex-A, it
> could be start/stop by Linux.
> 
> Added power domain to make sure M4 could run, it requires several power
> domains to work. Make clk always optional for i.MX8QXP, because
> SCFW handles it when power up M4 core.
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 64 +++++++++++++++++++++++++++++++++-
>  1 file changed, 63 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 5f04aea2f6a1..09d2a06e5ed6 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -16,6 +16,7 @@
>  #include <linux/of_reserved_mem.h>
>  #include <linux/of_device.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
>  #include <linux/regmap.h>
>  #include <linux/remoteproc.h>
>  #include <linux/workqueue.h>
> @@ -97,6 +98,9 @@ struct imx_rproc {
>  	struct notifier_block		proc_nb;
>  	u32				rproc_pt;
>  	u32				rsrc;
> +	int                             num_pd;
> +	struct device                   **pd_dev;
> +	struct device_link              **pd_dev_link;
>  };
>  
>  static const struct imx_rproc_att imx_rproc_att_imx8qxp[] = {
> @@ -305,6 +309,9 @@ static int imx_rproc_start(struct rproc *rproc)
>  		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_START, 0, 0, 0, 0, 0, 0, &res);
>  		ret = res.a0;
>  		break;
> +	case IMX_RPROC_SCU_API:
> +		ret = imx_sc_pm_cpu_start(priv->ipc_handle, priv->rsrc, true, 0x34fe0000);

Where does the 0x34fe0000 comes from and what happens when the boot address
changes?  This should come from the device tree or some HW register somewhere.

> +		break;
>  	default:
>  		return -EOPNOTSUPP;
>  	}
> @@ -334,6 +341,9 @@ static int imx_rproc_stop(struct rproc *rproc)
>  		if (res.a1)
>  			dev_info(dev, "Not in wfi, force stopped\n");
>  		break;
> +	case IMX_RPROC_SCU_API:
> +		ret = imx_sc_pm_cpu_start(priv->ipc_handle, priv->rsrc, false, 0x34fe0000);
> +		break;

Same as above.

>  	default:
>  		return -EOPNOTSUPP;
>  	}
> @@ -719,6 +729,56 @@ static int imx_rproc_partition_notify(struct notifier_block *nb,
>  	return 0;
>  }
>  
> +static int imx_rproc_attach_pd(struct imx_rproc *priv)
> +{
> +	struct device *dev = priv->dev;
> +	int ret, i;
> +
> +	priv->num_pd = of_count_phandle_with_args(dev->of_node, "power-domains",
> +						  "#power-domain-cells");
> +	if (priv->num_pd < 0)
> +		return priv->num_pd;
> +
> +	if (!priv->num_pd)
> +		return 0;
> +
> +	priv->pd_dev = devm_kmalloc_array(dev, priv->num_pd, sizeof(*priv->pd_dev), GFP_KERNEL);
> +	if (!priv->pd_dev)
> +		return -ENOMEM;
> +
> +	priv->pd_dev_link = devm_kmalloc_array(dev, priv->num_pd, sizeof(*priv->pd_dev_link),
> +					       GFP_KERNEL);
> +
> +	if (!priv->pd_dev_link)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < priv->num_pd; i++) {
> +		priv->pd_dev[i] = dev_pm_domain_attach_by_id(dev, i);
> +		if (IS_ERR(priv->pd_dev[i])) {
> +			ret = PTR_ERR(priv->pd_dev[i]);
> +			goto detach_pd;
> +		}
> +
> +		priv->pd_dev_link[i] = device_link_add(dev, priv->pd_dev[i], DL_FLAG_STATELESS |
> +						       DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
> +		if (!priv->pd_dev_link[i]) {
> +			dev_pm_domain_detach(priv->pd_dev[i], false);
> +			ret = -EINVAL;
> +			goto detach_pd;
> +		}
> +	}
> +
> +	return 0;
> +
> +detach_pd:
> +	while (--i >= 0) {
> +		device_link_del(priv->pd_dev_link[i]);
> +		dev_pm_domain_detach(priv->pd_dev[i], false);
> +	}
> +
> +	return ret;
> +}
> +
>  static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  {
>  	struct regmap_config config = { .name = "imx-rproc" };
> @@ -749,13 +809,13 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  			return ret;
>  		}
>  
> +		priv->has_clk = false;

This statement seems to imply that for imx8qxq processors, which is the only one
to use the IMX_RPROC_SCU_API, priv->has_clk is always false.  If so then why
bother with a flag at all?

More comments tomorrow...

>  		/*
>  		 * If Mcore resource is not owned by Acore partition, It is kicked by ROM,
>  		 * and Linux could only do IPC with Mcore and nothing else.
>  		 */
>  		if (!imx_sc_rm_is_resource_owned(priv->ipc_handle, priv->rsrc)) {
>  
> -			priv->has_clk = false;
>  			priv->rproc->self_recovery = true;
>  			priv->rproc->state = RPROC_DETACHED;
>  
> @@ -782,6 +842,8 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  				dev_warn(dev, "Enable irq failed.\n");
>  				return ret;
>  			}
> +		} else {
> +			return imx_rproc_attach_pd(priv);
>  		}
>  
>  		return 0;
> -- 
> 2.25.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-19 19:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11  3:33 [PATCH V2] remoteproc: imx_rproc: use imx specific hook for find_loaded_rsc_table Peng Fan (OSS)
2022-01-11  3:33 ` [PATCH] remoteproc: imx_rproc: validate resource table Peng Fan (OSS)
2022-01-17 18:25   ` Mathieu Poirier
2022-01-18  1:24     ` Peng Fan
2022-01-11  3:33 ` [PATCH 0/9] remoteproc: imx_rproc: support i.MX8QXP/QM and self recovery Peng Fan (OSS)
2022-01-11  3:33 ` [PATCH 1/9] dt-bindings: remoteproc: imx_rproc: support i.MX8QXP Peng Fan (OSS)
2022-01-11  6:44   ` Peng Fan
2022-01-18 18:41   ` Mathieu Poirier
2022-01-19  2:20     ` Peng Fan
2022-01-11  3:33 ` [PATCH 2/9] dt-bindings: remoteproc: imx_rproc: support i.MX8QM Peng Fan (OSS)
2022-01-11  6:45   ` Peng Fan
2022-01-11  3:33 ` [PATCH 3/9] remoteproc: support self recovery after rproc crash Peng Fan (OSS)
2022-01-18 18:44   ` Mathieu Poirier
2022-01-19  2:21     ` Peng Fan
2022-01-11  3:33 ` [PATCH 4/9] remoteproc: imx_rproc: ignore create mem entry for resource table Peng Fan (OSS)
2022-01-18 18:47   ` Mathieu Poirier
2022-01-19  2:23     ` Peng Fan
2022-01-11  3:33 ` [PATCH 5/9] remoteproc: imx_rproc: make clk optional Peng Fan (OSS)
2022-01-18 18:50   ` Mathieu Poirier
2022-01-19  2:25     ` Peng Fan
2022-01-19 17:49       ` Mathieu Poirier
2022-01-11  3:33 ` [PATCH 6/9] remoteproc: imx_rproc: support attaching to i.MX8QXP M4 Peng Fan (OSS)
2022-01-18 18:57   ` Mathieu Poirier
2022-01-19  2:28     ` Peng Fan
2022-01-19 18:04       ` Mathieu Poirier
2022-01-19 18:31   ` Mathieu Poirier
2022-01-11  3:33 ` [PATCH 7/9] remoteproc: imx_rproc: support kicking Mcore from Linux for i.MX8QXP Peng Fan (OSS)
2022-01-19 18:58   ` Mathieu Poirier [this message]
2022-01-11  3:33 ` [PATCH 8/9] remoteproc: imx_rproc: support i.MX8QM Peng Fan (OSS)
2022-01-20 17:23   ` Mathieu Poirier
2022-01-21  1:00     ` Peng Fan
2022-01-11  3:33 ` [PATCH 9/9] remoteproc: imx_rproc: request mbox channel later Peng Fan (OSS)
2022-12-21 10:55 ` [PATCH V2] remoteproc: imx_rproc: use imx specific hook for find_loaded_rsc_table Marco Felsch
2023-01-02 22:46   ` Mathieu Poirier

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=20220119185852.GB1284752@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.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).