[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b4d9dfbdc6684e59bec149f80897bd42@SFHDAG7NODE2.st.com>
Date: Mon, 14 May 2018 15:03:00 +0000
From: Loic PALLARDY <loic.pallardy@...com>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
CC: "ohad@...ery.com" <ohad@...ery.com>,
"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Arnaud POULIQUEN <arnaud.pouliquen@...com>,
"benjamin.gaignard@...aro.org" <benjamin.gaignard@...aro.org>
Subject: RE: [PATCH v3 08/13] remoteproc: add prepare and unprepare ops
> -----Original Message-----
> From: Bjorn Andersson [mailto:bjorn.andersson@...aro.org]
> Sent: Thursday, May 10, 2018 2:53 AM
> To: Loic PALLARDY <loic.pallardy@...com>
> Cc: ohad@...ery.com; linux-remoteproc@...r.kernel.org; linux-
> kernel@...r.kernel.org; Arnaud POULIQUEN <arnaud.pouliquen@...com>;
> benjamin.gaignard@...aro.org
> Subject: Re: [PATCH v3 08/13] remoteproc: add prepare and unprepare ops
>
> On Thu 01 Mar 08:23 PST 2018, Loic Pallardy wrote:
>
> > 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@...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 7a500cb..0ebbc4f 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1058,12 +1058,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);
> > + if (ret) {
> > + dev_err(dev, "can't prepare rproc %s: %d\n",
> > + rproc->name, ret);
> > + goto disable_iommu;
> > + }
> > + }
>
> We do allow drivers to implement custom versions of parse_fw() - and
> they can call the resource-table-parse-fw from the custom function.
>
> So with the proposed refactoring in patch 9 I would like for parse_fw()
> to call back into the core to fill out the resource lists and then
> before jumping to rproc_start() we loop over the allocator functions.
Agree
Regards,
Loic
>
> > +
> > rproc->bootaddr = rproc_get_boot_addr(rproc, fw);
> >
> > /* load resource table */
> > ret = rproc_load_rsc_table(rproc, fw);
> > if (ret)
> > - goto disable_iommu;
> > + goto unprepare_rproc;
> >
> > /* reset max_notifyid */
> > rproc->max_notifyid = -1;
> > @@ -1086,6 +1096,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;
> > @@ -1331,6 +1345,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);
>
> And this would then be handled by the rproc_resource_cleanup() function,
> looping over all resources and calling release().
>
> Regards,
> Bjorn
Powered by blists - more mailing lists