From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: ohad@wizery.com, bjorn.andersson@linaro.org,
arnaud.pouliquen@st.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, alexandre.torgue@st.com,
linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 07/19] remoteproc: Add new get_loaded_rsc_table() to rproc_ops
Date: Wed, 17 Feb 2021 14:22:51 -0700 [thread overview]
Message-ID: <20210217212251.GA2800385@xps15> (raw)
In-Reply-To: <406fe414-f454-c91d-8bbd-ce323a9612e7@foss.st.com>
On Mon, Feb 15, 2021 at 02:10:10PM +0100, Arnaud POULIQUEN wrote:
> Hi Mathieu,
>
> On 2/12/21 12:46 AM, Mathieu Poirier wrote:
> > Add a new get_loaded_rsc_table() operation in order to support
> > scenarios where the remoteproc core has booted a remote processor
> > and detaches from it. When re-attaching to the remote processor,
> > the core needs to know where the resource table has been placed
> > in memory.
> >
> > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > ---
> > New for V5:
> > - Added function rproc_set_loaded_rsc_table() to keep rproc_attach() clean.
> > - Setting ->cached_table, ->table_ptr and ->table_sz in the remoteproc core
> > rather than the platform drivers.
> > ---
> > drivers/remoteproc/remoteproc_core.c | 35 ++++++++++++++++++++++++
> > drivers/remoteproc/remoteproc_internal.h | 10 +++++++
> > include/linux/remoteproc.h | 6 +++-
> > 3 files changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > index e6606d10a4c8..741bc20de437 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1537,6 +1537,35 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
> > return ret;
> > }
> >
> > +static int rproc_set_loaded_rsc_table(struct rproc *rproc)
> > +{
> > + struct resource_table *table_ptr;
> > + struct device *dev = &rproc->dev;
> > + size_t table_sz;
> > + int ret;
> > +
> > + table_ptr = rproc_get_loaded_rsc_table(rproc, &table_sz);
> > + if (IS_ERR_OR_NULL(table_ptr)) {
> > + if (!table_ptr)
> > + ret = -EINVAL;
>
> I did few tests on this showing that this approach does not cover all use cases.
>
> The first one is a firmware without resource table. In this case table_ptr
> should be null, or we have to consider the -ENOENT error as a non error usecase.
>
Right, I'll provision for those cases.
> The second one, more tricky, is a firmware started by the remoteproc framework.
> In this case the resource table address is retrieved from the ELF file by the
> core part.
Correct.
> So if we detach and reattach rproc_get_loaded_rsc_table cannot return the
> address. Look to me that we should have also an alocation of the clean_table in
> rproc_start and then to keep the memory allocated until a shutdown.
I assumed the address of the resource table found in the ELF image was the same
as the one known by the platform driver. In hindsight I realise the platform
driver may not know that address.
>
> That said regarding the complexity to re-attach, I wonder if it would not be
> better to focus first on a simple detach, and address the reattachment in a
> separate series, to move forward in stages.
I agree that OFFLINE -> RUNNING -> DETACHED -> ATTACHED is introducing some
complexity related to the management of the resource table that where not
expected. We could concentrate on a simple detach and see where that takes us.
It would also mean to get rid of the "autonomous-on-core-shutdown" DT binding.
Thanks,
Mathieu
>
> Regards,
> Arnaud
>
> > + else
> > + ret = PTR_ERR(table_ptr);
> > +
> > + dev_err(dev, "can't load resource table: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + /*
> > + * The resource table is already loaded in device memory, no need
> > + * to work with a cached table.
> > + */
> > + rproc->cached_table = NULL;
> > + rproc->table_ptr = table_ptr;
> > + rproc->table_sz = table_sz;
> > +
> > + return 0;
> > +}
> > +
> > /*
> > * Attach to remote processor - similar to rproc_fw_boot() but without
> > * the steps that deal with the firmware image.
> > @@ -1556,6 +1585,12 @@ static int rproc_attach(struct rproc *rproc)
> > return ret;
> > }
> >
> > + ret = rproc_set_loaded_rsc_table(rproc);
> > + if (ret) {
> > + dev_err(dev, "can't load resource table: %d\n", ret);
> > + goto disable_iommu;
> > + }
> > +
> > /* reset max_notifyid */
> > rproc->max_notifyid = -1;
> >
> > diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> > index c34002888d2c..4f73aac7e60d 100644
> > --- a/drivers/remoteproc/remoteproc_internal.h
> > +++ b/drivers/remoteproc/remoteproc_internal.h
> > @@ -177,6 +177,16 @@ struct resource_table *rproc_find_loaded_rsc_table(struct rproc *rproc,
> > return NULL;
> > }
> >
> > +static inline
> > +struct resource_table *rproc_get_loaded_rsc_table(struct rproc *rproc,
> > + size_t *size)
> > +{
> > + if (rproc->ops->get_loaded_rsc_table)
> > + return rproc->ops->get_loaded_rsc_table(rproc, size);
> > +
> > + return NULL;
> > +}
> > +
> > static inline
> > bool rproc_u64_fit_in_size_t(u64 val)
> > {
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index 6b0a0ed30a03..51538a7d120d 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -368,7 +368,9 @@ enum rsc_handling_status {
> > * RSC_HANDLED if resource was handled, RSC_IGNORED if not handled and a
> > * negative value on error
> > * @load_rsc_table: load resource table from firmware image
> > - * @find_loaded_rsc_table: find the loaded resouce table
> > + * @find_loaded_rsc_table: find the loaded resource table from firmware image
> > + * @get_loaded_rsc_table: get resource table installed in memory
> > + * by external entity
> > * @load: load firmware to memory, where the remote processor
> > * expects to find it
> > * @sanity_check: sanity check the fw image
> > @@ -390,6 +392,8 @@ struct rproc_ops {
> > int offset, int avail);
> > struct resource_table *(*find_loaded_rsc_table)(
> > struct rproc *rproc, const struct firmware *fw);
> > + struct resource_table *(*get_loaded_rsc_table)(
> > + struct rproc *rproc, size_t *size);
> > int (*load)(struct rproc *rproc, const struct firmware *fw);
> > int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
> > u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> >
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: ohad@wizery.com, devicetree@vger.kernel.org,
alexandre.torgue@st.com, linux-remoteproc@vger.kernel.org,
arnaud.pouliquen@st.com, linux-kernel@vger.kernel.org,
bjorn.andersson@linaro.org, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 07/19] remoteproc: Add new get_loaded_rsc_table() to rproc_ops
Date: Wed, 17 Feb 2021 14:22:51 -0700 [thread overview]
Message-ID: <20210217212251.GA2800385@xps15> (raw)
In-Reply-To: <406fe414-f454-c91d-8bbd-ce323a9612e7@foss.st.com>
On Mon, Feb 15, 2021 at 02:10:10PM +0100, Arnaud POULIQUEN wrote:
> Hi Mathieu,
>
> On 2/12/21 12:46 AM, Mathieu Poirier wrote:
> > Add a new get_loaded_rsc_table() operation in order to support
> > scenarios where the remoteproc core has booted a remote processor
> > and detaches from it. When re-attaching to the remote processor,
> > the core needs to know where the resource table has been placed
> > in memory.
> >
> > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > ---
> > New for V5:
> > - Added function rproc_set_loaded_rsc_table() to keep rproc_attach() clean.
> > - Setting ->cached_table, ->table_ptr and ->table_sz in the remoteproc core
> > rather than the platform drivers.
> > ---
> > drivers/remoteproc/remoteproc_core.c | 35 ++++++++++++++++++++++++
> > drivers/remoteproc/remoteproc_internal.h | 10 +++++++
> > include/linux/remoteproc.h | 6 +++-
> > 3 files changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > index e6606d10a4c8..741bc20de437 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1537,6 +1537,35 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
> > return ret;
> > }
> >
> > +static int rproc_set_loaded_rsc_table(struct rproc *rproc)
> > +{
> > + struct resource_table *table_ptr;
> > + struct device *dev = &rproc->dev;
> > + size_t table_sz;
> > + int ret;
> > +
> > + table_ptr = rproc_get_loaded_rsc_table(rproc, &table_sz);
> > + if (IS_ERR_OR_NULL(table_ptr)) {
> > + if (!table_ptr)
> > + ret = -EINVAL;
>
> I did few tests on this showing that this approach does not cover all use cases.
>
> The first one is a firmware without resource table. In this case table_ptr
> should be null, or we have to consider the -ENOENT error as a non error usecase.
>
Right, I'll provision for those cases.
> The second one, more tricky, is a firmware started by the remoteproc framework.
> In this case the resource table address is retrieved from the ELF file by the
> core part.
Correct.
> So if we detach and reattach rproc_get_loaded_rsc_table cannot return the
> address. Look to me that we should have also an alocation of the clean_table in
> rproc_start and then to keep the memory allocated until a shutdown.
I assumed the address of the resource table found in the ELF image was the same
as the one known by the platform driver. In hindsight I realise the platform
driver may not know that address.
>
> That said regarding the complexity to re-attach, I wonder if it would not be
> better to focus first on a simple detach, and address the reattachment in a
> separate series, to move forward in stages.
I agree that OFFLINE -> RUNNING -> DETACHED -> ATTACHED is introducing some
complexity related to the management of the resource table that where not
expected. We could concentrate on a simple detach and see where that takes us.
It would also mean to get rid of the "autonomous-on-core-shutdown" DT binding.
Thanks,
Mathieu
>
> Regards,
> Arnaud
>
> > + else
> > + ret = PTR_ERR(table_ptr);
> > +
> > + dev_err(dev, "can't load resource table: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + /*
> > + * The resource table is already loaded in device memory, no need
> > + * to work with a cached table.
> > + */
> > + rproc->cached_table = NULL;
> > + rproc->table_ptr = table_ptr;
> > + rproc->table_sz = table_sz;
> > +
> > + return 0;
> > +}
> > +
> > /*
> > * Attach to remote processor - similar to rproc_fw_boot() but without
> > * the steps that deal with the firmware image.
> > @@ -1556,6 +1585,12 @@ static int rproc_attach(struct rproc *rproc)
> > return ret;
> > }
> >
> > + ret = rproc_set_loaded_rsc_table(rproc);
> > + if (ret) {
> > + dev_err(dev, "can't load resource table: %d\n", ret);
> > + goto disable_iommu;
> > + }
> > +
> > /* reset max_notifyid */
> > rproc->max_notifyid = -1;
> >
> > diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> > index c34002888d2c..4f73aac7e60d 100644
> > --- a/drivers/remoteproc/remoteproc_internal.h
> > +++ b/drivers/remoteproc/remoteproc_internal.h
> > @@ -177,6 +177,16 @@ struct resource_table *rproc_find_loaded_rsc_table(struct rproc *rproc,
> > return NULL;
> > }
> >
> > +static inline
> > +struct resource_table *rproc_get_loaded_rsc_table(struct rproc *rproc,
> > + size_t *size)
> > +{
> > + if (rproc->ops->get_loaded_rsc_table)
> > + return rproc->ops->get_loaded_rsc_table(rproc, size);
> > +
> > + return NULL;
> > +}
> > +
> > static inline
> > bool rproc_u64_fit_in_size_t(u64 val)
> > {
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index 6b0a0ed30a03..51538a7d120d 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -368,7 +368,9 @@ enum rsc_handling_status {
> > * RSC_HANDLED if resource was handled, RSC_IGNORED if not handled and a
> > * negative value on error
> > * @load_rsc_table: load resource table from firmware image
> > - * @find_loaded_rsc_table: find the loaded resouce table
> > + * @find_loaded_rsc_table: find the loaded resource table from firmware image
> > + * @get_loaded_rsc_table: get resource table installed in memory
> > + * by external entity
> > * @load: load firmware to memory, where the remote processor
> > * expects to find it
> > * @sanity_check: sanity check the fw image
> > @@ -390,6 +392,8 @@ struct rproc_ops {
> > int offset, int avail);
> > struct resource_table *(*find_loaded_rsc_table)(
> > struct rproc *rproc, const struct firmware *fw);
> > + struct resource_table *(*get_loaded_rsc_table)(
> > + struct rproc *rproc, size_t *size);
> > int (*load)(struct rproc *rproc, const struct firmware *fw);
> > int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
> > u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> >
_______________________________________________
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:[~2021-02-17 21:24 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 23:46 [PATCH v5 00/19] remoteproc: Add support for detaching a remote processor Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 01/19] dt-bindings: remoteproc: Add bindind to support autonomous processors Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 02/19] remoteproc: Re-check state in rproc_shutdown() Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 03/19] remoteproc: Remove useless check in rproc_del() Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 04/19] remoteproc: Rename function rproc_actuate() Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 05/19] remoteproc: Add new RPROC_ATTACHED state Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 06/19] remoteproc: Properly represent the attached state Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 07/19] remoteproc: Add new get_loaded_rsc_table() to rproc_ops Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-15 13:10 ` Arnaud POULIQUEN
2021-02-15 13:10 ` Arnaud POULIQUEN
2021-02-17 21:22 ` Mathieu Poirier [this message]
2021-02-17 21:22 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 08/19] remoteproc: stm32: Move resource table setup " Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 09/19] remoteproc: stm32: Move memory parsing " Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 10/19] remoteproc: Add new detach() remoteproc operation Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 11/19] remoteproc: Introduce function __rproc_detach() Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 12/19] remoteproc: Introduce function rproc_detach() Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 13/19] remoteproc: Properly deal with the resource table Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-15 12:06 ` Dan Carpenter
2021-02-15 12:06 ` Dan Carpenter
2021-02-15 12:06 ` Dan Carpenter
2021-02-15 12:06 ` Dan Carpenter
2021-02-15 13:19 ` Arnaud POULIQUEN
2021-02-15 13:19 ` Arnaud POULIQUEN
2021-02-11 23:46 ` [PATCH v5 14/19] remoteproc: Add return value to function rproc_shutdown() Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 15/19] remoteproc: Properly deal with a kernel panic when attached Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 16/19] remoteproc: Properly deal with a stop request " Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 17/19] remoteproc: Properly deal with a start " Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 18/19] remoteproc: Properly deal with detach request Mathieu Poirier
2021-02-11 23:46 ` Mathieu Poirier
2021-02-11 23:46 ` [PATCH v5 19/19] remoteproc: Refactor rproc delete and cdev release path Mathieu Poirier
2021-02-11 23: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=20210217212251.GA2800385@xps15 \
--to=mathieu.poirier@linaro.org \
--cc=alexandre.torgue@st.com \
--cc=arnaud.pouliquen@foss.st.com \
--cc=arnaud.pouliquen@st.com \
--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=mcoquelin.stm32@gmail.com \
--cc=ohad@wizery.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 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.