[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIjqBi3X4hWGsJLP@p14s>
Date: Tue, 29 Jul 2025 09:34:30 -0600
From: Mathieu Poirier <mathieu.poirier@...aro.org>
To: Beleswar Padhi <b-padhi@...com>
Cc: andersson@...nel.org, afd@...com, hnagalla@...com, jm@...com,
jan.kiszka@...mens.com, christophe.jaillet@...adoo.fr,
linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
daniel.baluta@....com, iuliana.prodan@....com,
arnaud.pouliquen@...s.st.com, tanmay.shah@....com
Subject: Re: [RFC PATCH] remoteproc: core: Do not process carveout and devmem
rsc in attach mode
Hi Beleswar,
On Thu, Jul 24, 2025 at 07:01:44PM +0530, Beleswar Padhi wrote:
> When attaching to a remote processor, it is implied that the rproc was
> booted by an external entity. Thus, it's carveout and devmem resources
> would already have been processed by the external entity during boot.
>
> Re-allocating the carveouts in Linux (without proper flags) would zero
> out the memory regions used by the firmware and can lead to undefined
> behaviour. And there is no need to re-map the memory regions for devmem
> resources as well.
>
> Therefore, do not process the carveout and devmem resources in attach
> mode by not appending them to the rproc->carveouts and rproc->mappings
> lists respectively.
>
I think what you are proposing is logical. Arnaud, Daniel, Iuliana and Tanmay -
please test this on your platforms. I will also need another TB from someone at
TI.
Regards,
Mathieu
> Signed-off-by: Beleswar Padhi <b-padhi@...com>
> ---
> Testing:
> 1. Tested IPC with remoteprocs in attach mode in TI platforms.
> [However, TI K3 platforms do not use resource table for carveouts,
> all the memory regions are reserved statically in Device Tree.]
>
> drivers/remoteproc/remoteproc_core.c | 30 ++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 825672100528..ef709a5fa73c 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -640,6 +640,20 @@ static int rproc_handle_devmem(struct rproc *rproc, void *ptr,
> return -EINVAL;
> }
>
> + /*
> + * When attaching to a remote processor, it is implied that the rproc
> + * was booted by an external entity. Thus, it's devmem resources would
> + * already have been mapped by the external entity during boot. There is
> + * no need to re-map the memory regions here.
> + *
> + * Skip adding the devmem rsc to the mapping list and return without
> + * complaining.
> + */
> + if (rproc->state == RPROC_DETACHED) {
> + dev_info(dev, "skipping devmem rsc in attach mode\n");
> + return 0;
> + }
> +
> mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
> if (!mapping)
> return -ENOMEM;
> @@ -839,6 +853,22 @@ static int rproc_handle_carveout(struct rproc *rproc,
> return -EINVAL;
> }
>
> + /*
> + * When attaching to a remote processor, it is implied that the rproc
> + * was booted by an external entity. Thus, it's carveout resources would
> + * already have been allocated by the external entity during boot.
> + * Re-allocating the carveouts here (without proper flags) would zero
> + * out the memory regions used by the firmware and can lead to undefined
> + * behaviour.
> + *
> + * Skip adding the carveouts to the alloc list and return without
> + * complaining.
> + */
> + if (rproc->state == RPROC_DETACHED) {
> + dev_info(dev, "skipping carveout allocation in attach mode\n");
> + return 0;
> + }
> +
> dev_dbg(dev, "carveout rsc: name: %s, da 0x%x, pa 0x%x, len 0x%x, flags 0x%x\n",
> rsc->name, rsc->da, rsc->pa, rsc->len, rsc->flags);
>
> --
> 2.34.1
>
Powered by blists - more mailing lists