From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F3591C433EF for ; Wed, 19 Jan 2022 19:00:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=RFpxs8BeZvV5pu7T2OtuM8BXtgYod8MVICUArJzrAQw=; b=M7BwNs3UTabncY /mcsd16URUd8Kqw7rd3Xh5plRKvTvM00cj7vDDp9sWw049fBVyOW3l15D8ibLTN2imx7/b8qSufX7 RkxFFa3H6drlMPj0GRTUUHgNmwZB/Dy9F+NUJRqEel50zEyMcerXDbOyYPfclS1YYDKRJBU3YOEq7 ugEildW8D+wajd/oQzcNAmaOprzYzW7XsJpU6ya3FF0geunwDJzalRXgR8pcLrH3gE3vLLAxf4MaL cPAVZB9o4BUP7H/d81qDJlvgDVztxk2WgnKfgMrUrBL9PxHE0ULMeHELVrLrQgwzaCcoiztci8Lnx xsqNZLIGPr/4dCt6Z78w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nAGAf-006v4w-V5; Wed, 19 Jan 2022 18:59:02 +0000 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nAGAc-006v3O-A3 for linux-arm-kernel@lists.infradead.org; Wed, 19 Jan 2022 18:59:00 +0000 Received: by mail-pj1-x1036.google.com with SMTP id d5so912757pjk.5 for ; Wed, 19 Jan 2022 10:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KVCbO/zBQSuPDv2Qo3g+XS7TOlXwA0ETja4CXg7oELk=; b=FN/qNvZs6asA+BpDQPhKVkibYzKevrkQfKWzy3s+8cuVDYVGMaHWKJV9P6O6k1Q8TI /+54N8YcRba/sObW6AnQnfTOUd9GJP3JS6Xx2ZT85uD2bLFuEIIoiWhTG7Nd0NO1CzJX RgeMVA6O1orM+3PgaE6XdrlhLFcuoHko0WrWPfhP7HJtgvvsr3q8lMCe7wV6lLllsJ3n llLKpoDvBT7lWef6l2Cnh5r75CWfwMMKnT4vaPs1Tik6zScRyvlnN6tr+eOGPBa6in3E fTctY1FlpfDQPFpWvqbLBeCVtJX1S8QmQdKpD4g4MWFZ11svTtVlrAq/ZoXPXivv+Ly8 5lUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KVCbO/zBQSuPDv2Qo3g+XS7TOlXwA0ETja4CXg7oELk=; b=LfoT6Op0Ut8f3lit5nSMp2FBi39394yuB9GxgbqI3qZUA4qaIYuc+9ndJBMgKp6G0x rCQzpKN6xc9+FGOWS6ltzvsaw5Odv7vxLCCn7z3tTUw2lxMJXRjwKT4BaaMyIZ4Sb3aL MW3Cuy9SR/9Qh3Mw6kKffpM2FhiKEV/XVYN/g1x5ZSaD1CF6lkdNVbaUmHn/WpEcJ887 opYdBNuDpZzXQXkOflHlr3OWrVubeWp01/wW63zAoe87qd+fK64gbl8jW0lsDhlziEUJ QSNLdXtJuBU2EYzTOJQvQyyrshFnM42uFtMEbZ/+ou9wAaXNW4ylC0lvkuHNyftHd0qg gRmA== X-Gm-Message-State: AOAM530DZJYlKiKpWM8X5ZsUJzlj6PbT9y4GINO409mWZ+cgL8bNlzKh TM5Kz1WoDmlgifGFnzsPw7s7eg== X-Google-Smtp-Source: ABdhPJypgOfByERIAkxGzI7t3DN2HEXlgJPIuzEhjJYKpf4Aq+W6RWVuLkHKcRDFka7cx5qjAB+5yA== X-Received: by 2002:a17:902:7d8f:b0:14a:b712:bbfb with SMTP id a15-20020a1709027d8f00b0014ab712bbfbmr17292816plm.63.1642618736462; Wed, 19 Jan 2022 10:58:56 -0800 (PST) Received: from p14s (S0106889e681aac74.cg.shawcable.net. [68.147.0.187]) by smtp.gmail.com with ESMTPSA id x7sm375505pfh.178.2022.01.19.10.58.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jan 2022 10:58:54 -0800 (PST) Date: Wed, 19 Jan 2022 11:58:52 -0700 From: Mathieu Poirier To: "Peng Fan (OSS)" 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 Subject: Re: [PATCH 7/9] remoteproc: imx_rproc: support kicking Mcore from Linux for i.MX8QXP Message-ID: <20220119185852.GB1284752@p14s> References: <20220111033333.403448-1-peng.fan@oss.nxp.com> <20220111033333.403448-10-peng.fan@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220111033333.403448-10-peng.fan@oss.nxp.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220119_105858_424465_761A2222 X-CRM114-Status: GOOD ( 34.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 11, 2022 at 11:33:31AM +0800, Peng Fan (OSS) wrote: > From: Peng Fan > > 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 > --- > 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 > #include > #include > +#include > #include > #include > #include > @@ -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