From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Frank Li <Frank.Li@nxp.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH v2 1/2] remoteproc: elf_loader: Create new callback for copying segments to remote cpu
Date: Tue, 3 Nov 2026 09:40:22 -0600 [thread overview]
Message-ID: <auoAZs66RA5OYjJo@p14s> (raw)
In-Reply-To: <15d90126debc21c116c9e862a007afa4d81f704c.1793117996.git.u.kleine-koenig@baylibre.com>
Hi Uwe,
On Tue, Oct 27, 2026 at 05:25:20PM +0100, Uwe Kleine-König wrote:
> Some devices have special needs about how an Elf segment is copied to
> the remote cpu's memory space where the default implementation using
> memcpy_toio/memcpy and memset_io/memset isn't suitable. An affected
> mainline driver is imx-dsp-rproc which includes a near-copy of
> rproc_elf_load_segments() just to handle the IRAM only allowing 32 bit
> accesses. On (not-yet-mainline) ADI SC846 the respective memory isn't
> directly accessible at all and DMA must be used to copy the data.
>
> The new callback can be used to implement just the driver specific
> memcpy + memset to increase code reuse.
>
> The patch only appears big because of indentation changes.
>
> Reviewed-by: Peng Fan <peng.fan@nxp.com>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> drivers/remoteproc/remoteproc_elf_loader.c | 64 +++++++++++++---------
> include/linux/remoteproc.h | 4 ++
> 2 files changed, 41 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
> index da3cddbe7d4c..3c749a39e5da 100644
> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> @@ -227,35 +227,45 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> break;
> }
>
> - /* grab the kernel address for this device address */
> - ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
> - if (!ptr) {
> - dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
> - memsz);
> - ret = -EINVAL;
> - break;
> - }
> + if (rproc->ops->memcpy_tova) {
> + ret = rproc->ops->memcpy_tova(rproc, da, elf_data + offset, filesz, memsz);
> + if (ret) {
> + dev_err(dev, "Failed to copy segment %d to device address 0x%llx: %pe\n",
> + i, da, ERR_PTR(ret));
> + break;
> + }
I really like your patch, but I'm wondering why you decided to move
rproc_da_to_va() in ops->memcpy_tova(). Right now it is called in both path,
i.e with and without ops->memcpy_tova(). Wouldn't it be better to
unconditionally leave rproc_da_to_va() in rproc_elf_load_segments()?
Thanks,
Mathieu
> + } else {
> + /* grab the kernel address for this device address */
> + ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
> + if (!ptr) {
> + dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
> + memsz);
> + ret = -EINVAL;
> + break;
> + }
>
> - /* put the segment where the remote processor expects it */
> - if (filesz) {
> - if (is_iomem)
> - memcpy_toio((void __iomem *)ptr, elf_data + offset, filesz);
> - else
> - memcpy(ptr, elf_data + offset, filesz);
> - }
> + /* put the segment where the remote processor expects it */
> + if (filesz) {
> + if (is_iomem)
> + memcpy_toio((void __iomem *)ptr, elf_data + offset, filesz);
> + else
> + memcpy(ptr, elf_data + offset, filesz);
> + }
>
> - /*
> - * Zero out remaining memory for this segment.
> - *
> - * This isn't strictly required since dma_alloc_coherent already
> - * did this for us. albeit harmless, we may consider removing
> - * this.
> - */
> - if (memsz > filesz) {
> - if (is_iomem)
> - memset_io((void __iomem *)(ptr + filesz), 0, memsz - filesz);
> - else
> - memset(ptr + filesz, 0, memsz - filesz);
> + /*
> + * Zero out remaining memory for this segment.
> + *
> + * This isn't strictly required since dma_alloc_coherent already
> + * did this for us. albeit harmless, we may consider removing
> + * this.
> + */
> + if (memsz > filesz) {
> + if (is_iomem)
> + memset_io((void __iomem *)(ptr + filesz),
> + 0, memsz - filesz);
> + else
> + memset(ptr + filesz, 0, memsz - filesz);
> + }
> }
> }
>
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index 00019b1895e6..e750a127cbc4 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -75,6 +75,7 @@ enum rsc_handling_status {
> * @detach: detach from a device, leaving it powered up
> * @kick: kick a virtqueue (virtqueue id given as a parameter)
> * @da_to_va: optional platform hook to perform address translations
> + * @memcpy_tova:optional platform hook to copy data into remote memory range
> * @parse_fw: parse firmware to extract information (e.g. resource table)
> * @handle_rsc: optional platform hook to handle vendor resources. Should return
> * RSC_HANDLED if resource was handled, RSC_IGNORED if not handled
> @@ -99,6 +100,9 @@ struct rproc_ops {
> int (*detach)(struct rproc *rproc);
> void (*kick)(struct rproc *rproc, int vqid);
> void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
> + int (*memcpy_tova)(struct rproc *rproc, u64 da, const void *src,
> + size_t filesz, size_t memsz);
> +
> int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
> int (*handle_rsc)(struct rproc *rproc, u32 rsc_type, void *rsc,
> int offset, int avail);
> --
> 2.47.3
>
next prev parent reply other threads:[~2026-11-03 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 16:25 [PATCH v2 0/2] remoteproc: elf_loader: Make rproc_elf_load_segments() more generic Uwe Kleine-König
2026-10-27 16:25 ` [PATCH v2 1/2] remoteproc: elf_loader: Create new callback for copying segments to remote cpu Uwe Kleine-König
2026-11-03 15:40 ` Mathieu Poirier [this message]
2026-11-03 17:49 ` Uwe Kleine-König
2026-11-04 16:44 ` Mathieu Poirier
2026-10-27 16:25 ` [PATCH v2 2/2] remoteproc: imx_dsp_rproc: Implement .memcpy_tova() Uwe Kleine-König
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=auoAZs66RA5OYjJo@p14s \
--to=mathieu.poirier@linaro.org \
--cc=Frank.Li@nxp.com \
--cc=andersson@kernel.org \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=s.hauer@pengutronix.de \
--cc=u.kleine-koenig@baylibre.com \
--cc=wsa+renesas@sang-engineering.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: 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.