All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>,
	"ohad@wizery.com" <ohad@wizery.com>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>
Cc: "linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 05/17] remoteproc: Add new get_loaded_rsc_table() remoteproc operation
Date: Wed, 27 Jan 2021 09:44:28 +0100	[thread overview]
Message-ID: <47edac31-2f5f-efa9-2699-9fbec7f0d263@st.com> (raw)
In-Reply-To: <20201218173228.2277032-6-mathieu.poirier@linaro.org>

Hi Mathieu,

Come back on you series...

On 12/18/20 6:32 PM, Mathieu Poirier wrote:
> Add an 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>
> ---
>  drivers/remoteproc/remoteproc_core.c     | 6 ++++++
>  drivers/remoteproc/remoteproc_internal.h | 8 ++++++++
>  include/linux/remoteproc.h               | 5 ++++-
>  3 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index d0f6b39b56f9..3d87c910aca7 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1556,6 +1556,12 @@ static int rproc_attach(struct rproc *rproc)
>  		return ret;
>  	}
>  
> +	ret = rproc_get_loaded_rsc_table(rproc);
> +	if (ret) {
> +		dev_err(dev, "can't load resource table: %d\n", ret);
> +		goto disable_iommu;
> +	}
> +

This function is rather ambiguous. Without the example of stm32, it is not
obvious what the platform driver has to do in this ops. And the update of rproc
in the in the core instead of in platform driver seems to me more reliable.

Here is a suggestion considering that ->cached_table is always NULL:


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);

	*size = 0;
	return NULL;
}

then in rproc_attach:

	table_ptr = rproc_get_loaded_rsc_table(rproc, &tab_size);
	if (PTR_ERR(table_ptr) {
		dev_err(dev, "can't load resource table: %d\n", ret);
		goto disable_iommu;
	}
 	rproc->cached_table = NULL;
 	rproc->table_ptr = table_ptr;
 	rproc->table_sz = table_sz;


Thanks,
Arnaud

>  	/* reset max_notifyid */
>  	rproc->max_notifyid = -1;
>  
> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> index c34002888d2c..c48b301d6ad1 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -177,6 +177,14 @@ struct resource_table *rproc_find_loaded_rsc_table(struct rproc *rproc,
>  	return NULL;
>  }
>  
> +static inline int rproc_get_loaded_rsc_table(struct rproc *rproc)
> +{
> +	if (rproc->ops->get_loaded_rsc_table)
> +		return rproc->ops->get_loaded_rsc_table(rproc);
> +
> +	return 0;
> +}
> +
>  static inline
>  bool rproc_u64_fit_in_size_t(u64 val)
>  {
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index 3fa3ba6498e8..571615e77e6f 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
> @@ -389,6 +391,7 @@ struct rproc_ops {
>  			  int offset, int avail);
>  	struct resource_table *(*find_loaded_rsc_table)(
>  				struct rproc *rproc, const struct firmware *fw);
> +	int (*get_loaded_rsc_table)(struct rproc *rproc);
>  	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);
> 

  reply	other threads:[~2021-01-27  8:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-18 17:32 [PATCH v4 00/17] remoteproc: Add support for detaching a rproc Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 01/17] dt-bindings: remoteproc: Add bindind to support autonomous processors Mathieu Poirier
2021-01-20 15:53   ` Rob Herring
2020-12-18 17:32 ` [PATCH v4 02/17] remoteproc: Re-check state in rproc_shutdown() Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 03/17] remoteproc: Remove useless check in rproc_del() Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 04/17] remoteproc: Rename function rproc_actuate() Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 05/17] remoteproc: Add new get_loaded_rsc_table() remoteproc operation Mathieu Poirier
2021-01-27  8:44   ` Arnaud POULIQUEN [this message]
2021-01-29 21:37     ` Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 06/17] remoteproc: stm32: Move resource table setup to rproc_ops Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 07/17] remoteproc: Add new RPROC_ATTACHED state Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 08/17] remoteproc: Properly represent the attached state Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 09/17] remoteproc: Properly deal with a kernel panic when attached Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 10/17] remoteproc: Add new detach() remoteproc operation Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 11/17] remoteproc: Introduce function __rproc_detach() Mathieu Poirier
2021-01-27  8:46   ` Arnaud POULIQUEN
2021-01-29 22:17     ` Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 12/17] remoteproc: Introduce function rproc_detach() Mathieu Poirier
2021-01-27  8:50   ` Arnaud POULIQUEN
2021-01-29 22:31     ` Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 13/17] remoteproc: Add return value to function rproc_shutdown() Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 14/17] remoteproc: Properly deal with a stop request when attached Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 15/17] remoteproc: Properly deal with a start " Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 16/17] remoteproc: Properly deal with detach request Mathieu Poirier
2020-12-18 17:32 ` [PATCH v4 17/17] remoteproc: Refactor rproc delete and cdev release path Mathieu Poirier
2021-01-27  8:56   ` Arnaud POULIQUEN
2021-01-27  9:21 ` [PATCH v4 00/17] remoteproc: Add support for detaching a rproc Arnaud POULIQUEN
2021-02-02  0:49   ` Mathieu Poirier
2021-02-02  8:54     ` Arnaud POULIQUEN
2021-02-02 22:42       ` Mathieu Poirier
2021-02-03  7:58         ` Arnaud POULIQUEN
2021-02-08 23:43           ` 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=47edac31-2f5f-efa9-2699-9fbec7f0d263@st.com \
    --to=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --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.