From: Mathieu Poirier <mathieu.poirier@linaro.org> To: Suman Anna <s-anna@ti.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Lokesh Vutla <lokeshvutla@ti.com>, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Loic Pallardy <loic.pallardy@st.com> Subject: Re: [PATCH 1/7] remoteproc: add prepare and unprepare ops Date: Mon, 6 Apr 2020 11:20:18 -0600 [thread overview] Message-ID: <20200406172018.GA11572@xps15> (raw) In-Reply-To: <20200324201819.23095-2-s-anna@ti.com> Good morning Suman, I have started to work on this set - comments will come in over the next few days... On Tue, Mar 24, 2020 at 03:18:13PM -0500, Suman Anna wrote: > From: Loic Pallardy <loic.pallardy@st.com> > > On some SoC architecture, it is needed to enable HW like > clock, bus, regulator, memory region... before loading > co-processor firmware. > > This patch introduces prepare and unprepare ops to execute > platform specific function before firmware loading and after > stop execution. > > Signed-off-by: Loic Pallardy <loic.pallardy@st.com> > Signed-off-by: Suman Anna <s-anna@ti.com> > --- > drivers/remoteproc/remoteproc_core.c | 20 +++++++++++++++++++- > include/linux/remoteproc.h | 4 ++++ > 2 files changed, 23 insertions(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index 26f6947267d2..aca6d022901a 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1394,12 +1394,22 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw) > return ret; > } > > + /* Prepare rproc for firmware loading if needed */ > + if (rproc->ops->prepare) { > + ret = rproc->ops->prepare(rproc); In my patchset on MCU synchronisation I have moved ops->{start/stop} to remoteproc_internal.h and called them rproc_start/stop_device() (after Loic's suggestion). In order to be consistent and remove boiler plate code in the core we could do the same, i.e have rproc_prepare/unprepare_device() in remoteproc_internal.h . With the above: Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Thanks, Mathieu > + if (ret) { > + dev_err(dev, "can't prepare rproc %s: %d\n", > + rproc->name, ret); > + goto disable_iommu; > + } > + } > + > rproc->bootaddr = rproc_get_boot_addr(rproc, fw); > > /* Load resource table, core dump segment list etc from the firmware */ > ret = rproc_parse_fw(rproc, fw); > if (ret) > - goto disable_iommu; > + goto unprepare_rproc; > > /* reset max_notifyid */ > rproc->max_notifyid = -1; > @@ -1433,6 +1443,10 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw) > kfree(rproc->cached_table); > rproc->cached_table = NULL; > rproc->table_ptr = NULL; > +unprepare_rproc: > + /* release HW resources if needed */ > + if (rproc->ops->unprepare) > + rproc->ops->unprepare(rproc); > disable_iommu: > rproc_disable_iommu(rproc); > return ret; > @@ -1838,6 +1852,10 @@ void rproc_shutdown(struct rproc *rproc) > /* clean up all acquired resources */ > rproc_resource_cleanup(rproc); > > + /* release HW resources if needed */ > + if (rproc->ops->unprepare) > + rproc->ops->unprepare(rproc); > + > rproc_disable_iommu(rproc); > > /* Free the copy of the resource table */ > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index 07bd73a6d72a..ddce7a7775d1 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -355,6 +355,8 @@ enum rsc_handling_status { > > /** > * struct rproc_ops - platform-specific device handlers > + * @prepare: prepare device for code loading > + * @unprepare: unprepare device after stop > * @start: power on the device and boot it > * @stop: power off the device > * @kick: kick a virtqueue (virtqueue id given as a parameter) > @@ -371,6 +373,8 @@ enum rsc_handling_status { > * @get_boot_addr: get boot address to entry point specified in firmware > */ > struct rproc_ops { > + int (*prepare)(struct rproc *rproc); > + int (*unprepare)(struct rproc *rproc); > int (*start)(struct rproc *rproc); > int (*stop)(struct rproc *rproc); > void (*kick)(struct rproc *rproc, int vqid); > -- > 2.23.0 >
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Poirier <mathieu.poirier@linaro.org> To: Suman Anna <s-anna@ti.com> Cc: devicetree@vger.kernel.org, Loic Pallardy <loic.pallardy@st.com>, Lokesh Vutla <lokeshvutla@ti.com>, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/7] remoteproc: add prepare and unprepare ops Date: Mon, 6 Apr 2020 11:20:18 -0600 [thread overview] Message-ID: <20200406172018.GA11572@xps15> (raw) In-Reply-To: <20200324201819.23095-2-s-anna@ti.com> Good morning Suman, I have started to work on this set - comments will come in over the next few days... On Tue, Mar 24, 2020 at 03:18:13PM -0500, Suman Anna wrote: > From: Loic Pallardy <loic.pallardy@st.com> > > On some SoC architecture, it is needed to enable HW like > clock, bus, regulator, memory region... before loading > co-processor firmware. > > This patch introduces prepare and unprepare ops to execute > platform specific function before firmware loading and after > stop execution. > > Signed-off-by: Loic Pallardy <loic.pallardy@st.com> > Signed-off-by: Suman Anna <s-anna@ti.com> > --- > drivers/remoteproc/remoteproc_core.c | 20 +++++++++++++++++++- > include/linux/remoteproc.h | 4 ++++ > 2 files changed, 23 insertions(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index 26f6947267d2..aca6d022901a 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1394,12 +1394,22 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw) > return ret; > } > > + /* Prepare rproc for firmware loading if needed */ > + if (rproc->ops->prepare) { > + ret = rproc->ops->prepare(rproc); In my patchset on MCU synchronisation I have moved ops->{start/stop} to remoteproc_internal.h and called them rproc_start/stop_device() (after Loic's suggestion). In order to be consistent and remove boiler plate code in the core we could do the same, i.e have rproc_prepare/unprepare_device() in remoteproc_internal.h . With the above: Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Thanks, Mathieu > + if (ret) { > + dev_err(dev, "can't prepare rproc %s: %d\n", > + rproc->name, ret); > + goto disable_iommu; > + } > + } > + > rproc->bootaddr = rproc_get_boot_addr(rproc, fw); > > /* Load resource table, core dump segment list etc from the firmware */ > ret = rproc_parse_fw(rproc, fw); > if (ret) > - goto disable_iommu; > + goto unprepare_rproc; > > /* reset max_notifyid */ > rproc->max_notifyid = -1; > @@ -1433,6 +1443,10 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw) > kfree(rproc->cached_table); > rproc->cached_table = NULL; > rproc->table_ptr = NULL; > +unprepare_rproc: > + /* release HW resources if needed */ > + if (rproc->ops->unprepare) > + rproc->ops->unprepare(rproc); > disable_iommu: > rproc_disable_iommu(rproc); > return ret; > @@ -1838,6 +1852,10 @@ void rproc_shutdown(struct rproc *rproc) > /* clean up all acquired resources */ > rproc_resource_cleanup(rproc); > > + /* release HW resources if needed */ > + if (rproc->ops->unprepare) > + rproc->ops->unprepare(rproc); > + > rproc_disable_iommu(rproc); > > /* Free the copy of the resource table */ > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index 07bd73a6d72a..ddce7a7775d1 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -355,6 +355,8 @@ enum rsc_handling_status { > > /** > * struct rproc_ops - platform-specific device handlers > + * @prepare: prepare device for code loading > + * @unprepare: unprepare device after stop > * @start: power on the device and boot it > * @stop: power off the device > * @kick: kick a virtqueue (virtqueue id given as a parameter) > @@ -371,6 +373,8 @@ enum rsc_handling_status { > * @get_boot_addr: get boot address to entry point specified in firmware > */ > struct rproc_ops { > + int (*prepare)(struct rproc *rproc); > + int (*unprepare)(struct rproc *rproc); > int (*start)(struct rproc *rproc); > int (*stop)(struct rproc *rproc); > void (*kick)(struct rproc *rproc, int vqid); > -- > 2.23.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-06 17:20 UTC|newest] Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-24 20:18 [PATCH 0/7] TI K3 R5F remoteproc support Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` [PATCH 1/7] remoteproc: add prepare and unprepare ops Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-26 19:50 ` Bjorn Andersson 2020-03-26 19:51 ` Bjorn Andersson 2020-03-26 19:50 ` Bjorn Andersson 2020-04-06 17:20 ` Mathieu Poirier [this message] 2020-04-06 17:20 ` Mathieu Poirier 2020-04-08 23:39 ` Suman Anna 2020-04-08 23:39 ` Suman Anna 2020-04-08 23:39 ` Suman Anna 2020-03-24 20:18 ` [PATCH 2/7] remoteproc: use a local copy for the name field Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-26 5:42 ` Bjorn Andersson 2020-03-26 5:42 ` Bjorn Andersson 2020-03-26 5:42 ` Bjorn Andersson 2020-03-26 14:01 ` Suman Anna 2020-03-26 14:01 ` Suman Anna 2020-03-26 14:01 ` Suman Anna 2020-03-26 19:43 ` Bjorn Andersson 2020-03-26 19:43 ` Bjorn Andersson 2020-03-26 19:43 ` Bjorn Andersson 2020-03-26 20:35 ` Suman Anna 2020-03-26 20:35 ` Suman Anna 2020-03-26 20:35 ` Suman Anna 2020-03-24 20:18 ` [PATCH 3/7] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-26 16:28 ` Rob Herring 2020-03-26 16:28 ` Rob Herring 2020-03-26 16:28 ` Rob Herring 2020-03-26 18:09 ` Suman Anna 2020-03-26 18:09 ` Suman Anna 2020-03-26 18:09 ` Suman Anna 2020-03-26 16:53 ` Rob Herring 2020-03-26 16:53 ` Rob Herring 2020-03-26 16:53 ` Rob Herring 2020-04-09 0:02 ` Suman Anna 2020-04-09 0:02 ` Suman Anna 2020-04-09 0:02 ` Suman Anna 2020-04-09 0:15 ` Suman Anna 2020-04-09 0:15 ` Suman Anna 2020-04-09 0:15 ` Suman Anna 2020-04-06 19:59 ` Mathieu Poirier 2020-04-06 19:59 ` Mathieu Poirier 2020-04-09 0:12 ` Suman Anna 2020-04-09 0:12 ` Suman Anna 2020-04-09 0:12 ` Suman Anna 2020-03-24 20:18 ` [PATCH 4/7] remoteproc/k3-r5: Add TI-SCI processor control helper functions Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` [PATCH 5/7] remoteproc/k3-r5: Add a remoteproc driver for R5F subsystem Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-04-07 18:08 ` Mathieu Poirier 2020-04-07 18:08 ` Mathieu Poirier 2020-04-09 0:26 ` Suman Anna 2020-04-09 0:26 ` Suman Anna 2020-04-09 0:26 ` Suman Anna 2020-04-08 19:38 ` Mathieu Poirier 2020-04-08 19:38 ` Mathieu Poirier 2020-04-15 22:30 ` Suman Anna 2020-04-15 22:30 ` Suman Anna 2020-04-15 22:30 ` Suman Anna 2020-04-09 21:25 ` Mathieu Poirier 2020-04-09 21:25 ` Mathieu Poirier 2020-04-15 22:44 ` Suman Anna 2020-04-15 22:44 ` Suman Anna 2020-04-15 22:44 ` Suman Anna 2020-04-16 20:11 ` Mathieu Poirier 2020-04-16 20:11 ` Mathieu Poirier 2020-03-24 20:18 ` [PATCH 6/7] remoteproc/k3-r5: Initialize TCM memories for ECC Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-04-09 21:36 ` Mathieu Poirier 2020-04-09 21:36 ` Mathieu Poirier 2020-04-09 22:01 ` Suman Anna 2020-04-09 22:01 ` Suman Anna 2020-04-09 22:01 ` Suman Anna 2020-03-24 20:18 ` [PATCH 7/7] remoteproc/k3-r5: Add loading support for on-chip SRAM regions Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-03-24 20:18 ` Suman Anna 2020-04-10 20:30 ` Mathieu Poirier 2020-04-10 20:30 ` 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=20200406172018.GA11572@xps15 \ --to=mathieu.poirier@linaro.org \ --cc=bjorn.andersson@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=loic.pallardy@st.com \ --cc=lokeshvutla@ti.com \ --cc=robh+dt@kernel.org \ --cc=s-anna@ti.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.