From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: "TingHan Shen (沈廷翰)" <TingHan.Shen@mediatek.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"linux-remoteproc@vger.kernel.org"
<linux-remoteproc@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"krzysztof.kozlowski+dt@linaro.org"
<krzysztof.kozlowski+dt@linaro.org>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"andersson@kernel.org" <andersson@kernel.org>,
"angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH v9 05/11] remoteproc: mediatek: Extract remoteproc initialization flow
Date: Wed, 19 Apr 2023 09:09:47 -0600 [thread overview]
Message-ID: <ZEAEO3ZOptIoIskz@p14s> (raw)
In-Reply-To: <46baff1f95fa13976d7a07b5e50ff2175e464baa.camel@mediatek.com>
On Wed, Apr 19, 2023 at 03:38:14AM +0000, TingHan Shen (沈廷翰) wrote:
> Hi Mathieu,
>
> On Fri, 2023-03-31 at 11:44 -0600, Mathieu Poirier wrote:
> > External email : Please do not click links or open attachments until you have verified the sender or the content.
> >
> >
> > On Tue, Mar 28, 2023 at 10:27:27AM +0800, Tinghan Shen wrote:
> > > This is the preparation for probing multi-core SCP. The remoteproc
> > > initialization flow is similar on cores and is reused to avoid
> > > redundant code.
> > >
> > > The registers of config and l1tcm are shared for multi-core
> > > SCP. Reuse the mapped addresses for all cores.
> > >
> > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > ---
> > > drivers/remoteproc/mtk_scp.c | 64 +++++++++++++++++++++++++-----------
> > > 1 file changed, 45 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> > > index a3b9bc158cd9..32ecd1450c6f 100644
> > > --- a/drivers/remoteproc/mtk_scp.c
> > > +++ b/drivers/remoteproc/mtk_scp.c
> > > @@ -23,6 +23,13 @@
> > > #define MAX_CODE_SIZE 0x500000
> > > #define SECTION_NAME_IPI_BUFFER ".ipi_buffer"
> > >
> > > +struct mtk_scp_of_regs {
> > > + void __iomem *reg_base;
> > > + void __iomem *l1tcm_base;
> > > + size_t l1tcm_size;
> > > + phys_addr_t l1tcm_phys;
> > > +};
> > > +
> >
> > This should represent the cluster with a list of mtk_scp instead of @cluster_cores as
> > introduced in the next patch.
>
> If I'm understanding you correctly, you're suggesting that @cluster_cores should be included
> as a member of this structure. Is that correct?
Correct. Than this structure is allocated in probe() and added as driver data
for the platform device. Its name should also be something like
mtk_scp_cluster or something like that. I suggest you look at what has been
done in ti_k3_r5_remoteproc.c, your end design should be quite similar to that.
In fact you are close but a few things need to be addressed.
>
> Best regards,
> TingHan
>
> >
> > > /**
> > > * scp_get() - get a reference to SCP.
> > > *
> > > @@ -855,7 +862,8 @@ static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
> > > }
> > > }
> > >
> > > -static int scp_probe(struct platform_device *pdev)
> > > +static int scp_rproc_init(struct platform_device *pdev,
> > > + struct mtk_scp_of_regs *of_regs)
> > > {
> > > struct device *dev = &pdev->dev;
> > > struct device_node *np = dev->of_node;
> > > @@ -879,6 +887,11 @@ static int scp_probe(struct platform_device *pdev)
> > > scp->data = of_device_get_match_data(dev);
> > > platform_set_drvdata(pdev, scp);
> > >
> > > + scp->reg_base = of_regs->reg_base;
> > > + scp->l1tcm_base = of_regs->l1tcm_base;
> > > + scp->l1tcm_size = of_regs->l1tcm_size;
> > > + scp->l1tcm_phys = of_regs->l1tcm_phys;
> > > +
> > > res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
> > > scp->sram_base = devm_ioremap_resource(dev, res);
> > > if (IS_ERR(scp->sram_base))
> > > @@ -888,24 +901,6 @@ static int scp_probe(struct platform_device *pdev)
> > > scp->sram_size = resource_size(res);
> > > scp->sram_phys = res->start;
> > >
> > > - /* l1tcm is an optional memory region */
> > > - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "l1tcm");
> > > - scp->l1tcm_base = devm_ioremap_resource(dev, res);
> > > - if (IS_ERR(scp->l1tcm_base)) {
> > > - ret = PTR_ERR(scp->l1tcm_base);
> > > - if (ret != -EINVAL) {
> > > - return dev_err_probe(dev, ret, "Failed to map l1tcm memory\n");
> > > - }
> > > - } else {
> >
> > scp->l1tcm_base = NULL;
> >
> > > - scp->l1tcm_size = resource_size(res);
> > > - scp->l1tcm_phys = res->start;
> > > - }
> > > -
> > > - scp->reg_base = devm_platform_ioremap_resource_byname(pdev, "cfg");
> > > - if (IS_ERR(scp->reg_base))
> > > - return dev_err_probe(dev, PTR_ERR(scp->reg_base),
> > > - "Failed to parse and map cfg memory\n");
> > > -
> > > ret = scp->data->scp_clk_get(scp);
> > > if (ret)
> > > return ret;
> > > @@ -957,6 +952,37 @@ static int scp_probe(struct platform_device *pdev)
> > > return ret;
> > > }
> > >
> > > +static int scp_probe(struct platform_device *pdev)
> > > +{
> > > + struct device *dev = &pdev->dev;
> > > + struct mtk_scp_of_regs scp_regs;
> > > + struct resource *res;
> > > + int ret;
> > > +
> > > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
> > > + scp_regs.reg_base = devm_ioremap_resource(dev, res);
> > > + if (IS_ERR(scp_regs.reg_base))
> > > + return dev_err_probe(dev, PTR_ERR(scp_regs.reg_base),
> > > + "Failed to parse and map cfg memory\n");
> > > +
> > > + /* l1tcm is an optional memory region */
> > > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "l1tcm");
> > > + scp_regs.l1tcm_base = devm_ioremap_resource(dev, res);
> > > + if (IS_ERR(scp_regs.l1tcm_base)) {
> > > + ret = PTR_ERR(scp_regs.l1tcm_base);
> > > + if (ret != -EINVAL)
> > > + return dev_err_probe(dev, ret, "Failed to map l1tcm memory\n");
> > > +
> > > + scp_regs.l1tcm_size = 0;
> > > + scp_regs.l1tcm_phys = 0;
> > > + } else {
> > > + scp_regs.l1tcm_size = resource_size(res);
> > > + scp_regs.l1tcm_phys = res->start;
> > > + }
> > > +
> > > + return scp_rproc_init(pdev, &scp_regs);
> > > +}
> > > +
> > > static int scp_remove(struct platform_device *pdev)
> > > {
> > > struct mtk_scp *scp = platform_get_drvdata(pdev);
> > > --
> > > 2.18.0
> > >
>
> --
> Best regards,
> TingHan
next prev parent reply other threads:[~2023-04-19 15:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 2:27 [PATCH v9 00/11] Add support for MT8195 SCP 2nd core Tinghan Shen
2023-03-28 2:27 ` [PATCH v9 01/11] dt-bindings: remoteproc: mediatek: Improve the rpmsg subnode definition Tinghan Shen
2023-03-28 2:27 ` [PATCH v9 02/11] arm64: dts: mediatek: Update the node name of SCP rpmsg subnode Tinghan Shen
2023-03-31 10:57 ` Matthias Brugger
2023-03-28 2:27 ` [PATCH v9 03/11] dt-bindings: remoteproc: mediatek: Support MT8195 dual-core SCP Tinghan Shen
2023-03-28 2:27 ` [PATCH v9 04/11] remoteproc: mediatek: Add MT8195 SCP core 1 operations Tinghan Shen
2023-03-28 2:27 ` [PATCH v9 05/11] remoteproc: mediatek: Extract remoteproc initialization flow Tinghan Shen
2023-03-31 17:44 ` Mathieu Poirier
2023-04-19 3:38 ` TingHan Shen (沈廷翰)
2023-04-19 15:09 ` Mathieu Poirier [this message]
2023-03-28 2:27 ` [PATCH v9 06/11] remoteproc: mediatek: Probe multi-core SCP Tinghan Shen
2023-03-31 17:53 ` Mathieu Poirier
2023-03-28 2:27 ` [PATCH v9 07/11] remoteproc: mediatek: Control SCP core 1 by rproc subdevice Tinghan Shen
2023-03-28 2:27 ` [PATCH v9 08/11] remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offset Tinghan Shen
2023-03-28 2:27 ` [PATCH v9 09/11] remoteproc: mediatek: Handle MT8195 SCP core 1 watchdog timeout Tinghan Shen
2023-03-28 2:27 ` [PATCH v9 10/11] remoteproc: mediatek: Refine ipi handler error message Tinghan Shen
2023-03-28 2:27 ` [PATCH v9 11/11] arm64: dts: mediatek: mt8195: Add SCP 2nd core Tinghan Shen
2023-03-31 10:59 ` Matthias Brugger
2023-04-03 17:25 ` 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=ZEAEO3ZOptIoIskz@p14s \
--to=mathieu.poirier@linaro.org \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=TingHan.Shen@mediatek.com \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=robh+dt@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).