Re: [PATCH V3 1/7] remoteproc: elf: support platform specific memory hook

On Wed, 9 Dec 2020 at 08:00, Peng Fan [off-list ref] wrote:

quoted

Subject: RE: [PATCH V3 1/7] remoteproc: elf: support platform specific
memory hook

Hi Bjorn,

quoted

Subject: Re: [PATCH V3 1/7] remoteproc: elf: support platform specific
memory hook

On Fri 04 Dec 01:40 CST 2020, Peng Fan (OSS) wrote:

quoted

From: Peng Fan <peng.fan@nxp.com>

To arm64, "dc      zva, dst" is used in memset.
Per ARM DDI 0487A.j, chapter C5.3.8 DC ZVA, Data Cache Zero by VA,

"If the memory region being zeroed is any type of Device memory,
this instruction can give an alignment fault which is prioritized in
the same way as other alignment faults that are determined by the
memory type."

On i.MX platforms, when elf is loaded to onchip TCM area, the region
is ioremapped, so "dc zva, dst" will trigger abort. And ioremap_wc()
on i.MX not able to write correct data to TCM area.

So we need to use io helpers, and extend the elf loader to support
platform specific memory functions.

Acked-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 drivers/remoteproc/remoteproc_elf_loader.c | 20

++++++++++++++++++--

quoted

 include/linux/remoteproc.h                 |  4 ++++
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_elf_loader.c

b/drivers/remoteproc/remoteproc_elf_loader.c
index df68d87752e4..6cb71fe47261 100644

--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c

@@ -129,6 +129,22 @@ u64 rproc_elf_get_boot_addr(struct rproc

*rproc, const struct firmware *fw)  }

EXPORT_SYMBOL(rproc_elf_get_boot_addr);

quoted

+static void rproc_elf_memcpy(struct rproc *rproc, void *dest, const
+void *src, size_t count) {
+ if (!rproc->ops->elf_memcpy)
+         memcpy(dest, src, count);
+
+ rproc->ops->elf_memcpy(rproc, dest, src, count);

Looking at the current set of remoteproc drivers I get a feeling that
we'll end up with a while bunch of functions that all just wraps
memcpy_toio(). And the reason for this is that we are we're "abusing"
the carveout to carry the __iomem pointer without keeping track of it.

And this is not the only time we're supposed to use an io-accessor,
another example is rproc_copy_segment() in rproc_coredump.c

It also means that if a platform driver for some reason where to
support both ioremap and normal carveouts the elf_memcpy op would be

quite quirky.

quoted

So I would prefer if we track the knowledge about void *va being a
__iomem or not in the struct rproc_mem_entry and make rproc_da_to_va()
return this information as well.

Then instead of extending the ops we can make this simply call memcpy
or
memcpy_toio() depending on this.

A draft proposal as below, are you ok with the approach?

Mathieu, do you have any comments?

I will look into this on Monday.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel