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: 5+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®