From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: ohad@wizery.com, mathieu.poirier@linaro.org,
o.rempel@pengutronix.de, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, linux-imx@nxp.com,
linux-remoteproc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Peng Fan <peng.fan@nxp.com>,
Richard Zhu <hongxing.zhu@nxp.com>
Subject: Re: [PATCH V3 1/7] remoteproc: elf: support platform specific memory hook
Date: Fri, 4 Dec 2020 18:16:57 -0600 [thread overview]
Message-ID: <X8rRedNHet9gm5lJ@builder.lan> (raw)
In-Reply-To: <20201204074036.23870-2-peng.fan@oss.nxp.com>
On Fri 04 Dec 01:40 CST 2020, Peng Fan (OSS) wrote:
> 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 ++++++++++++++++++--
> 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);
>
> +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.
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.
Regards,
Bjorn
> +}
> +
> +static void rproc_elf_memset(struct rproc *rproc, void *s, int c, size_t count)
> +{
> + if (!rproc->ops->elf_memset)
> + memset(s, c, count);
> +
> + rproc->ops->elf_memset(rproc, s, c, count);
> +}
> +
> /**
> * rproc_elf_load_segments() - load firmware segments to memory
> * @rproc: remote processor which will be booted using these fw segments
> @@ -214,7 +230,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
>
> /* put the segment where the remote processor expects it */
> if (filesz)
> - memcpy(ptr, elf_data + offset, filesz);
> + rproc_elf_memcpy(rproc, ptr, elf_data + offset, filesz);
>
> /*
> * Zero out remaining memory for this segment.
> @@ -224,7 +240,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> * this.
> */
> if (memsz > filesz)
> - memset(ptr + filesz, 0, memsz - filesz);
> + rproc_elf_memset(rproc, ptr + filesz, 0, memsz - filesz);
> }
>
> return ret;
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index e8ac041c64d9..06c52f88a3fd 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -373,6 +373,8 @@ enum rsc_handling_status {
> * expects to find it
> * @sanity_check: sanity check the fw image
> * @get_boot_addr: get boot address to entry point specified in firmware
> + * @elf_memcpy: platform specific elf loader memcpy
> + * @elf_memset: platform specific elf loader memset
> * @panic: optional callback to react to system panic, core will delay
> * panic at least the returned number of milliseconds
> */
> @@ -392,6 +394,8 @@ struct rproc_ops {
> 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);
> + void (*elf_memcpy)(struct rproc *rproc, void *dest, const void *src, size_t count);
> + void (*elf_memset)(struct rproc *rproc, void *s, int c, size_t count);
> unsigned long (*panic)(struct rproc *rproc);
> };
>
> --
> 2.28.0
>
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: ohad@wizery.com, Peng Fan <peng.fan@nxp.com>,
Richard Zhu <hongxing.zhu@nxp.com>,
mathieu.poirier@linaro.org, festevam@gmail.com,
s.hauer@pengutronix.de, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org, o.rempel@pengutronix.de,
linux-imx@nxp.com, kernel@pengutronix.de, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V3 1/7] remoteproc: elf: support platform specific memory hook
Date: Fri, 4 Dec 2020 18:16:57 -0600 [thread overview]
Message-ID: <X8rRedNHet9gm5lJ@builder.lan> (raw)
In-Reply-To: <20201204074036.23870-2-peng.fan@oss.nxp.com>
On Fri 04 Dec 01:40 CST 2020, Peng Fan (OSS) wrote:
> 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 ++++++++++++++++++--
> 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);
>
> +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.
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.
Regards,
Bjorn
> +}
> +
> +static void rproc_elf_memset(struct rproc *rproc, void *s, int c, size_t count)
> +{
> + if (!rproc->ops->elf_memset)
> + memset(s, c, count);
> +
> + rproc->ops->elf_memset(rproc, s, c, count);
> +}
> +
> /**
> * rproc_elf_load_segments() - load firmware segments to memory
> * @rproc: remote processor which will be booted using these fw segments
> @@ -214,7 +230,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
>
> /* put the segment where the remote processor expects it */
> if (filesz)
> - memcpy(ptr, elf_data + offset, filesz);
> + rproc_elf_memcpy(rproc, ptr, elf_data + offset, filesz);
>
> /*
> * Zero out remaining memory for this segment.
> @@ -224,7 +240,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> * this.
> */
> if (memsz > filesz)
> - memset(ptr + filesz, 0, memsz - filesz);
> + rproc_elf_memset(rproc, ptr + filesz, 0, memsz - filesz);
> }
>
> return ret;
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index e8ac041c64d9..06c52f88a3fd 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -373,6 +373,8 @@ enum rsc_handling_status {
> * expects to find it
> * @sanity_check: sanity check the fw image
> * @get_boot_addr: get boot address to entry point specified in firmware
> + * @elf_memcpy: platform specific elf loader memcpy
> + * @elf_memset: platform specific elf loader memset
> * @panic: optional callback to react to system panic, core will delay
> * panic at least the returned number of milliseconds
> */
> @@ -392,6 +394,8 @@ struct rproc_ops {
> 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);
> + void (*elf_memcpy)(struct rproc *rproc, void *dest, const void *src, size_t count);
> + void (*elf_memset)(struct rproc *rproc, void *s, int c, size_t count);
> unsigned long (*panic)(struct rproc *rproc);
> };
>
> --
> 2.28.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-05 0:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 7:40 [PATCH V3 0/7] remoteproc: imx_rproc: support iMX8MQ/M Peng Fan (OSS)
2020-12-04 7:40 ` Peng Fan (OSS)
2020-12-04 7:40 ` [PATCH V3 1/7] remoteproc: elf: support platform specific memory hook Peng Fan (OSS)
2020-12-04 7:40 ` Peng Fan (OSS)
2020-12-05 0:16 ` Bjorn Andersson [this message]
2020-12-05 0:16 ` Bjorn Andersson
2020-12-07 2:07 ` Peng Fan
2020-12-07 2:07 ` Peng Fan
2020-12-09 15:00 ` Peng Fan
2020-12-09 15:00 ` Peng Fan
2020-12-11 21:38 ` Mathieu Poirier
2020-12-11 21:38 ` Mathieu Poirier
2020-12-10 16:54 ` Bjorn Andersson
2020-12-10 16:54 ` Bjorn Andersson
2020-12-14 17:08 ` Mathieu Poirier
2020-12-14 17:08 ` Mathieu Poirier
2020-12-04 7:40 ` [PATCH V3 2/7] remoteproc: imx_rproc: add elf memory hooks Peng Fan (OSS)
2020-12-04 7:40 ` Peng Fan (OSS)
2020-12-04 7:40 ` [PATCH V3 3/7] remoteproc: imx_rproc: correct err message Peng Fan (OSS)
2020-12-04 7:40 ` Peng Fan (OSS)
2020-12-05 0:26 ` Bjorn Andersson
2020-12-05 0:26 ` Bjorn Andersson
2020-12-07 2:08 ` Peng Fan
2020-12-07 2:08 ` Peng Fan
2020-12-04 7:40 ` [PATCH V3 4/7] remoteproc: imx_rproc: use devm_ioremap Peng Fan (OSS)
2020-12-04 7:40 ` Peng Fan (OSS)
2020-12-04 7:40 ` [PATCH V3 5/7] remoteproc: imx_rproc: add i.MX specific parse fw hook Peng Fan (OSS)
2020-12-04 7:40 ` Peng Fan (OSS)
2020-12-04 7:40 ` [PATCH V3 6/7] remoteproc: imx_rproc: support i.MX8MQ/M Peng Fan (OSS)
2020-12-04 7:40 ` Peng Fan (OSS)
2020-12-04 7:40 ` [PATCH V3 7/7] remoteproc: imx_proc: enable virtio/mailbox Peng Fan (OSS)
2020-12-04 7:40 ` Peng Fan (OSS)
2020-12-05 0:44 ` Bjorn Andersson
2020-12-05 0:44 ` Bjorn Andersson
2020-12-07 2:10 ` Peng Fan
2020-12-07 2:10 ` Peng Fan
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=X8rRedNHet9gm5lJ@builder.lan \
--to=bjorn.andersson@linaro.org \
--cc=festevam@gmail.com \
--cc=hongxing.zhu@nxp.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=o.rempel@pengutronix.de \
--cc=ohad@wizery.com \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@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.