* [PATCH V5 0/8] remoteproc: imx_rproc: support iMX8MQ/M
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
V5:
Apply on Linux next
Add V5 subject prefix
Add R-b tag from Bjorn for 1/8, 2/8, 3/8
V4:
According to Bjorn's comments, add is_iomem for da to va usage
1/8, 2/8 is new patch
3/8, follow Bjorn's comments to correct/update the err msg.
6/8, new patch
8/8, use dev_err_probe to simplify code, use queue_work instead schedule_delayed_work
V3:
Since I was quite busy in the past days, V3 is late
Rebased on Linux-next
Add R-b tags
1/7: Add R-b tag of Mathieu, add comments
4/7: Typo fix
5/7: Add R-b tag of Mathieu, drop index Per Mathieu's comments
6/7: Add R-b tag of Mathieu
7/7: Add comment for vqid << 16, drop unneeded timeout settings of mailbox
Use queue_work instead of schedule_delayed_work
free mbox channels when remove
https://lkml.org/lkml/2020/12/4/82
V2:
Rebased on linux-next
Dropped early boot feature to make patchset simple.
Drop rsc-da
https://patchwork.kernel.org/project/linux-remoteproc/cover/20200927064131.24101-1-peng.fan@nxp.com/
V1:
https://patchwork.kernel.org/cover/11682461/
This patchset is to support i.MX8MQ/M coproc.
The early boot feature was dropped to make the patchset small in V2.
Since i.MX specific TCM memory requirement, add elf platform hook.
Several patches have got reviewed by Oleksij and Mathieu in v1.
Peng Fan (8):
remoteproc: introduce is_iomem to rproc_mem_entry
remoteproc: add is_iomem to da_to_va
remoteproc: imx_rproc: correct err message
remoteproc: imx_rproc: use devm_ioremap
remoteproc: imx_rproc: add i.MX specific parse fw hook
remoteproc: imx_rproc: support i.MX8MQ/M
remoteproc: imx_rproc: ignore mapping vdev regions
remoteproc: imx_proc: enable virtio/mailbox
drivers/remoteproc/imx_rproc.c | 259 ++++++++++++++++++++-
drivers/remoteproc/ingenic_rproc.c | 2 +-
drivers/remoteproc/keystone_remoteproc.c | 2 +-
drivers/remoteproc/mtk_scp.c | 6 +-
drivers/remoteproc/omap_remoteproc.c | 2 +-
drivers/remoteproc/pru_rproc.c | 2 +-
drivers/remoteproc/qcom_q6v5_adsp.c | 2 +-
drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
drivers/remoteproc/qcom_q6v5_wcss.c | 2 +-
drivers/remoteproc/qcom_wcnss.c | 2 +-
drivers/remoteproc/remoteproc_core.c | 7 +-
drivers/remoteproc/remoteproc_coredump.c | 8 +-
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
drivers/remoteproc/remoteproc_elf_loader.c | 21 +-
drivers/remoteproc/remoteproc_internal.h | 2 +-
drivers/remoteproc/st_slim_rproc.c | 2 +-
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +-
drivers/remoteproc/wkup_m3_rproc.c | 2 +-
include/linux/remoteproc.h | 4 +-
20 files changed, 298 insertions(+), 35 deletions(-)
--
2.28.0
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH V5 0/8] remoteproc: imx_rproc: support iMX8MQ/M
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, shawnguo, s.hauer, linux-remoteproc, linux-kernel,
patrice.chotard, paul, agross, linux-imx, kernel, matthias.bgg,
festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
V5:
Apply on Linux next
Add V5 subject prefix
Add R-b tag from Bjorn for 1/8, 2/8, 3/8
V4:
According to Bjorn's comments, add is_iomem for da to va usage
1/8, 2/8 is new patch
3/8, follow Bjorn's comments to correct/update the err msg.
6/8, new patch
8/8, use dev_err_probe to simplify code, use queue_work instead schedule_delayed_work
V3:
Since I was quite busy in the past days, V3 is late
Rebased on Linux-next
Add R-b tags
1/7: Add R-b tag of Mathieu, add comments
4/7: Typo fix
5/7: Add R-b tag of Mathieu, drop index Per Mathieu's comments
6/7: Add R-b tag of Mathieu
7/7: Add comment for vqid << 16, drop unneeded timeout settings of mailbox
Use queue_work instead of schedule_delayed_work
free mbox channels when remove
https://lkml.org/lkml/2020/12/4/82
V2:
Rebased on linux-next
Dropped early boot feature to make patchset simple.
Drop rsc-da
https://patchwork.kernel.org/project/linux-remoteproc/cover/20200927064131.24101-1-peng.fan@nxp.com/
V1:
https://patchwork.kernel.org/cover/11682461/
This patchset is to support i.MX8MQ/M coproc.
The early boot feature was dropped to make the patchset small in V2.
Since i.MX specific TCM memory requirement, add elf platform hook.
Several patches have got reviewed by Oleksij and Mathieu in v1.
Peng Fan (8):
remoteproc: introduce is_iomem to rproc_mem_entry
remoteproc: add is_iomem to da_to_va
remoteproc: imx_rproc: correct err message
remoteproc: imx_rproc: use devm_ioremap
remoteproc: imx_rproc: add i.MX specific parse fw hook
remoteproc: imx_rproc: support i.MX8MQ/M
remoteproc: imx_rproc: ignore mapping vdev regions
remoteproc: imx_proc: enable virtio/mailbox
drivers/remoteproc/imx_rproc.c | 259 ++++++++++++++++++++-
drivers/remoteproc/ingenic_rproc.c | 2 +-
drivers/remoteproc/keystone_remoteproc.c | 2 +-
drivers/remoteproc/mtk_scp.c | 6 +-
drivers/remoteproc/omap_remoteproc.c | 2 +-
drivers/remoteproc/pru_rproc.c | 2 +-
drivers/remoteproc/qcom_q6v5_adsp.c | 2 +-
drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
drivers/remoteproc/qcom_q6v5_wcss.c | 2 +-
drivers/remoteproc/qcom_wcnss.c | 2 +-
drivers/remoteproc/remoteproc_core.c | 7 +-
drivers/remoteproc/remoteproc_coredump.c | 8 +-
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
drivers/remoteproc/remoteproc_elf_loader.c | 21 +-
drivers/remoteproc/remoteproc_internal.h | 2 +-
drivers/remoteproc/st_slim_rproc.c | 2 +-
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +-
drivers/remoteproc/wkup_m3_rproc.c | 2 +-
include/linux/remoteproc.h | 4 +-
20 files changed, 298 insertions(+), 35 deletions(-)
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH V5 1/8] remoteproc: introduce is_iomem to rproc_mem_entry
2020-12-29 3:30 ` peng.fan
@ 2020-12-29 3:30 ` peng.fan
-1 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
Introduce is_iomem to indicate this piece memory is iomem or not.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
include/linux/remoteproc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index f28ee75d1005..a5f6d2d9cde2 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -315,6 +315,7 @@ struct rproc;
/**
* struct rproc_mem_entry - memory entry descriptor
* @va: virtual address
+ * @is_iomem: io memory
* @dma: dma address
* @len: length, in bytes
* @da: device address
@@ -329,6 +330,7 @@ struct rproc;
*/
struct rproc_mem_entry {
void *va;
+ bool is_iomem;
dma_addr_t dma;
size_t len;
u32 da;
--
2.28.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 1/8] remoteproc: introduce is_iomem to rproc_mem_entry
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, shawnguo, s.hauer, linux-remoteproc, linux-kernel,
patrice.chotard, paul, agross, linux-imx, kernel, matthias.bgg,
festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
Introduce is_iomem to indicate this piece memory is iomem or not.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
include/linux/remoteproc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index f28ee75d1005..a5f6d2d9cde2 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -315,6 +315,7 @@ struct rproc;
/**
* struct rproc_mem_entry - memory entry descriptor
* @va: virtual address
+ * @is_iomem: io memory
* @dma: dma address
* @len: length, in bytes
* @da: device address
@@ -329,6 +330,7 @@ struct rproc;
*/
struct rproc_mem_entry {
void *va;
+ bool is_iomem;
dma_addr_t dma;
size_t len;
u32 da;
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va
2020-12-29 3:30 ` peng.fan
@ 2020-12-29 3:30 ` peng.fan
-1 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
Introduce an extra parameter is_iomem to da_to_va, then the caller
could take the memory as normal memory or io mapped memory.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 2 +-
drivers/remoteproc/ingenic_rproc.c | 2 +-
drivers/remoteproc/keystone_remoteproc.c | 2 +-
drivers/remoteproc/mtk_scp.c | 6 +++---
drivers/remoteproc/omap_remoteproc.c | 2 +-
drivers/remoteproc/pru_rproc.c | 2 +-
drivers/remoteproc/qcom_q6v5_adsp.c | 2 +-
drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
drivers/remoteproc/qcom_q6v5_wcss.c | 2 +-
drivers/remoteproc/qcom_wcnss.c | 2 +-
drivers/remoteproc/remoteproc_core.c | 7 +++++--
drivers/remoteproc/remoteproc_coredump.c | 8 ++++++--
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
drivers/remoteproc/remoteproc_elf_loader.c | 21 +++++++++++++++------
drivers/remoteproc/remoteproc_internal.h | 2 +-
drivers/remoteproc/st_slim_rproc.c | 2 +-
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +-
drivers/remoteproc/wkup_m3_rproc.c | 2 +-
include/linux/remoteproc.h | 2 +-
20 files changed, 45 insertions(+), 29 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 8957ed271d20..6603e00bb6f4 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -208,7 +208,7 @@ static int imx_rproc_da_to_sys(struct imx_rproc *priv, u64 da,
return -ENOENT;
}
-static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct imx_rproc *priv = rproc->priv;
void *va = NULL;
diff --git a/drivers/remoteproc/ingenic_rproc.c b/drivers/remoteproc/ingenic_rproc.c
index 26e19e6143b7..bb5049295576 100644
--- a/drivers/remoteproc/ingenic_rproc.c
+++ b/drivers/remoteproc/ingenic_rproc.c
@@ -116,7 +116,7 @@ static void ingenic_rproc_kick(struct rproc *rproc, int vqid)
writel(vqid, vpu->aux_base + REG_CORE_MSG);
}
-static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct vpu *vpu = rproc->priv;
void __iomem *va = NULL;
diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
index cd266163a65f..54781f553f4e 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -246,7 +246,7 @@ static void keystone_rproc_kick(struct rproc *rproc, int vqid)
* can be used either by the remoteproc core for loading (when using kernel
* remoteproc loader), or by any rpmsg bus drivers.
*/
-static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct keystone_rproc *ksproc = rproc->priv;
void __iomem *va = NULL;
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index e0c235690361..535175f013e4 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -270,7 +270,7 @@ static int scp_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
}
/* grab the kernel address for this device address */
- ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz);
+ ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz, NULL);
if (!ptr) {
dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
ret = -EINVAL;
@@ -458,7 +458,7 @@ static int scp_start(struct rproc *rproc)
return ret;
}
-static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
int offset;
@@ -587,7 +587,7 @@ void *scp_mapping_dm_addr(struct mtk_scp *scp, u32 mem_addr)
{
void *ptr;
- ptr = scp_da_to_va(scp->rproc, mem_addr, 0);
+ ptr = scp_da_to_va(scp->rproc, mem_addr, 0, NULL);
if (!ptr)
return ERR_PTR(-EINVAL);
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index d94b7391bf9d..43531caa1959 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -728,7 +728,7 @@ static int omap_rproc_stop(struct rproc *rproc)
* Return: translated virtual address in kernel memory space on success,
* or NULL on failure.
*/
-static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct omap_rproc *oproc = rproc->priv;
int i;
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 2667919d76b3..2dcaa274e266 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -465,7 +465,7 @@ static void *pru_i_da_to_va(struct pru_rproc *pru, u32 da, size_t len)
* core for any PRU client drivers. The PRU Instruction RAM access is restricted
* only to the PRU loader code.
*/
-static void *pru_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *pru_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct pru_rproc *pru = rproc->priv;
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c
index e02450225e4a..8b0d8bbacd2e 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -281,7 +281,7 @@ static int adsp_stop(struct rproc *rproc)
return ret;
}
-static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
int offset;
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index ee586226e438..333a1e389fcd 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -242,7 +242,7 @@ static int adsp_stop(struct rproc *rproc)
return ret;
}
-static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
int offset;
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c b/drivers/remoteproc/qcom_q6v5_wcss.c
index 78ebe1168b33..704cd63c9af4 100644
--- a/drivers/remoteproc/qcom_q6v5_wcss.c
+++ b/drivers/remoteproc/qcom_q6v5_wcss.c
@@ -410,7 +410,7 @@ static int q6v5_wcss_stop(struct rproc *rproc)
return 0;
}
-static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct q6v5_wcss *wcss = rproc->priv;
int offset;
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index f95854255c70..1bf60dc84f69 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -320,7 +320,7 @@ static int wcnss_stop(struct rproc *rproc)
return ret;
}
-static void *wcnss_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *wcnss_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct qcom_wcnss *wcnss = (struct qcom_wcnss *)rproc->priv;
int offset;
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 2394eef383e3..9bec422ccce3 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -189,13 +189,13 @@ EXPORT_SYMBOL(rproc_va_to_pa);
* here the output of the DMA API for the carveouts, which should be more
* correct.
*/
-void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct rproc_mem_entry *carveout;
void *ptr = NULL;
if (rproc->ops->da_to_va) {
- ptr = rproc->ops->da_to_va(rproc, da, len);
+ ptr = rproc->ops->da_to_va(rproc, da, len, is_iomem);
if (ptr)
goto out;
}
@@ -217,6 +217,9 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
ptr = carveout->va + offset;
+ if (is_iomem)
+ *is_iomem = carveout->is_iomem;
+
break;
}
diff --git a/drivers/remoteproc/remoteproc_coredump.c b/drivers/remoteproc/remoteproc_coredump.c
index 81ec154a6a5e..aee657cc08c6 100644
--- a/drivers/remoteproc/remoteproc_coredump.c
+++ b/drivers/remoteproc/remoteproc_coredump.c
@@ -153,18 +153,22 @@ static void rproc_copy_segment(struct rproc *rproc, void *dest,
size_t offset, size_t size)
{
void *ptr;
+ bool is_iomem;
if (segment->dump) {
segment->dump(rproc, segment, dest, offset, size);
} else {
- ptr = rproc_da_to_va(rproc, segment->da + offset, size);
+ ptr = rproc_da_to_va(rproc, segment->da + offset, size, &is_iomem);
if (!ptr) {
dev_err(&rproc->dev,
"invalid copy request for segment %pad with offset %zu and size %zu)\n",
&segment->da, offset, size);
memset(dest, 0xff, size);
} else {
- memcpy(dest, ptr, size);
+ if (is_iomem)
+ memcpy_fromio(dest, ptr, size);
+ else
+ memcpy(dest, ptr, size);
}
}
}
diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index 7e5845376e9f..b5a1e3b697d9 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -132,7 +132,7 @@ static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
char buf[100];
int len;
- va = rproc_da_to_va(data->rproc, trace->da, trace->len);
+ va = rproc_da_to_va(data->rproc, trace->da, trace->len, NULL);
if (!va) {
len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
index df68d87752e4..c02d4fec93a9 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -175,6 +175,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
u64 offset = elf_phdr_get_p_offset(class, phdr);
u32 type = elf_phdr_get_p_type(class, phdr);
void *ptr;
+ bool is_iomem;
if (type != PT_LOAD)
continue;
@@ -204,7 +205,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
}
/* grab the kernel address for this device address */
- ptr = rproc_da_to_va(rproc, da, memsz);
+ 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);
@@ -213,8 +214,12 @@ 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);
+ if (filesz) {
+ if (is_iomem)
+ memcpy_fromio(ptr, elf_data + offset, filesz);
+ else
+ memcpy(ptr, elf_data + offset, filesz);
+ }
/*
* Zero out remaining memory for this segment.
@@ -223,8 +228,12 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
* did this for us. albeit harmless, we may consider removing
* this.
*/
- if (memsz > filesz)
- memset(ptr + filesz, 0, memsz - filesz);
+ if (memsz > filesz) {
+ if (is_iomem)
+ memset_io(ptr + filesz, 0, memsz - filesz);
+ else
+ memset(ptr + filesz, 0, memsz - filesz);
+ }
}
return ret;
@@ -377,6 +386,6 @@ struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
return NULL;
}
- return rproc_da_to_va(rproc, sh_addr, sh_size);
+ return rproc_da_to_va(rproc, sh_addr, sh_size, NULL);
}
EXPORT_SYMBOL(rproc_elf_find_loaded_rsc_table);
diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index c34002888d2c..9ea37aa687d2 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -84,7 +84,7 @@ static inline void rproc_char_device_remove(struct rproc *rproc)
void rproc_free_vring(struct rproc_vring *rvring);
int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
-void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len);
+void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
phys_addr_t rproc_va_to_pa(void *cpu_addr);
int rproc_trigger_recovery(struct rproc *rproc);
diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
index 09bcb4d8b9e0..22096adc1ad3 100644
--- a/drivers/remoteproc/st_slim_rproc.c
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -174,7 +174,7 @@ static int slim_rproc_stop(struct rproc *rproc)
return 0;
}
-static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct st_slim_rproc *slim_rproc = rproc->priv;
void *va = NULL;
diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index 863c0214e0a8..fd4eb67a6681 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -354,7 +354,7 @@ static int k3_dsp_rproc_stop(struct rproc *rproc)
* can be used either by the remoteproc core for loading (when using kernel
* remoteproc loader), or by any rpmsg bus drivers.
*/
-static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct k3_dsp_rproc *kproc = rproc->priv;
void __iomem *va = NULL;
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 62b5a4c29456..5cf8d030a1f0 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -590,7 +590,7 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
* present in a DSP or IPU device). The translated addresses can be used
* either by the remoteproc core for loading, or by any rpmsg bus drivers.
*/
-static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct k3_r5_rproc *kproc = rproc->priv;
struct k3_r5_core *core = kproc->core;
diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
index 92d387dfc03b..484f7605823e 100644
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -89,7 +89,7 @@ static int wkup_m3_rproc_stop(struct rproc *rproc)
return error;
}
-static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct wkup_m3_rproc *wkupm3 = rproc->priv;
void *va = NULL;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index a5f6d2d9cde2..1b7d56c7a453 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -386,7 +386,7 @@ struct rproc_ops {
int (*stop)(struct rproc *rproc);
int (*attach)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
- void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len);
+ void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
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.28.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, shawnguo, s.hauer, linux-remoteproc, linux-kernel,
patrice.chotard, paul, agross, linux-imx, kernel, matthias.bgg,
festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
Introduce an extra parameter is_iomem to da_to_va, then the caller
could take the memory as normal memory or io mapped memory.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 2 +-
drivers/remoteproc/ingenic_rproc.c | 2 +-
drivers/remoteproc/keystone_remoteproc.c | 2 +-
drivers/remoteproc/mtk_scp.c | 6 +++---
drivers/remoteproc/omap_remoteproc.c | 2 +-
drivers/remoteproc/pru_rproc.c | 2 +-
drivers/remoteproc/qcom_q6v5_adsp.c | 2 +-
drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
drivers/remoteproc/qcom_q6v5_wcss.c | 2 +-
drivers/remoteproc/qcom_wcnss.c | 2 +-
drivers/remoteproc/remoteproc_core.c | 7 +++++--
drivers/remoteproc/remoteproc_coredump.c | 8 ++++++--
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
drivers/remoteproc/remoteproc_elf_loader.c | 21 +++++++++++++++------
drivers/remoteproc/remoteproc_internal.h | 2 +-
drivers/remoteproc/st_slim_rproc.c | 2 +-
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +-
drivers/remoteproc/wkup_m3_rproc.c | 2 +-
include/linux/remoteproc.h | 2 +-
20 files changed, 45 insertions(+), 29 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 8957ed271d20..6603e00bb6f4 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -208,7 +208,7 @@ static int imx_rproc_da_to_sys(struct imx_rproc *priv, u64 da,
return -ENOENT;
}
-static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct imx_rproc *priv = rproc->priv;
void *va = NULL;
diff --git a/drivers/remoteproc/ingenic_rproc.c b/drivers/remoteproc/ingenic_rproc.c
index 26e19e6143b7..bb5049295576 100644
--- a/drivers/remoteproc/ingenic_rproc.c
+++ b/drivers/remoteproc/ingenic_rproc.c
@@ -116,7 +116,7 @@ static void ingenic_rproc_kick(struct rproc *rproc, int vqid)
writel(vqid, vpu->aux_base + REG_CORE_MSG);
}
-static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct vpu *vpu = rproc->priv;
void __iomem *va = NULL;
diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
index cd266163a65f..54781f553f4e 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -246,7 +246,7 @@ static void keystone_rproc_kick(struct rproc *rproc, int vqid)
* can be used either by the remoteproc core for loading (when using kernel
* remoteproc loader), or by any rpmsg bus drivers.
*/
-static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct keystone_rproc *ksproc = rproc->priv;
void __iomem *va = NULL;
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index e0c235690361..535175f013e4 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -270,7 +270,7 @@ static int scp_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
}
/* grab the kernel address for this device address */
- ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz);
+ ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz, NULL);
if (!ptr) {
dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
ret = -EINVAL;
@@ -458,7 +458,7 @@ static int scp_start(struct rproc *rproc)
return ret;
}
-static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
int offset;
@@ -587,7 +587,7 @@ void *scp_mapping_dm_addr(struct mtk_scp *scp, u32 mem_addr)
{
void *ptr;
- ptr = scp_da_to_va(scp->rproc, mem_addr, 0);
+ ptr = scp_da_to_va(scp->rproc, mem_addr, 0, NULL);
if (!ptr)
return ERR_PTR(-EINVAL);
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index d94b7391bf9d..43531caa1959 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -728,7 +728,7 @@ static int omap_rproc_stop(struct rproc *rproc)
* Return: translated virtual address in kernel memory space on success,
* or NULL on failure.
*/
-static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct omap_rproc *oproc = rproc->priv;
int i;
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 2667919d76b3..2dcaa274e266 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -465,7 +465,7 @@ static void *pru_i_da_to_va(struct pru_rproc *pru, u32 da, size_t len)
* core for any PRU client drivers. The PRU Instruction RAM access is restricted
* only to the PRU loader code.
*/
-static void *pru_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *pru_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct pru_rproc *pru = rproc->priv;
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c
index e02450225e4a..8b0d8bbacd2e 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -281,7 +281,7 @@ static int adsp_stop(struct rproc *rproc)
return ret;
}
-static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
int offset;
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index ee586226e438..333a1e389fcd 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -242,7 +242,7 @@ static int adsp_stop(struct rproc *rproc)
return ret;
}
-static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
int offset;
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c b/drivers/remoteproc/qcom_q6v5_wcss.c
index 78ebe1168b33..704cd63c9af4 100644
--- a/drivers/remoteproc/qcom_q6v5_wcss.c
+++ b/drivers/remoteproc/qcom_q6v5_wcss.c
@@ -410,7 +410,7 @@ static int q6v5_wcss_stop(struct rproc *rproc)
return 0;
}
-static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct q6v5_wcss *wcss = rproc->priv;
int offset;
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index f95854255c70..1bf60dc84f69 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -320,7 +320,7 @@ static int wcnss_stop(struct rproc *rproc)
return ret;
}
-static void *wcnss_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *wcnss_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct qcom_wcnss *wcnss = (struct qcom_wcnss *)rproc->priv;
int offset;
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 2394eef383e3..9bec422ccce3 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -189,13 +189,13 @@ EXPORT_SYMBOL(rproc_va_to_pa);
* here the output of the DMA API for the carveouts, which should be more
* correct.
*/
-void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct rproc_mem_entry *carveout;
void *ptr = NULL;
if (rproc->ops->da_to_va) {
- ptr = rproc->ops->da_to_va(rproc, da, len);
+ ptr = rproc->ops->da_to_va(rproc, da, len, is_iomem);
if (ptr)
goto out;
}
@@ -217,6 +217,9 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
ptr = carveout->va + offset;
+ if (is_iomem)
+ *is_iomem = carveout->is_iomem;
+
break;
}
diff --git a/drivers/remoteproc/remoteproc_coredump.c b/drivers/remoteproc/remoteproc_coredump.c
index 81ec154a6a5e..aee657cc08c6 100644
--- a/drivers/remoteproc/remoteproc_coredump.c
+++ b/drivers/remoteproc/remoteproc_coredump.c
@@ -153,18 +153,22 @@ static void rproc_copy_segment(struct rproc *rproc, void *dest,
size_t offset, size_t size)
{
void *ptr;
+ bool is_iomem;
if (segment->dump) {
segment->dump(rproc, segment, dest, offset, size);
} else {
- ptr = rproc_da_to_va(rproc, segment->da + offset, size);
+ ptr = rproc_da_to_va(rproc, segment->da + offset, size, &is_iomem);
if (!ptr) {
dev_err(&rproc->dev,
"invalid copy request for segment %pad with offset %zu and size %zu)\n",
&segment->da, offset, size);
memset(dest, 0xff, size);
} else {
- memcpy(dest, ptr, size);
+ if (is_iomem)
+ memcpy_fromio(dest, ptr, size);
+ else
+ memcpy(dest, ptr, size);
}
}
}
diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index 7e5845376e9f..b5a1e3b697d9 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -132,7 +132,7 @@ static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
char buf[100];
int len;
- va = rproc_da_to_va(data->rproc, trace->da, trace->len);
+ va = rproc_da_to_va(data->rproc, trace->da, trace->len, NULL);
if (!va) {
len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
index df68d87752e4..c02d4fec93a9 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -175,6 +175,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
u64 offset = elf_phdr_get_p_offset(class, phdr);
u32 type = elf_phdr_get_p_type(class, phdr);
void *ptr;
+ bool is_iomem;
if (type != PT_LOAD)
continue;
@@ -204,7 +205,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
}
/* grab the kernel address for this device address */
- ptr = rproc_da_to_va(rproc, da, memsz);
+ 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);
@@ -213,8 +214,12 @@ 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);
+ if (filesz) {
+ if (is_iomem)
+ memcpy_fromio(ptr, elf_data + offset, filesz);
+ else
+ memcpy(ptr, elf_data + offset, filesz);
+ }
/*
* Zero out remaining memory for this segment.
@@ -223,8 +228,12 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
* did this for us. albeit harmless, we may consider removing
* this.
*/
- if (memsz > filesz)
- memset(ptr + filesz, 0, memsz - filesz);
+ if (memsz > filesz) {
+ if (is_iomem)
+ memset_io(ptr + filesz, 0, memsz - filesz);
+ else
+ memset(ptr + filesz, 0, memsz - filesz);
+ }
}
return ret;
@@ -377,6 +386,6 @@ struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
return NULL;
}
- return rproc_da_to_va(rproc, sh_addr, sh_size);
+ return rproc_da_to_va(rproc, sh_addr, sh_size, NULL);
}
EXPORT_SYMBOL(rproc_elf_find_loaded_rsc_table);
diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index c34002888d2c..9ea37aa687d2 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -84,7 +84,7 @@ static inline void rproc_char_device_remove(struct rproc *rproc)
void rproc_free_vring(struct rproc_vring *rvring);
int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
-void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len);
+void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
phys_addr_t rproc_va_to_pa(void *cpu_addr);
int rproc_trigger_recovery(struct rproc *rproc);
diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
index 09bcb4d8b9e0..22096adc1ad3 100644
--- a/drivers/remoteproc/st_slim_rproc.c
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -174,7 +174,7 @@ static int slim_rproc_stop(struct rproc *rproc)
return 0;
}
-static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct st_slim_rproc *slim_rproc = rproc->priv;
void *va = NULL;
diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index 863c0214e0a8..fd4eb67a6681 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -354,7 +354,7 @@ static int k3_dsp_rproc_stop(struct rproc *rproc)
* can be used either by the remoteproc core for loading (when using kernel
* remoteproc loader), or by any rpmsg bus drivers.
*/
-static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct k3_dsp_rproc *kproc = rproc->priv;
void __iomem *va = NULL;
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 62b5a4c29456..5cf8d030a1f0 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -590,7 +590,7 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
* present in a DSP or IPU device). The translated addresses can be used
* either by the remoteproc core for loading, or by any rpmsg bus drivers.
*/
-static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct k3_r5_rproc *kproc = rproc->priv;
struct k3_r5_core *core = kproc->core;
diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
index 92d387dfc03b..484f7605823e 100644
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -89,7 +89,7 @@ static int wkup_m3_rproc_stop(struct rproc *rproc)
return error;
}
-static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
{
struct wkup_m3_rproc *wkupm3 = rproc->priv;
void *va = NULL;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index a5f6d2d9cde2..1b7d56c7a453 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -386,7 +386,7 @@ struct rproc_ops {
int (*stop)(struct rproc *rproc);
int (*attach)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
- void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len);
+ void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
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.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 3/8] remoteproc: imx_rproc: correct err message
2020-12-29 3:30 ` peng.fan
@ 2020-12-29 3:30 ` peng.fan
-1 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
It is using devm_ioremap, so not devm_ioremap_resource. Correct
the error message and print out sa/size.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 6603e00bb6f4..2a093cea4997 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -268,7 +268,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
att->sa, att->size);
if (!priv->mem[b].cpu_addr) {
- dev_err(dev, "devm_ioremap_resource failed\n");
+ dev_err(dev, "failed to remap %#x bytes from %#x\n", att->size, att->sa);
return -ENOMEM;
}
priv->mem[b].sys_addr = att->sa;
@@ -298,7 +298,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
if (IS_ERR(priv->mem[b].cpu_addr)) {
- dev_err(dev, "devm_ioremap_resource failed\n");
+ dev_err(dev, "failed to remap %pr\n", &res);
err = PTR_ERR(priv->mem[b].cpu_addr);
return err;
}
--
2.28.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 3/8] remoteproc: imx_rproc: correct err message
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, shawnguo, s.hauer, linux-remoteproc, linux-kernel,
patrice.chotard, paul, agross, linux-imx, kernel, matthias.bgg,
festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
It is using devm_ioremap, so not devm_ioremap_resource. Correct
the error message and print out sa/size.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 6603e00bb6f4..2a093cea4997 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -268,7 +268,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
att->sa, att->size);
if (!priv->mem[b].cpu_addr) {
- dev_err(dev, "devm_ioremap_resource failed\n");
+ dev_err(dev, "failed to remap %#x bytes from %#x\n", att->size, att->sa);
return -ENOMEM;
}
priv->mem[b].sys_addr = att->sa;
@@ -298,7 +298,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
if (IS_ERR(priv->mem[b].cpu_addr)) {
- dev_err(dev, "devm_ioremap_resource failed\n");
+ dev_err(dev, "failed to remap %pr\n", &res);
err = PTR_ERR(priv->mem[b].cpu_addr);
return err;
}
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 4/8] remoteproc: imx_rproc: use devm_ioremap
2020-12-29 3:30 ` peng.fan
@ 2020-12-29 3:30 ` peng.fan
-1 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan, Richard Zhu
From: Peng Fan <peng.fan@nxp.com>
We might need to map an region multiple times, becaue the region might
be shared between remote processors, such i.MX8QM with dual M4 cores.
So use devm_ioremap, not devm_ioremap_resource.
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 2a093cea4997..47fc1d06be6a 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -296,7 +296,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (b >= IMX7D_RPROC_MEM_MAX)
break;
- priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
+ /* Not use resource version, because we might share region */
+ priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev, res.start, resource_size(&res));
if (IS_ERR(priv->mem[b].cpu_addr)) {
dev_err(dev, "failed to remap %pr\n", &res);
err = PTR_ERR(priv->mem[b].cpu_addr);
--
2.28.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 4/8] remoteproc: imx_rproc: use devm_ioremap
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, Richard Zhu, shawnguo, s.hauer, linux-remoteproc,
linux-kernel, patrice.chotard, paul, agross, linux-imx, kernel,
matthias.bgg, festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
We might need to map an region multiple times, becaue the region might
be shared between remote processors, such i.MX8QM with dual M4 cores.
So use devm_ioremap, not devm_ioremap_resource.
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 2a093cea4997..47fc1d06be6a 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -296,7 +296,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (b >= IMX7D_RPROC_MEM_MAX)
break;
- priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
+ /* Not use resource version, because we might share region */
+ priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev, res.start, resource_size(&res));
if (IS_ERR(priv->mem[b].cpu_addr)) {
dev_err(dev, "failed to remap %pr\n", &res);
err = PTR_ERR(priv->mem[b].cpu_addr);
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 5/8] remoteproc: imx_rproc: add i.MX specific parse fw hook
2020-12-29 3:30 ` peng.fan
@ 2020-12-29 3:30 ` peng.fan
-1 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan, Richard Zhu
From: Peng Fan <peng.fan@nxp.com>
The hook is used to parse memory-regions and load resource table
from the address the remote processor published.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/remoteproc/imx_rproc.c | 93 ++++++++++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 47fc1d06be6a..3c0075dc1787 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -10,6 +10,7 @@
#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/of_address.h>
+#include <linux/of_reserved_mem.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
@@ -241,10 +242,102 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *i
return va;
}
+static int imx_rproc_mem_alloc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ struct device *dev = rproc->dev.parent;
+ void *va;
+
+ dev_dbg(dev, "map memory: %p+%zx\n", &mem->dma, mem->len);
+ va = ioremap_wc(mem->dma, mem->len);
+ if (IS_ERR_OR_NULL(va)) {
+ dev_err(dev, "Unable to map memory region: %p+%zx\n",
+ &mem->dma, mem->len);
+ return -ENOMEM;
+ }
+
+ /* Update memory entry va */
+ mem->va = va;
+
+ return 0;
+}
+
+static int imx_rproc_mem_release(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ dev_dbg(rproc->dev.parent, "unmap memory: %pa\n", &mem->dma);
+ iounmap(mem->va);
+
+ return 0;
+}
+
+static int imx_rproc_parse_memory_regions(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+ struct device_node *np = priv->dev->of_node;
+ struct of_phandle_iterator it;
+ struct rproc_mem_entry *mem;
+ struct reserved_mem *rmem;
+ u32 da;
+
+ /* Register associated reserved memory regions */
+ of_phandle_iterator_init(&it, np, "memory-region", NULL, 0);
+ while (of_phandle_iterator_next(&it) == 0) {
+ /*
+ * Ignore the first memory region which will be used vdev buffer.
+ * No need to do extra handlings, rproc_add_virtio_dev will handle it.
+ */
+ if (!strcmp(it.node->name, "vdevbuffer"))
+ continue;
+
+ rmem = of_reserved_mem_lookup(it.node);
+ if (!rmem) {
+ dev_err(priv->dev, "unable to acquire memory-region\n");
+ return -EINVAL;
+ }
+
+ /* No need to translate pa to da, i.MX use same map */
+ da = rmem->base;
+
+ /* Register memory region */
+ mem = rproc_mem_entry_init(priv->dev, NULL, (dma_addr_t)rmem->base, rmem->size, da,
+ imx_rproc_mem_alloc, imx_rproc_mem_release,
+ it.node->name);
+
+ if (mem)
+ rproc_coredump_add_segment(rproc, da, rmem->size);
+ else
+ return -ENOMEM;
+
+ rproc_add_carveout(rproc, mem);
+ }
+
+ return 0;
+}
+
+static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ int ret = imx_rproc_parse_memory_regions(rproc);
+
+ if (ret)
+ return ret;
+
+ ret = rproc_elf_load_rsc_table(rproc, fw);
+ if (ret)
+ dev_info(&rproc->dev, "No resource table in elf\n");
+
+ return 0;
+}
+
static const struct rproc_ops imx_rproc_ops = {
.start = imx_rproc_start,
.stop = imx_rproc_stop,
.da_to_va = imx_rproc_da_to_va,
+ .load = rproc_elf_load_segments,
+ .parse_fw = imx_rproc_parse_fw,
+ .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+ .sanity_check = rproc_elf_sanity_check,
+ .get_boot_addr = rproc_elf_get_boot_addr,
};
static int imx_rproc_addr_init(struct imx_rproc *priv,
--
2.28.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 5/8] remoteproc: imx_rproc: add i.MX specific parse fw hook
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, Richard Zhu, shawnguo, s.hauer, linux-remoteproc,
linux-kernel, patrice.chotard, paul, agross, linux-imx, kernel,
matthias.bgg, festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
The hook is used to parse memory-regions and load resource table
from the address the remote processor published.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/remoteproc/imx_rproc.c | 93 ++++++++++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 47fc1d06be6a..3c0075dc1787 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -10,6 +10,7 @@
#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/of_address.h>
+#include <linux/of_reserved_mem.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
@@ -241,10 +242,102 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *i
return va;
}
+static int imx_rproc_mem_alloc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ struct device *dev = rproc->dev.parent;
+ void *va;
+
+ dev_dbg(dev, "map memory: %p+%zx\n", &mem->dma, mem->len);
+ va = ioremap_wc(mem->dma, mem->len);
+ if (IS_ERR_OR_NULL(va)) {
+ dev_err(dev, "Unable to map memory region: %p+%zx\n",
+ &mem->dma, mem->len);
+ return -ENOMEM;
+ }
+
+ /* Update memory entry va */
+ mem->va = va;
+
+ return 0;
+}
+
+static int imx_rproc_mem_release(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ dev_dbg(rproc->dev.parent, "unmap memory: %pa\n", &mem->dma);
+ iounmap(mem->va);
+
+ return 0;
+}
+
+static int imx_rproc_parse_memory_regions(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+ struct device_node *np = priv->dev->of_node;
+ struct of_phandle_iterator it;
+ struct rproc_mem_entry *mem;
+ struct reserved_mem *rmem;
+ u32 da;
+
+ /* Register associated reserved memory regions */
+ of_phandle_iterator_init(&it, np, "memory-region", NULL, 0);
+ while (of_phandle_iterator_next(&it) == 0) {
+ /*
+ * Ignore the first memory region which will be used vdev buffer.
+ * No need to do extra handlings, rproc_add_virtio_dev will handle it.
+ */
+ if (!strcmp(it.node->name, "vdevbuffer"))
+ continue;
+
+ rmem = of_reserved_mem_lookup(it.node);
+ if (!rmem) {
+ dev_err(priv->dev, "unable to acquire memory-region\n");
+ return -EINVAL;
+ }
+
+ /* No need to translate pa to da, i.MX use same map */
+ da = rmem->base;
+
+ /* Register memory region */
+ mem = rproc_mem_entry_init(priv->dev, NULL, (dma_addr_t)rmem->base, rmem->size, da,
+ imx_rproc_mem_alloc, imx_rproc_mem_release,
+ it.node->name);
+
+ if (mem)
+ rproc_coredump_add_segment(rproc, da, rmem->size);
+ else
+ return -ENOMEM;
+
+ rproc_add_carveout(rproc, mem);
+ }
+
+ return 0;
+}
+
+static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ int ret = imx_rproc_parse_memory_regions(rproc);
+
+ if (ret)
+ return ret;
+
+ ret = rproc_elf_load_rsc_table(rproc, fw);
+ if (ret)
+ dev_info(&rproc->dev, "No resource table in elf\n");
+
+ return 0;
+}
+
static const struct rproc_ops imx_rproc_ops = {
.start = imx_rproc_start,
.stop = imx_rproc_stop,
.da_to_va = imx_rproc_da_to_va,
+ .load = rproc_elf_load_segments,
+ .parse_fw = imx_rproc_parse_fw,
+ .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+ .sanity_check = rproc_elf_sanity_check,
+ .get_boot_addr = rproc_elf_get_boot_addr,
};
static int imx_rproc_addr_init(struct imx_rproc *priv,
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 6/8] remoteproc: imx_rproc: support i.MX8MQ/M
2020-12-29 3:30 ` peng.fan
@ 2020-12-29 3:30 ` peng.fan
-1 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan, Richard Zhu
From: Peng Fan <peng.fan@nxp.com>
Add i.MX8MQ dev/sys addr map and configuration data structure
i.MX8MM share i.MX8MQ settings.
Reviewed-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/imx_rproc.c | 39 ++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 3c0075dc1787..f80428afb8a7 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -88,6 +88,34 @@ struct imx_rproc {
struct clk *clk;
};
+static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCML - alias */
+ { 0x00000000, 0x007e0000, 0x00020000, 0 },
+ /* OCRAM_S */
+ { 0x00180000, 0x00180000, 0x00008000, 0 },
+ /* OCRAM */
+ { 0x00900000, 0x00900000, 0x00020000, 0 },
+ /* OCRAM */
+ { 0x00920000, 0x00920000, 0x00020000, 0 },
+ /* QSPI Code - alias */
+ { 0x08000000, 0x08000000, 0x08000000, 0 },
+ /* DDR (Code) - alias */
+ { 0x10000000, 0x80000000, 0x0FFE0000, 0 },
+ /* TCML */
+ { 0x1FFE0000, 0x007E0000, 0x00020000, ATT_OWN },
+ /* TCMU */
+ { 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
+ /* OCRAM_S */
+ { 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
+ /* OCRAM */
+ { 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
+ /* OCRAM */
+ { 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
+ /* DDR (Data) */
+ { 0x40000000, 0x40000000, 0x80000000, 0 },
+};
+
static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
/* dev addr , sys addr , size , flags */
/* OCRAM_S (M4 Boot code) - alias */
@@ -138,6 +166,15 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = {
{ 0x80000000, 0x80000000, 0x60000000, 0 },
};
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
+ .src_reg = IMX7D_SRC_SCR,
+ .src_mask = IMX7D_M4_RST_MASK,
+ .src_start = IMX7D_M4_START,
+ .src_stop = IMX7D_M4_STOP,
+ .att = imx_rproc_att_imx8mq,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx8mq),
+};
+
static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
.src_reg = IMX7D_SRC_SCR,
.src_mask = IMX7D_M4_RST_MASK,
@@ -496,6 +533,8 @@ static int imx_rproc_remove(struct platform_device *pdev)
static const struct of_device_id imx_rproc_of_match[] = {
{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
+ { .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
+ { .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
{},
};
MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
--
2.28.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 6/8] remoteproc: imx_rproc: support i.MX8MQ/M
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, Richard Zhu, shawnguo, s.hauer, linux-remoteproc,
linux-kernel, patrice.chotard, paul, agross, linux-imx, kernel,
matthias.bgg, festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
Add i.MX8MQ dev/sys addr map and configuration data structure
i.MX8MM share i.MX8MQ settings.
Reviewed-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/imx_rproc.c | 39 ++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 3c0075dc1787..f80428afb8a7 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -88,6 +88,34 @@ struct imx_rproc {
struct clk *clk;
};
+static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCML - alias */
+ { 0x00000000, 0x007e0000, 0x00020000, 0 },
+ /* OCRAM_S */
+ { 0x00180000, 0x00180000, 0x00008000, 0 },
+ /* OCRAM */
+ { 0x00900000, 0x00900000, 0x00020000, 0 },
+ /* OCRAM */
+ { 0x00920000, 0x00920000, 0x00020000, 0 },
+ /* QSPI Code - alias */
+ { 0x08000000, 0x08000000, 0x08000000, 0 },
+ /* DDR (Code) - alias */
+ { 0x10000000, 0x80000000, 0x0FFE0000, 0 },
+ /* TCML */
+ { 0x1FFE0000, 0x007E0000, 0x00020000, ATT_OWN },
+ /* TCMU */
+ { 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
+ /* OCRAM_S */
+ { 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
+ /* OCRAM */
+ { 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
+ /* OCRAM */
+ { 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
+ /* DDR (Data) */
+ { 0x40000000, 0x40000000, 0x80000000, 0 },
+};
+
static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
/* dev addr , sys addr , size , flags */
/* OCRAM_S (M4 Boot code) - alias */
@@ -138,6 +166,15 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = {
{ 0x80000000, 0x80000000, 0x60000000, 0 },
};
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
+ .src_reg = IMX7D_SRC_SCR,
+ .src_mask = IMX7D_M4_RST_MASK,
+ .src_start = IMX7D_M4_START,
+ .src_stop = IMX7D_M4_STOP,
+ .att = imx_rproc_att_imx8mq,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx8mq),
+};
+
static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
.src_reg = IMX7D_SRC_SCR,
.src_mask = IMX7D_M4_RST_MASK,
@@ -496,6 +533,8 @@ static int imx_rproc_remove(struct platform_device *pdev)
static const struct of_device_id imx_rproc_of_match[] = {
{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
+ { .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
+ { .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
{},
};
MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2020-12-29 3:30 ` peng.fan
@ 2020-12-29 3:30 ` peng.fan
-1 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
They are handled by remoteproc common code, no need to map in imx
rproc driver.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index f80428afb8a7..e62a53ee128e 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
struct resource res;
node = of_parse_phandle(np, "memory-region", a);
+ /* Not map vdev region */
+ if (!strcmp(node->name, "vdev"))
+ continue;
err = of_address_to_resource(node, 0, &res);
if (err) {
dev_err(dev, "unable to resolve memory region\n");
--
2.28.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, shawnguo, s.hauer, linux-remoteproc, linux-kernel,
patrice.chotard, paul, agross, linux-imx, kernel, matthias.bgg,
festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
They are handled by remoteproc common code, no need to map in imx
rproc driver.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index f80428afb8a7..e62a53ee128e 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
struct resource res;
node = of_parse_phandle(np, "memory-region", a);
+ /* Not map vdev region */
+ if (!strcmp(node->name, "vdev"))
+ continue;
err = of_address_to_resource(node, 0, &res);
if (err) {
dev_err(dev, "unable to resolve memory region\n");
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 8/8] remoteproc: imx_proc: enable virtio/mailbox
2020-12-29 3:30 ` peng.fan
@ 2020-12-29 3:30 ` peng.fan
-1 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: shawnguo, s.hauer, kernel, festevam, linux-imx, linux-remoteproc,
linux-arm-kernel, linux-kernel, paul, matthias.bgg, agross,
patrice.chotard, Peng Fan, Richard Zhu
From: Peng Fan <peng.fan@nxp.com>
Use virtio/mailbox to build connection between Remote Proccessors
and Linux. Add work queue to handle incoming messages.
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 115 ++++++++++++++++++++++++++++++++-
1 file changed, 112 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index e62a53ee128e..812b077f1282 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -7,6 +7,7 @@
#include <linux/err.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <linux/mailbox_client.h>
#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/of_address.h>
@@ -15,6 +16,9 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/remoteproc.h>
+#include <linux/workqueue.h>
+
+#include "remoteproc_internal.h"
#define IMX7D_SRC_SCR 0x0C
#define IMX7D_ENABLE_M4 BIT(3)
@@ -86,6 +90,11 @@ struct imx_rproc {
const struct imx_rproc_dcfg *dcfg;
struct imx_rproc_mem mem[IMX7D_RPROC_MEM_MAX];
struct clk *clk;
+ struct mbox_client cl;
+ struct mbox_chan *tx_ch;
+ struct mbox_chan *rx_ch;
+ struct work_struct rproc_work;
+ struct workqueue_struct *workqueue;
};
static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -366,9 +375,33 @@ static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
return 0;
}
+static void imx_rproc_kick(struct rproc *rproc, int vqid)
+{
+ struct imx_rproc *priv = rproc->priv;
+ int err;
+ __u32 mmsg;
+
+ if (!priv->tx_ch) {
+ dev_err(priv->dev, "No initialized mbox tx channel\n");
+ return;
+ }
+
+ /*
+ * Send the index of the triggered virtqueue as the mu payload.
+ * Let remote processor know which virtqueue is used.
+ */
+ mmsg = vqid << 16;
+
+ err = mbox_send_message(priv->tx_ch, (void *)&mmsg);
+ if (err < 0)
+ dev_err(priv->dev, "%s: failed (%d, err:%d)\n",
+ __func__, vqid, err);
+}
+
static const struct rproc_ops imx_rproc_ops = {
.start = imx_rproc_start,
.stop = imx_rproc_stop,
+ .kick = imx_rproc_kick,
.da_to_va = imx_rproc_da_to_va,
.load = rproc_elf_load_segments,
.parse_fw = imx_rproc_parse_fw,
@@ -444,6 +477,65 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
return 0;
}
+static void imx_rproc_vq_work(struct work_struct *work)
+{
+ struct imx_rproc *priv = container_of(work, struct imx_rproc,
+ rproc_work);
+
+ rproc_vq_interrupt(priv->rproc, 0);
+ rproc_vq_interrupt(priv->rproc, 1);
+}
+
+static void imx_rproc_rx_callback(struct mbox_client *cl, void *msg)
+{
+ struct rproc *rproc = dev_get_drvdata(cl->dev);
+ struct imx_rproc *priv = rproc->priv;
+
+ queue_work(priv->workqueue, &priv->rproc_work);
+}
+
+static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+ struct device *dev = priv->dev;
+ struct mbox_client *cl;
+ int ret;
+
+ if (!of_get_property(dev->of_node, "mbox-names", NULL))
+ return 0;
+
+ cl = &priv->cl;
+ cl->dev = dev;
+ cl->tx_block = true;
+ cl->tx_tout = 100;
+ cl->knows_txdone = false;
+ cl->rx_callback = imx_rproc_rx_callback;
+
+ priv->tx_ch = mbox_request_channel_byname(cl, "tx");
+ if (IS_ERR(priv->tx_ch)) {
+ ret = PTR_ERR(priv->tx_ch);
+ return dev_err_probe(cl->dev, PTR_ERR(priv->tx_ch),
+ "failed to request tx mailbox channel: %d\n", ret);
+ }
+
+ priv->rx_ch = mbox_request_channel_byname(cl, "rx");
+ if (IS_ERR(priv->rx_ch)) {
+ mbox_free_channel(priv->tx_ch);
+ return dev_err_probe(cl->dev, PTR_ERR(priv->rx_ch),
+ "failed to request mbox tx chan\n");
+ }
+
+ return 0;
+}
+
+static void imx_rproc_free_mbox(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+
+ mbox_free_channel(priv->tx_ch);
+ mbox_free_channel(priv->rx_ch);
+}
+
static int imx_rproc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -481,18 +573,28 @@ static int imx_rproc_probe(struct platform_device *pdev)
priv->dev = dev;
dev_set_drvdata(dev, rproc);
+ priv->workqueue = create_workqueue(dev_name(dev));
+ if (!priv->workqueue) {
+ dev_err(dev, "cannot create workqueue\n");
+ ret = -ENOMEM;
+ goto err_put_rproc;
+ }
+
+ ret = imx_rproc_xtr_mbox_init(rproc);
+ if (ret)
+ goto err_put_wkq;
ret = imx_rproc_addr_init(priv, pdev);
if (ret) {
dev_err(dev, "failed on imx_rproc_addr_init\n");
- goto err_put_rproc;
+ goto err_put_mbox;
}
priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(dev, "Failed to get clock\n");
ret = PTR_ERR(priv->clk);
- goto err_put_rproc;
+ goto err_put_mbox;
}
/*
@@ -502,9 +604,11 @@ static int imx_rproc_probe(struct platform_device *pdev)
ret = clk_prepare_enable(priv->clk);
if (ret) {
dev_err(&rproc->dev, "Failed to enable clock\n");
- goto err_put_rproc;
+ goto err_put_mbox;
}
+ INIT_WORK(&(priv->rproc_work), imx_rproc_vq_work);
+
ret = rproc_add(rproc);
if (ret) {
dev_err(dev, "rproc_add failed\n");
@@ -515,6 +619,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
err_put_clk:
clk_disable_unprepare(priv->clk);
+err_put_mbox:
+ imx_rproc_free_mbox(rproc);
+err_put_wkq:
+ destroy_workqueue(priv->workqueue);
err_put_rproc:
rproc_free(rproc);
@@ -527,6 +635,7 @@ static int imx_rproc_remove(struct platform_device *pdev)
struct imx_rproc *priv = rproc->priv;
clk_disable_unprepare(priv->clk);
+ imx_rproc_free_mbox(rproc);
rproc_del(rproc);
rproc_free(rproc);
--
2.28.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH V5 8/8] remoteproc: imx_proc: enable virtio/mailbox
@ 2020-12-29 3:30 ` peng.fan
0 siblings, 0 replies; 50+ messages in thread
From: peng.fan @ 2020-12-29 3:30 UTC (permalink / raw)
To: ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: Peng Fan, Richard Zhu, shawnguo, s.hauer, linux-remoteproc,
linux-kernel, patrice.chotard, paul, agross, linux-imx, kernel,
matthias.bgg, festevam, linux-arm-kernel
From: Peng Fan <peng.fan@nxp.com>
Use virtio/mailbox to build connection between Remote Proccessors
and Linux. Add work queue to handle incoming messages.
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 115 ++++++++++++++++++++++++++++++++-
1 file changed, 112 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index e62a53ee128e..812b077f1282 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -7,6 +7,7 @@
#include <linux/err.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <linux/mailbox_client.h>
#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/of_address.h>
@@ -15,6 +16,9 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/remoteproc.h>
+#include <linux/workqueue.h>
+
+#include "remoteproc_internal.h"
#define IMX7D_SRC_SCR 0x0C
#define IMX7D_ENABLE_M4 BIT(3)
@@ -86,6 +90,11 @@ struct imx_rproc {
const struct imx_rproc_dcfg *dcfg;
struct imx_rproc_mem mem[IMX7D_RPROC_MEM_MAX];
struct clk *clk;
+ struct mbox_client cl;
+ struct mbox_chan *tx_ch;
+ struct mbox_chan *rx_ch;
+ struct work_struct rproc_work;
+ struct workqueue_struct *workqueue;
};
static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -366,9 +375,33 @@ static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
return 0;
}
+static void imx_rproc_kick(struct rproc *rproc, int vqid)
+{
+ struct imx_rproc *priv = rproc->priv;
+ int err;
+ __u32 mmsg;
+
+ if (!priv->tx_ch) {
+ dev_err(priv->dev, "No initialized mbox tx channel\n");
+ return;
+ }
+
+ /*
+ * Send the index of the triggered virtqueue as the mu payload.
+ * Let remote processor know which virtqueue is used.
+ */
+ mmsg = vqid << 16;
+
+ err = mbox_send_message(priv->tx_ch, (void *)&mmsg);
+ if (err < 0)
+ dev_err(priv->dev, "%s: failed (%d, err:%d)\n",
+ __func__, vqid, err);
+}
+
static const struct rproc_ops imx_rproc_ops = {
.start = imx_rproc_start,
.stop = imx_rproc_stop,
+ .kick = imx_rproc_kick,
.da_to_va = imx_rproc_da_to_va,
.load = rproc_elf_load_segments,
.parse_fw = imx_rproc_parse_fw,
@@ -444,6 +477,65 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
return 0;
}
+static void imx_rproc_vq_work(struct work_struct *work)
+{
+ struct imx_rproc *priv = container_of(work, struct imx_rproc,
+ rproc_work);
+
+ rproc_vq_interrupt(priv->rproc, 0);
+ rproc_vq_interrupt(priv->rproc, 1);
+}
+
+static void imx_rproc_rx_callback(struct mbox_client *cl, void *msg)
+{
+ struct rproc *rproc = dev_get_drvdata(cl->dev);
+ struct imx_rproc *priv = rproc->priv;
+
+ queue_work(priv->workqueue, &priv->rproc_work);
+}
+
+static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+ struct device *dev = priv->dev;
+ struct mbox_client *cl;
+ int ret;
+
+ if (!of_get_property(dev->of_node, "mbox-names", NULL))
+ return 0;
+
+ cl = &priv->cl;
+ cl->dev = dev;
+ cl->tx_block = true;
+ cl->tx_tout = 100;
+ cl->knows_txdone = false;
+ cl->rx_callback = imx_rproc_rx_callback;
+
+ priv->tx_ch = mbox_request_channel_byname(cl, "tx");
+ if (IS_ERR(priv->tx_ch)) {
+ ret = PTR_ERR(priv->tx_ch);
+ return dev_err_probe(cl->dev, PTR_ERR(priv->tx_ch),
+ "failed to request tx mailbox channel: %d\n", ret);
+ }
+
+ priv->rx_ch = mbox_request_channel_byname(cl, "rx");
+ if (IS_ERR(priv->rx_ch)) {
+ mbox_free_channel(priv->tx_ch);
+ return dev_err_probe(cl->dev, PTR_ERR(priv->rx_ch),
+ "failed to request mbox tx chan\n");
+ }
+
+ return 0;
+}
+
+static void imx_rproc_free_mbox(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+
+ mbox_free_channel(priv->tx_ch);
+ mbox_free_channel(priv->rx_ch);
+}
+
static int imx_rproc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -481,18 +573,28 @@ static int imx_rproc_probe(struct platform_device *pdev)
priv->dev = dev;
dev_set_drvdata(dev, rproc);
+ priv->workqueue = create_workqueue(dev_name(dev));
+ if (!priv->workqueue) {
+ dev_err(dev, "cannot create workqueue\n");
+ ret = -ENOMEM;
+ goto err_put_rproc;
+ }
+
+ ret = imx_rproc_xtr_mbox_init(rproc);
+ if (ret)
+ goto err_put_wkq;
ret = imx_rproc_addr_init(priv, pdev);
if (ret) {
dev_err(dev, "failed on imx_rproc_addr_init\n");
- goto err_put_rproc;
+ goto err_put_mbox;
}
priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(dev, "Failed to get clock\n");
ret = PTR_ERR(priv->clk);
- goto err_put_rproc;
+ goto err_put_mbox;
}
/*
@@ -502,9 +604,11 @@ static int imx_rproc_probe(struct platform_device *pdev)
ret = clk_prepare_enable(priv->clk);
if (ret) {
dev_err(&rproc->dev, "Failed to enable clock\n");
- goto err_put_rproc;
+ goto err_put_mbox;
}
+ INIT_WORK(&(priv->rproc_work), imx_rproc_vq_work);
+
ret = rproc_add(rproc);
if (ret) {
dev_err(dev, "rproc_add failed\n");
@@ -515,6 +619,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
err_put_clk:
clk_disable_unprepare(priv->clk);
+err_put_mbox:
+ imx_rproc_free_mbox(rproc);
+err_put_wkq:
+ destroy_workqueue(priv->workqueue);
err_put_rproc:
rproc_free(rproc);
@@ -527,6 +635,7 @@ static int imx_rproc_remove(struct platform_device *pdev)
struct imx_rproc *priv = rproc->priv;
clk_disable_unprepare(priv->clk);
+ imx_rproc_free_mbox(rproc);
rproc_del(rproc);
rproc_free(rproc);
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va
2020-12-29 3:30 ` peng.fan
@ 2020-12-30 15:14 ` kernel test robot
-1 siblings, 0 replies; 50+ messages in thread
From: kernel test robot @ 2020-12-30 15:14 UTC (permalink / raw)
To: peng.fan, ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: kbuild-all, shawnguo, s.hauer, kernel, festevam, linux-imx,
linux-remoteproc
[-- Attachment #1: Type: text/plain, Size: 7231 bytes --]
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.11-rc1 next-20201223]
[cannot apply to soc/for-next xlnx/master remoteproc/for-next rpmsg/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dea8dcf2a9fa8cc540136a6cd885c3beece16ec3
config: powerpc64-randconfig-s032-20201230 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
# https://github.com/0day-ci/linux/commit/f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
git checkout f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
"sparse warnings: (new ones prefixed by >>)"
>> drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem *s @@ got unsigned char const [usertype] * @@
drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: expected void const volatile [noderef] __iomem *s
drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: got unsigned char const [usertype] *
>> drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *a @@ got void * @@
drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: expected void volatile [noderef] __iomem *a
drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: got void *
--
>> drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem *s @@ got void *[assigned] ptr @@
drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: expected void const volatile [noderef] __iomem *s
drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: got void *[assigned] ptr
vim +219 drivers/remoteproc/remoteproc_elf_loader.c
131
132 /**
133 * rproc_elf_load_segments() - load firmware segments to memory
134 * @rproc: remote processor which will be booted using these fw segments
135 * @fw: the ELF firmware image
136 *
137 * This function loads the firmware segments to memory, where the remote
138 * processor expects them.
139 *
140 * Some remote processors will expect their code and data to be placed
141 * in specific device addresses, and can't have them dynamically assigned.
142 *
143 * We currently support only those kind of remote processors, and expect
144 * the program header's paddr member to contain those addresses. We then go
145 * through the physically contiguous "carveout" memory regions which we
146 * allocated (and mapped) earlier on behalf of the remote processor,
147 * and "translate" device address to kernel addresses, so we can copy the
148 * segments where they are expected.
149 *
150 * Currently we only support remote processors that required carveout
151 * allocations and got them mapped onto their iommus. Some processors
152 * might be different: they might not have iommus, and would prefer to
153 * directly allocate memory for every segment/resource. This is not yet
154 * supported, though.
155 */
156 int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
157 {
158 struct device *dev = &rproc->dev;
159 const void *ehdr, *phdr;
160 int i, ret = 0;
161 u16 phnum;
162 const u8 *elf_data = fw->data;
163 u8 class = fw_elf_get_class(fw);
164 u32 elf_phdr_get_size = elf_size_of_phdr(class);
165
166 ehdr = elf_data;
167 phnum = elf_hdr_get_e_phnum(class, ehdr);
168 phdr = elf_data + elf_hdr_get_e_phoff(class, ehdr);
169
170 /* go through the available ELF segments */
171 for (i = 0; i < phnum; i++, phdr += elf_phdr_get_size) {
172 u64 da = elf_phdr_get_p_paddr(class, phdr);
173 u64 memsz = elf_phdr_get_p_memsz(class, phdr);
174 u64 filesz = elf_phdr_get_p_filesz(class, phdr);
175 u64 offset = elf_phdr_get_p_offset(class, phdr);
176 u32 type = elf_phdr_get_p_type(class, phdr);
177 void *ptr;
178 bool is_iomem;
179
180 if (type != PT_LOAD)
181 continue;
182
183 dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
184 type, da, memsz, filesz);
185
186 if (filesz > memsz) {
187 dev_err(dev, "bad phdr filesz 0x%llx memsz 0x%llx\n",
188 filesz, memsz);
189 ret = -EINVAL;
190 break;
191 }
192
193 if (offset + filesz > fw->size) {
194 dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
195 offset + filesz, fw->size);
196 ret = -EINVAL;
197 break;
198 }
199
200 if (!rproc_u64_fit_in_size_t(memsz)) {
201 dev_err(dev, "size (%llx) does not fit in size_t type\n",
202 memsz);
203 ret = -EOVERFLOW;
204 break;
205 }
206
207 /* grab the kernel address for this device address */
208 ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
209 if (!ptr) {
210 dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
211 memsz);
212 ret = -EINVAL;
213 break;
214 }
215
216 /* put the segment where the remote processor expects it */
217 if (filesz) {
218 if (is_iomem)
> 219 memcpy_fromio(ptr, elf_data + offset, filesz);
220 else
221 memcpy(ptr, elf_data + offset, filesz);
222 }
223
224 /*
225 * Zero out remaining memory for this segment.
226 *
227 * This isn't strictly required since dma_alloc_coherent already
228 * did this for us. albeit harmless, we may consider removing
229 * this.
230 */
231 if (memsz > filesz) {
232 if (is_iomem)
> 233 memset_io(ptr + filesz, 0, memsz - filesz);
234 else
235 memset(ptr + filesz, 0, memsz - filesz);
236 }
237 }
238
239 return ret;
240 }
241 EXPORT_SYMBOL(rproc_elf_load_segments);
242
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 36269 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va
@ 2020-12-30 15:14 ` kernel test robot
0 siblings, 0 replies; 50+ messages in thread
From: kernel test robot @ 2020-12-30 15:14 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 7394 bytes --]
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.11-rc1 next-20201223]
[cannot apply to soc/for-next xlnx/master remoteproc/for-next rpmsg/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dea8dcf2a9fa8cc540136a6cd885c3beece16ec3
config: powerpc64-randconfig-s032-20201230 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
# https://github.com/0day-ci/linux/commit/f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
git checkout f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
"sparse warnings: (new ones prefixed by >>)"
>> drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem *s @@ got unsigned char const [usertype] * @@
drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: expected void const volatile [noderef] __iomem *s
drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: got unsigned char const [usertype] *
>> drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *a @@ got void * @@
drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: expected void volatile [noderef] __iomem *a
drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: got void *
--
>> drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem *s @@ got void *[assigned] ptr @@
drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: expected void const volatile [noderef] __iomem *s
drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: got void *[assigned] ptr
vim +219 drivers/remoteproc/remoteproc_elf_loader.c
131
132 /**
133 * rproc_elf_load_segments() - load firmware segments to memory
134 * @rproc: remote processor which will be booted using these fw segments
135 * @fw: the ELF firmware image
136 *
137 * This function loads the firmware segments to memory, where the remote
138 * processor expects them.
139 *
140 * Some remote processors will expect their code and data to be placed
141 * in specific device addresses, and can't have them dynamically assigned.
142 *
143 * We currently support only those kind of remote processors, and expect
144 * the program header's paddr member to contain those addresses. We then go
145 * through the physically contiguous "carveout" memory regions which we
146 * allocated (and mapped) earlier on behalf of the remote processor,
147 * and "translate" device address to kernel addresses, so we can copy the
148 * segments where they are expected.
149 *
150 * Currently we only support remote processors that required carveout
151 * allocations and got them mapped onto their iommus. Some processors
152 * might be different: they might not have iommus, and would prefer to
153 * directly allocate memory for every segment/resource. This is not yet
154 * supported, though.
155 */
156 int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
157 {
158 struct device *dev = &rproc->dev;
159 const void *ehdr, *phdr;
160 int i, ret = 0;
161 u16 phnum;
162 const u8 *elf_data = fw->data;
163 u8 class = fw_elf_get_class(fw);
164 u32 elf_phdr_get_size = elf_size_of_phdr(class);
165
166 ehdr = elf_data;
167 phnum = elf_hdr_get_e_phnum(class, ehdr);
168 phdr = elf_data + elf_hdr_get_e_phoff(class, ehdr);
169
170 /* go through the available ELF segments */
171 for (i = 0; i < phnum; i++, phdr += elf_phdr_get_size) {
172 u64 da = elf_phdr_get_p_paddr(class, phdr);
173 u64 memsz = elf_phdr_get_p_memsz(class, phdr);
174 u64 filesz = elf_phdr_get_p_filesz(class, phdr);
175 u64 offset = elf_phdr_get_p_offset(class, phdr);
176 u32 type = elf_phdr_get_p_type(class, phdr);
177 void *ptr;
178 bool is_iomem;
179
180 if (type != PT_LOAD)
181 continue;
182
183 dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
184 type, da, memsz, filesz);
185
186 if (filesz > memsz) {
187 dev_err(dev, "bad phdr filesz 0x%llx memsz 0x%llx\n",
188 filesz, memsz);
189 ret = -EINVAL;
190 break;
191 }
192
193 if (offset + filesz > fw->size) {
194 dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
195 offset + filesz, fw->size);
196 ret = -EINVAL;
197 break;
198 }
199
200 if (!rproc_u64_fit_in_size_t(memsz)) {
201 dev_err(dev, "size (%llx) does not fit in size_t type\n",
202 memsz);
203 ret = -EOVERFLOW;
204 break;
205 }
206
207 /* grab the kernel address for this device address */
208 ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
209 if (!ptr) {
210 dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
211 memsz);
212 ret = -EINVAL;
213 break;
214 }
215
216 /* put the segment where the remote processor expects it */
217 if (filesz) {
218 if (is_iomem)
> 219 memcpy_fromio(ptr, elf_data + offset, filesz);
220 else
221 memcpy(ptr, elf_data + offset, filesz);
222 }
223
224 /*
225 * Zero out remaining memory for this segment.
226 *
227 * This isn't strictly required since dma_alloc_coherent already
228 * did this for us. albeit harmless, we may consider removing
229 * this.
230 */
231 if (memsz > filesz) {
232 if (is_iomem)
> 233 memset_io(ptr + filesz, 0, memsz - filesz);
234 else
235 memset(ptr + filesz, 0, memsz - filesz);
236 }
237 }
238
239 return ret;
240 }
241 EXPORT_SYMBOL(rproc_elf_load_segments);
242
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 36269 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va
2020-12-29 3:30 ` peng.fan
@ 2020-12-30 15:20 ` kernel test robot
-1 siblings, 0 replies; 50+ messages in thread
From: kernel test robot @ 2020-12-30 15:20 UTC (permalink / raw)
To: peng.fan, ohad, bjorn.andersson, mathieu.poirier, o.rempel
Cc: kbuild-all, shawnguo, s.hauer, kernel, festevam, linux-imx,
linux-remoteproc
[-- Attachment #1: Type: text/plain, Size: 7019 bytes --]
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.11-rc1 next-20201223]
[cannot apply to soc/for-next xlnx/master remoteproc/for-next rpmsg/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dea8dcf2a9fa8cc540136a6cd885c3beece16ec3
config: i386-randconfig-s001-20201230 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
# https://github.com/0day-ci/linux/commit/f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
git checkout f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
"sparse warnings: (new ones prefixed by >>)"
>> drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem * @@ got unsigned char const [usertype] * @@
drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: expected void const volatile [noderef] __iomem *
drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: got unsigned char const [usertype] *
>> drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem * @@ got void * @@
drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: expected void volatile [noderef] __iomem *
drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: got void *
--
>> drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem * @@ got void *[assigned] ptr @@
drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: expected void const volatile [noderef] __iomem *
drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: got void *[assigned] ptr
vim +219 drivers/remoteproc/remoteproc_elf_loader.c
131
132 /**
133 * rproc_elf_load_segments() - load firmware segments to memory
134 * @rproc: remote processor which will be booted using these fw segments
135 * @fw: the ELF firmware image
136 *
137 * This function loads the firmware segments to memory, where the remote
138 * processor expects them.
139 *
140 * Some remote processors will expect their code and data to be placed
141 * in specific device addresses, and can't have them dynamically assigned.
142 *
143 * We currently support only those kind of remote processors, and expect
144 * the program header's paddr member to contain those addresses. We then go
145 * through the physically contiguous "carveout" memory regions which we
146 * allocated (and mapped) earlier on behalf of the remote processor,
147 * and "translate" device address to kernel addresses, so we can copy the
148 * segments where they are expected.
149 *
150 * Currently we only support remote processors that required carveout
151 * allocations and got them mapped onto their iommus. Some processors
152 * might be different: they might not have iommus, and would prefer to
153 * directly allocate memory for every segment/resource. This is not yet
154 * supported, though.
155 */
156 int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
157 {
158 struct device *dev = &rproc->dev;
159 const void *ehdr, *phdr;
160 int i, ret = 0;
161 u16 phnum;
162 const u8 *elf_data = fw->data;
163 u8 class = fw_elf_get_class(fw);
164 u32 elf_phdr_get_size = elf_size_of_phdr(class);
165
166 ehdr = elf_data;
167 phnum = elf_hdr_get_e_phnum(class, ehdr);
168 phdr = elf_data + elf_hdr_get_e_phoff(class, ehdr);
169
170 /* go through the available ELF segments */
171 for (i = 0; i < phnum; i++, phdr += elf_phdr_get_size) {
172 u64 da = elf_phdr_get_p_paddr(class, phdr);
173 u64 memsz = elf_phdr_get_p_memsz(class, phdr);
174 u64 filesz = elf_phdr_get_p_filesz(class, phdr);
175 u64 offset = elf_phdr_get_p_offset(class, phdr);
176 u32 type = elf_phdr_get_p_type(class, phdr);
177 void *ptr;
178 bool is_iomem;
179
180 if (type != PT_LOAD)
181 continue;
182
183 dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
184 type, da, memsz, filesz);
185
186 if (filesz > memsz) {
187 dev_err(dev, "bad phdr filesz 0x%llx memsz 0x%llx\n",
188 filesz, memsz);
189 ret = -EINVAL;
190 break;
191 }
192
193 if (offset + filesz > fw->size) {
194 dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
195 offset + filesz, fw->size);
196 ret = -EINVAL;
197 break;
198 }
199
200 if (!rproc_u64_fit_in_size_t(memsz)) {
201 dev_err(dev, "size (%llx) does not fit in size_t type\n",
202 memsz);
203 ret = -EOVERFLOW;
204 break;
205 }
206
207 /* grab the kernel address for this device address */
208 ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
209 if (!ptr) {
210 dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
211 memsz);
212 ret = -EINVAL;
213 break;
214 }
215
216 /* put the segment where the remote processor expects it */
217 if (filesz) {
218 if (is_iomem)
> 219 memcpy_fromio(ptr, elf_data + offset, filesz);
220 else
221 memcpy(ptr, elf_data + offset, filesz);
222 }
223
224 /*
225 * Zero out remaining memory for this segment.
226 *
227 * This isn't strictly required since dma_alloc_coherent already
228 * did this for us. albeit harmless, we may consider removing
229 * this.
230 */
231 if (memsz > filesz) {
232 if (is_iomem)
> 233 memset_io(ptr + filesz, 0, memsz - filesz);
234 else
235 memset(ptr + filesz, 0, memsz - filesz);
236 }
237 }
238
239 return ret;
240 }
241 EXPORT_SYMBOL(rproc_elf_load_segments);
242
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25361 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va
@ 2020-12-30 15:20 ` kernel test robot
0 siblings, 0 replies; 50+ messages in thread
From: kernel test robot @ 2020-12-30 15:20 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 7180 bytes --]
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.11-rc1 next-20201223]
[cannot apply to soc/for-next xlnx/master remoteproc/for-next rpmsg/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dea8dcf2a9fa8cc540136a6cd885c3beece16ec3
config: i386-randconfig-s001-20201230 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
# https://github.com/0day-ci/linux/commit/f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
git checkout f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
"sparse warnings: (new ones prefixed by >>)"
>> drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem * @@ got unsigned char const [usertype] * @@
drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: expected void const volatile [noderef] __iomem *
drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse: got unsigned char const [usertype] *
>> drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem * @@ got void * @@
drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: expected void volatile [noderef] __iomem *
drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: got void *
--
>> drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const volatile [noderef] __iomem * @@ got void *[assigned] ptr @@
drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: expected void const volatile [noderef] __iomem *
drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: got void *[assigned] ptr
vim +219 drivers/remoteproc/remoteproc_elf_loader.c
131
132 /**
133 * rproc_elf_load_segments() - load firmware segments to memory
134 * @rproc: remote processor which will be booted using these fw segments
135 * @fw: the ELF firmware image
136 *
137 * This function loads the firmware segments to memory, where the remote
138 * processor expects them.
139 *
140 * Some remote processors will expect their code and data to be placed
141 * in specific device addresses, and can't have them dynamically assigned.
142 *
143 * We currently support only those kind of remote processors, and expect
144 * the program header's paddr member to contain those addresses. We then go
145 * through the physically contiguous "carveout" memory regions which we
146 * allocated (and mapped) earlier on behalf of the remote processor,
147 * and "translate" device address to kernel addresses, so we can copy the
148 * segments where they are expected.
149 *
150 * Currently we only support remote processors that required carveout
151 * allocations and got them mapped onto their iommus. Some processors
152 * might be different: they might not have iommus, and would prefer to
153 * directly allocate memory for every segment/resource. This is not yet
154 * supported, though.
155 */
156 int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
157 {
158 struct device *dev = &rproc->dev;
159 const void *ehdr, *phdr;
160 int i, ret = 0;
161 u16 phnum;
162 const u8 *elf_data = fw->data;
163 u8 class = fw_elf_get_class(fw);
164 u32 elf_phdr_get_size = elf_size_of_phdr(class);
165
166 ehdr = elf_data;
167 phnum = elf_hdr_get_e_phnum(class, ehdr);
168 phdr = elf_data + elf_hdr_get_e_phoff(class, ehdr);
169
170 /* go through the available ELF segments */
171 for (i = 0; i < phnum; i++, phdr += elf_phdr_get_size) {
172 u64 da = elf_phdr_get_p_paddr(class, phdr);
173 u64 memsz = elf_phdr_get_p_memsz(class, phdr);
174 u64 filesz = elf_phdr_get_p_filesz(class, phdr);
175 u64 offset = elf_phdr_get_p_offset(class, phdr);
176 u32 type = elf_phdr_get_p_type(class, phdr);
177 void *ptr;
178 bool is_iomem;
179
180 if (type != PT_LOAD)
181 continue;
182
183 dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
184 type, da, memsz, filesz);
185
186 if (filesz > memsz) {
187 dev_err(dev, "bad phdr filesz 0x%llx memsz 0x%llx\n",
188 filesz, memsz);
189 ret = -EINVAL;
190 break;
191 }
192
193 if (offset + filesz > fw->size) {
194 dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
195 offset + filesz, fw->size);
196 ret = -EINVAL;
197 break;
198 }
199
200 if (!rproc_u64_fit_in_size_t(memsz)) {
201 dev_err(dev, "size (%llx) does not fit in size_t type\n",
202 memsz);
203 ret = -EOVERFLOW;
204 break;
205 }
206
207 /* grab the kernel address for this device address */
208 ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
209 if (!ptr) {
210 dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
211 memsz);
212 ret = -EINVAL;
213 break;
214 }
215
216 /* put the segment where the remote processor expects it */
217 if (filesz) {
218 if (is_iomem)
> 219 memcpy_fromio(ptr, elf_data + offset, filesz);
220 else
221 memcpy(ptr, elf_data + offset, filesz);
222 }
223
224 /*
225 * Zero out remaining memory for this segment.
226 *
227 * This isn't strictly required since dma_alloc_coherent already
228 * did this for us. albeit harmless, we may consider removing
229 * this.
230 */
231 if (memsz > filesz) {
232 if (is_iomem)
> 233 memset_io(ptr + filesz, 0, memsz - filesz);
234 else
235 memset(ptr + filesz, 0, memsz - filesz);
236 }
237 }
238
239 return ret;
240 }
241 EXPORT_SYMBOL(rproc_elf_load_segments);
242
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 25361 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 1/8] remoteproc: introduce is_iomem to rproc_mem_entry
2020-12-29 3:30 ` peng.fan
@ 2021-01-11 18:53 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 18:53 UTC (permalink / raw)
To: peng.fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
On Tue, Dec 29, 2020 at 11:30:12AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Introduce is_iomem to indicate this piece memory is iomem or not.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> include/linux/remoteproc.h | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index f28ee75d1005..a5f6d2d9cde2 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -315,6 +315,7 @@ struct rproc;
> /**
> * struct rproc_mem_entry - memory entry descriptor
> * @va: virtual address
> + * @is_iomem: io memory
> * @dma: dma address
> * @len: length, in bytes
> * @da: device address
> @@ -329,6 +330,7 @@ struct rproc;
> */
> struct rproc_mem_entry {
> void *va;
> + bool is_iomem;
> dma_addr_t dma;
> size_t len;
> u32 da;
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 1/8] remoteproc: introduce is_iomem to rproc_mem_entry
@ 2021-01-11 18:53 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 18:53 UTC (permalink / raw)
To: peng.fan
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross, linux-imx,
kernel, matthias.bgg, shawnguo, linux-arm-kernel
On Tue, Dec 29, 2020 at 11:30:12AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Introduce is_iomem to indicate this piece memory is iomem or not.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> include/linux/remoteproc.h | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index f28ee75d1005..a5f6d2d9cde2 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -315,6 +315,7 @@ struct rproc;
> /**
> * struct rproc_mem_entry - memory entry descriptor
> * @va: virtual address
> + * @is_iomem: io memory
> * @dma: dma address
> * @len: length, in bytes
> * @da: device address
> @@ -329,6 +330,7 @@ struct rproc;
> */
> struct rproc_mem_entry {
> void *va;
> + bool is_iomem;
> dma_addr_t dma;
> size_t len;
> u32 da;
> --
> 2.28.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va
2020-12-29 3:30 ` peng.fan
@ 2021-01-11 20:25 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 20:25 UTC (permalink / raw)
To: peng.fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
On Tue, Dec 29, 2020 at 11:30:13AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Introduce an extra parameter is_iomem to da_to_va, then the caller
> could take the memory as normal memory or io mapped memory.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 2 +-
> drivers/remoteproc/ingenic_rproc.c | 2 +-
> drivers/remoteproc/keystone_remoteproc.c | 2 +-
> drivers/remoteproc/mtk_scp.c | 6 +++---
> drivers/remoteproc/omap_remoteproc.c | 2 +-
> drivers/remoteproc/pru_rproc.c | 2 +-
> drivers/remoteproc/qcom_q6v5_adsp.c | 2 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
> drivers/remoteproc/qcom_q6v5_wcss.c | 2 +-
> drivers/remoteproc/qcom_wcnss.c | 2 +-
> drivers/remoteproc/remoteproc_core.c | 7 +++++--
> drivers/remoteproc/remoteproc_coredump.c | 8 ++++++--
> drivers/remoteproc/remoteproc_debugfs.c | 2 +-
> drivers/remoteproc/remoteproc_elf_loader.c | 21 +++++++++++++++------
> drivers/remoteproc/remoteproc_internal.h | 2 +-
> drivers/remoteproc/st_slim_rproc.c | 2 +-
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +-
> drivers/remoteproc/wkup_m3_rproc.c | 2 +-
> include/linux/remoteproc.h | 2 +-
> 20 files changed, 45 insertions(+), 29 deletions(-)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 8957ed271d20..6603e00bb6f4 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -208,7 +208,7 @@ static int imx_rproc_da_to_sys(struct imx_rproc *priv, u64 da,
> return -ENOENT;
> }
>
> -static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct imx_rproc *priv = rproc->priv;
> void *va = NULL;
> diff --git a/drivers/remoteproc/ingenic_rproc.c b/drivers/remoteproc/ingenic_rproc.c
> index 26e19e6143b7..bb5049295576 100644
> --- a/drivers/remoteproc/ingenic_rproc.c
> +++ b/drivers/remoteproc/ingenic_rproc.c
> @@ -116,7 +116,7 @@ static void ingenic_rproc_kick(struct rproc *rproc, int vqid)
> writel(vqid, vpu->aux_base + REG_CORE_MSG);
> }
>
> -static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct vpu *vpu = rproc->priv;
> void __iomem *va = NULL;
> diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
> index cd266163a65f..54781f553f4e 100644
> --- a/drivers/remoteproc/keystone_remoteproc.c
> +++ b/drivers/remoteproc/keystone_remoteproc.c
> @@ -246,7 +246,7 @@ static void keystone_rproc_kick(struct rproc *rproc, int vqid)
> * can be used either by the remoteproc core for loading (when using kernel
> * remoteproc loader), or by any rpmsg bus drivers.
> */
> -static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct keystone_rproc *ksproc = rproc->priv;
> void __iomem *va = NULL;
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index e0c235690361..535175f013e4 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -270,7 +270,7 @@ static int scp_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> }
>
> /* grab the kernel address for this device address */
> - ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz);
> + ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz, NULL);
> if (!ptr) {
> dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
> ret = -EINVAL;
> @@ -458,7 +458,7 @@ static int scp_start(struct rproc *rproc)
> return ret;
> }
>
> -static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
> int offset;
> @@ -587,7 +587,7 @@ void *scp_mapping_dm_addr(struct mtk_scp *scp, u32 mem_addr)
> {
> void *ptr;
>
> - ptr = scp_da_to_va(scp->rproc, mem_addr, 0);
> + ptr = scp_da_to_va(scp->rproc, mem_addr, 0, NULL);
> if (!ptr)
> return ERR_PTR(-EINVAL);
>
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index d94b7391bf9d..43531caa1959 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -728,7 +728,7 @@ static int omap_rproc_stop(struct rproc *rproc)
> * Return: translated virtual address in kernel memory space on success,
> * or NULL on failure.
> */
> -static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct omap_rproc *oproc = rproc->priv;
> int i;
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index 2667919d76b3..2dcaa274e266 100644
> --- a/drivers/remoteproc/pru_rproc.c
> +++ b/drivers/remoteproc/pru_rproc.c
> @@ -465,7 +465,7 @@ static void *pru_i_da_to_va(struct pru_rproc *pru, u32 da, size_t len)
> * core for any PRU client drivers. The PRU Instruction RAM access is restricted
> * only to the PRU loader code.
> */
> -static void *pru_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *pru_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct pru_rproc *pru = rproc->priv;
>
> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c
> index e02450225e4a..8b0d8bbacd2e 100644
> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
> @@ -281,7 +281,7 @@ static int adsp_stop(struct rproc *rproc)
> return ret;
> }
>
> -static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
> int offset;
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index ee586226e438..333a1e389fcd 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -242,7 +242,7 @@ static int adsp_stop(struct rproc *rproc)
> return ret;
> }
>
> -static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
> int offset;
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c b/drivers/remoteproc/qcom_q6v5_wcss.c
> index 78ebe1168b33..704cd63c9af4 100644
> --- a/drivers/remoteproc/qcom_q6v5_wcss.c
> +++ b/drivers/remoteproc/qcom_q6v5_wcss.c
> @@ -410,7 +410,7 @@ static int q6v5_wcss_stop(struct rproc *rproc)
> return 0;
> }
>
> -static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct q6v5_wcss *wcss = rproc->priv;
> int offset;
> diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
> index f95854255c70..1bf60dc84f69 100644
> --- a/drivers/remoteproc/qcom_wcnss.c
> +++ b/drivers/remoteproc/qcom_wcnss.c
> @@ -320,7 +320,7 @@ static int wcnss_stop(struct rproc *rproc)
> return ret;
> }
>
> -static void *wcnss_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *wcnss_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct qcom_wcnss *wcnss = (struct qcom_wcnss *)rproc->priv;
> int offset;
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 2394eef383e3..9bec422ccce3 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -189,13 +189,13 @@ EXPORT_SYMBOL(rproc_va_to_pa);
> * here the output of the DMA API for the carveouts, which should be more
> * correct.
> */
> -void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct rproc_mem_entry *carveout;
> void *ptr = NULL;
>
> if (rproc->ops->da_to_va) {
> - ptr = rproc->ops->da_to_va(rproc, da, len);
> + ptr = rproc->ops->da_to_va(rproc, da, len, is_iomem);
> if (ptr)
> goto out;
> }
> @@ -217,6 +217,9 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
>
> ptr = carveout->va + offset;
>
> + if (is_iomem)
> + *is_iomem = carveout->is_iomem;
> +
> break;
> }
>
> diff --git a/drivers/remoteproc/remoteproc_coredump.c b/drivers/remoteproc/remoteproc_coredump.c
> index 81ec154a6a5e..aee657cc08c6 100644
> --- a/drivers/remoteproc/remoteproc_coredump.c
> +++ b/drivers/remoteproc/remoteproc_coredump.c
> @@ -153,18 +153,22 @@ static void rproc_copy_segment(struct rproc *rproc, void *dest,
> size_t offset, size_t size)
> {
> void *ptr;
> + bool is_iomem;
>
> if (segment->dump) {
> segment->dump(rproc, segment, dest, offset, size);
> } else {
> - ptr = rproc_da_to_va(rproc, segment->da + offset, size);
> + ptr = rproc_da_to_va(rproc, segment->da + offset, size, &is_iomem);
> if (!ptr) {
> dev_err(&rproc->dev,
> "invalid copy request for segment %pad with offset %zu and size %zu)\n",
> &segment->da, offset, size);
> memset(dest, 0xff, size);
> } else {
> - memcpy(dest, ptr, size);
> + if (is_iomem)
> + memcpy_fromio(dest, ptr, size);
> + else
> + memcpy(dest, ptr, size);
> }
> }
> }
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> index 7e5845376e9f..b5a1e3b697d9 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -132,7 +132,7 @@ static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
> char buf[100];
> int len;
>
> - va = rproc_da_to_va(data->rproc, trace->da, trace->len);
> + va = rproc_da_to_va(data->rproc, trace->da, trace->len, NULL);
>
> if (!va) {
> len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
> index df68d87752e4..c02d4fec93a9 100644
> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> @@ -175,6 +175,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> u64 offset = elf_phdr_get_p_offset(class, phdr);
> u32 type = elf_phdr_get_p_type(class, phdr);
> void *ptr;
> + bool is_iomem;
>
> if (type != PT_LOAD)
> continue;
> @@ -204,7 +205,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> }
>
> /* grab the kernel address for this device address */
> - ptr = rproc_da_to_va(rproc, da, memsz);
> + 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);
> @@ -213,8 +214,12 @@ 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);
> + if (filesz) {
> + if (is_iomem)
> + memcpy_fromio(ptr, elf_data + offset, filesz);
> + else
> + memcpy(ptr, elf_data + offset, filesz);
> + }
>
> /*
> * Zero out remaining memory for this segment.
> @@ -223,8 +228,12 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> * did this for us. albeit harmless, we may consider removing
> * this.
> */
> - if (memsz > filesz)
> - memset(ptr + filesz, 0, memsz - filesz);
> + if (memsz > filesz) {
> + if (is_iomem)
> + memset_io(ptr + filesz, 0, memsz - filesz);
> + else
> + memset(ptr + filesz, 0, memsz - filesz);
> + }
> }
>
> return ret;
> @@ -377,6 +386,6 @@ struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
> return NULL;
> }
>
> - return rproc_da_to_va(rproc, sh_addr, sh_size);
> + return rproc_da_to_va(rproc, sh_addr, sh_size, NULL);
> }
> EXPORT_SYMBOL(rproc_elf_find_loaded_rsc_table);
> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> index c34002888d2c..9ea37aa687d2 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -84,7 +84,7 @@ static inline void rproc_char_device_remove(struct rproc *rproc)
> void rproc_free_vring(struct rproc_vring *rvring);
> int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
>
> -void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len);
> +void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
> phys_addr_t rproc_va_to_pa(void *cpu_addr);
> int rproc_trigger_recovery(struct rproc *rproc);
>
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> index 09bcb4d8b9e0..22096adc1ad3 100644
> --- a/drivers/remoteproc/st_slim_rproc.c
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -174,7 +174,7 @@ static int slim_rproc_stop(struct rproc *rproc)
> return 0;
> }
>
> -static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct st_slim_rproc *slim_rproc = rproc->priv;
> void *va = NULL;
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index 863c0214e0a8..fd4eb67a6681 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -354,7 +354,7 @@ static int k3_dsp_rproc_stop(struct rproc *rproc)
> * can be used either by the remoteproc core for loading (when using kernel
> * remoteproc loader), or by any rpmsg bus drivers.
> */
> -static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct k3_dsp_rproc *kproc = rproc->priv;
> void __iomem *va = NULL;
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 62b5a4c29456..5cf8d030a1f0 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -590,7 +590,7 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
> * present in a DSP or IPU device). The translated addresses can be used
> * either by the remoteproc core for loading, or by any rpmsg bus drivers.
> */
> -static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct k3_r5_rproc *kproc = rproc->priv;
> struct k3_r5_core *core = kproc->core;
> diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
> index 92d387dfc03b..484f7605823e 100644
> --- a/drivers/remoteproc/wkup_m3_rproc.c
> +++ b/drivers/remoteproc/wkup_m3_rproc.c
> @@ -89,7 +89,7 @@ static int wkup_m3_rproc_stop(struct rproc *rproc)
> return error;
> }
>
> -static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct wkup_m3_rproc *wkupm3 = rproc->priv;
> void *va = NULL;
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index a5f6d2d9cde2..1b7d56c7a453 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -386,7 +386,7 @@ struct rproc_ops {
> int (*stop)(struct rproc *rproc);
> int (*attach)(struct rproc *rproc);
> void (*kick)(struct rproc *rproc, int vqid);
> - void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len);
> + void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
> 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.28.0
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va
@ 2021-01-11 20:25 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 20:25 UTC (permalink / raw)
To: peng.fan
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross, linux-imx,
kernel, matthias.bgg, shawnguo, linux-arm-kernel
On Tue, Dec 29, 2020 at 11:30:13AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Introduce an extra parameter is_iomem to da_to_va, then the caller
> could take the memory as normal memory or io mapped memory.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 2 +-
> drivers/remoteproc/ingenic_rproc.c | 2 +-
> drivers/remoteproc/keystone_remoteproc.c | 2 +-
> drivers/remoteproc/mtk_scp.c | 6 +++---
> drivers/remoteproc/omap_remoteproc.c | 2 +-
> drivers/remoteproc/pru_rproc.c | 2 +-
> drivers/remoteproc/qcom_q6v5_adsp.c | 2 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
> drivers/remoteproc/qcom_q6v5_wcss.c | 2 +-
> drivers/remoteproc/qcom_wcnss.c | 2 +-
> drivers/remoteproc/remoteproc_core.c | 7 +++++--
> drivers/remoteproc/remoteproc_coredump.c | 8 ++++++--
> drivers/remoteproc/remoteproc_debugfs.c | 2 +-
> drivers/remoteproc/remoteproc_elf_loader.c | 21 +++++++++++++++------
> drivers/remoteproc/remoteproc_internal.h | 2 +-
> drivers/remoteproc/st_slim_rproc.c | 2 +-
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +-
> drivers/remoteproc/wkup_m3_rproc.c | 2 +-
> include/linux/remoteproc.h | 2 +-
> 20 files changed, 45 insertions(+), 29 deletions(-)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 8957ed271d20..6603e00bb6f4 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -208,7 +208,7 @@ static int imx_rproc_da_to_sys(struct imx_rproc *priv, u64 da,
> return -ENOENT;
> }
>
> -static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct imx_rproc *priv = rproc->priv;
> void *va = NULL;
> diff --git a/drivers/remoteproc/ingenic_rproc.c b/drivers/remoteproc/ingenic_rproc.c
> index 26e19e6143b7..bb5049295576 100644
> --- a/drivers/remoteproc/ingenic_rproc.c
> +++ b/drivers/remoteproc/ingenic_rproc.c
> @@ -116,7 +116,7 @@ static void ingenic_rproc_kick(struct rproc *rproc, int vqid)
> writel(vqid, vpu->aux_base + REG_CORE_MSG);
> }
>
> -static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct vpu *vpu = rproc->priv;
> void __iomem *va = NULL;
> diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
> index cd266163a65f..54781f553f4e 100644
> --- a/drivers/remoteproc/keystone_remoteproc.c
> +++ b/drivers/remoteproc/keystone_remoteproc.c
> @@ -246,7 +246,7 @@ static void keystone_rproc_kick(struct rproc *rproc, int vqid)
> * can be used either by the remoteproc core for loading (when using kernel
> * remoteproc loader), or by any rpmsg bus drivers.
> */
> -static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct keystone_rproc *ksproc = rproc->priv;
> void __iomem *va = NULL;
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index e0c235690361..535175f013e4 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -270,7 +270,7 @@ static int scp_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> }
>
> /* grab the kernel address for this device address */
> - ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz);
> + ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz, NULL);
> if (!ptr) {
> dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
> ret = -EINVAL;
> @@ -458,7 +458,7 @@ static int scp_start(struct rproc *rproc)
> return ret;
> }
>
> -static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
> int offset;
> @@ -587,7 +587,7 @@ void *scp_mapping_dm_addr(struct mtk_scp *scp, u32 mem_addr)
> {
> void *ptr;
>
> - ptr = scp_da_to_va(scp->rproc, mem_addr, 0);
> + ptr = scp_da_to_va(scp->rproc, mem_addr, 0, NULL);
> if (!ptr)
> return ERR_PTR(-EINVAL);
>
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index d94b7391bf9d..43531caa1959 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -728,7 +728,7 @@ static int omap_rproc_stop(struct rproc *rproc)
> * Return: translated virtual address in kernel memory space on success,
> * or NULL on failure.
> */
> -static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct omap_rproc *oproc = rproc->priv;
> int i;
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index 2667919d76b3..2dcaa274e266 100644
> --- a/drivers/remoteproc/pru_rproc.c
> +++ b/drivers/remoteproc/pru_rproc.c
> @@ -465,7 +465,7 @@ static void *pru_i_da_to_va(struct pru_rproc *pru, u32 da, size_t len)
> * core for any PRU client drivers. The PRU Instruction RAM access is restricted
> * only to the PRU loader code.
> */
> -static void *pru_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *pru_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct pru_rproc *pru = rproc->priv;
>
> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c
> index e02450225e4a..8b0d8bbacd2e 100644
> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
> @@ -281,7 +281,7 @@ static int adsp_stop(struct rproc *rproc)
> return ret;
> }
>
> -static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
> int offset;
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index ee586226e438..333a1e389fcd 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -242,7 +242,7 @@ static int adsp_stop(struct rproc *rproc)
> return ret;
> }
>
> -static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
> int offset;
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c b/drivers/remoteproc/qcom_q6v5_wcss.c
> index 78ebe1168b33..704cd63c9af4 100644
> --- a/drivers/remoteproc/qcom_q6v5_wcss.c
> +++ b/drivers/remoteproc/qcom_q6v5_wcss.c
> @@ -410,7 +410,7 @@ static int q6v5_wcss_stop(struct rproc *rproc)
> return 0;
> }
>
> -static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct q6v5_wcss *wcss = rproc->priv;
> int offset;
> diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
> index f95854255c70..1bf60dc84f69 100644
> --- a/drivers/remoteproc/qcom_wcnss.c
> +++ b/drivers/remoteproc/qcom_wcnss.c
> @@ -320,7 +320,7 @@ static int wcnss_stop(struct rproc *rproc)
> return ret;
> }
>
> -static void *wcnss_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *wcnss_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct qcom_wcnss *wcnss = (struct qcom_wcnss *)rproc->priv;
> int offset;
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 2394eef383e3..9bec422ccce3 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -189,13 +189,13 @@ EXPORT_SYMBOL(rproc_va_to_pa);
> * here the output of the DMA API for the carveouts, which should be more
> * correct.
> */
> -void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct rproc_mem_entry *carveout;
> void *ptr = NULL;
>
> if (rproc->ops->da_to_va) {
> - ptr = rproc->ops->da_to_va(rproc, da, len);
> + ptr = rproc->ops->da_to_va(rproc, da, len, is_iomem);
> if (ptr)
> goto out;
> }
> @@ -217,6 +217,9 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
>
> ptr = carveout->va + offset;
>
> + if (is_iomem)
> + *is_iomem = carveout->is_iomem;
> +
> break;
> }
>
> diff --git a/drivers/remoteproc/remoteproc_coredump.c b/drivers/remoteproc/remoteproc_coredump.c
> index 81ec154a6a5e..aee657cc08c6 100644
> --- a/drivers/remoteproc/remoteproc_coredump.c
> +++ b/drivers/remoteproc/remoteproc_coredump.c
> @@ -153,18 +153,22 @@ static void rproc_copy_segment(struct rproc *rproc, void *dest,
> size_t offset, size_t size)
> {
> void *ptr;
> + bool is_iomem;
>
> if (segment->dump) {
> segment->dump(rproc, segment, dest, offset, size);
> } else {
> - ptr = rproc_da_to_va(rproc, segment->da + offset, size);
> + ptr = rproc_da_to_va(rproc, segment->da + offset, size, &is_iomem);
> if (!ptr) {
> dev_err(&rproc->dev,
> "invalid copy request for segment %pad with offset %zu and size %zu)\n",
> &segment->da, offset, size);
> memset(dest, 0xff, size);
> } else {
> - memcpy(dest, ptr, size);
> + if (is_iomem)
> + memcpy_fromio(dest, ptr, size);
> + else
> + memcpy(dest, ptr, size);
> }
> }
> }
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> index 7e5845376e9f..b5a1e3b697d9 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -132,7 +132,7 @@ static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
> char buf[100];
> int len;
>
> - va = rproc_da_to_va(data->rproc, trace->da, trace->len);
> + va = rproc_da_to_va(data->rproc, trace->da, trace->len, NULL);
>
> if (!va) {
> len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
> index df68d87752e4..c02d4fec93a9 100644
> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> @@ -175,6 +175,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> u64 offset = elf_phdr_get_p_offset(class, phdr);
> u32 type = elf_phdr_get_p_type(class, phdr);
> void *ptr;
> + bool is_iomem;
>
> if (type != PT_LOAD)
> continue;
> @@ -204,7 +205,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> }
>
> /* grab the kernel address for this device address */
> - ptr = rproc_da_to_va(rproc, da, memsz);
> + 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);
> @@ -213,8 +214,12 @@ 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);
> + if (filesz) {
> + if (is_iomem)
> + memcpy_fromio(ptr, elf_data + offset, filesz);
> + else
> + memcpy(ptr, elf_data + offset, filesz);
> + }
>
> /*
> * Zero out remaining memory for this segment.
> @@ -223,8 +228,12 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> * did this for us. albeit harmless, we may consider removing
> * this.
> */
> - if (memsz > filesz)
> - memset(ptr + filesz, 0, memsz - filesz);
> + if (memsz > filesz) {
> + if (is_iomem)
> + memset_io(ptr + filesz, 0, memsz - filesz);
> + else
> + memset(ptr + filesz, 0, memsz - filesz);
> + }
> }
>
> return ret;
> @@ -377,6 +386,6 @@ struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
> return NULL;
> }
>
> - return rproc_da_to_va(rproc, sh_addr, sh_size);
> + return rproc_da_to_va(rproc, sh_addr, sh_size, NULL);
> }
> EXPORT_SYMBOL(rproc_elf_find_loaded_rsc_table);
> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> index c34002888d2c..9ea37aa687d2 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -84,7 +84,7 @@ static inline void rproc_char_device_remove(struct rproc *rproc)
> void rproc_free_vring(struct rproc_vring *rvring);
> int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
>
> -void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len);
> +void *rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
> phys_addr_t rproc_va_to_pa(void *cpu_addr);
> int rproc_trigger_recovery(struct rproc *rproc);
>
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> index 09bcb4d8b9e0..22096adc1ad3 100644
> --- a/drivers/remoteproc/st_slim_rproc.c
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -174,7 +174,7 @@ static int slim_rproc_stop(struct rproc *rproc)
> return 0;
> }
>
> -static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct st_slim_rproc *slim_rproc = rproc->priv;
> void *va = NULL;
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index 863c0214e0a8..fd4eb67a6681 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -354,7 +354,7 @@ static int k3_dsp_rproc_stop(struct rproc *rproc)
> * can be used either by the remoteproc core for loading (when using kernel
> * remoteproc loader), or by any rpmsg bus drivers.
> */
> -static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct k3_dsp_rproc *kproc = rproc->priv;
> void __iomem *va = NULL;
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 62b5a4c29456..5cf8d030a1f0 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -590,7 +590,7 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
> * present in a DSP or IPU device). The translated addresses can be used
> * either by the remoteproc core for loading, or by any rpmsg bus drivers.
> */
> -static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct k3_r5_rproc *kproc = rproc->priv;
> struct k3_r5_core *core = kproc->core;
> diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
> index 92d387dfc03b..484f7605823e 100644
> --- a/drivers/remoteproc/wkup_m3_rproc.c
> +++ b/drivers/remoteproc/wkup_m3_rproc.c
> @@ -89,7 +89,7 @@ static int wkup_m3_rproc_stop(struct rproc *rproc)
> return error;
> }
>
> -static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> {
> struct wkup_m3_rproc *wkupm3 = rproc->priv;
> void *va = NULL;
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index a5f6d2d9cde2..1b7d56c7a453 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -386,7 +386,7 @@ struct rproc_ops {
> int (*stop)(struct rproc *rproc);
> int (*attach)(struct rproc *rproc);
> void (*kick)(struct rproc *rproc, int vqid);
> - void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len);
> + void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
> 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.28.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 3/8] remoteproc: imx_rproc: correct err message
2020-12-29 3:30 ` peng.fan
@ 2021-01-11 20:35 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 20:35 UTC (permalink / raw)
To: peng.fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
On Tue, Dec 29, 2020 at 11:30:14AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> It is using devm_ioremap, so not devm_ioremap_resource. Correct
> the error message and print out sa/size.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 6603e00bb6f4..2a093cea4997 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -268,7 +268,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
> att->sa, att->size);
> if (!priv->mem[b].cpu_addr) {
> - dev_err(dev, "devm_ioremap_resource failed\n");
> + dev_err(dev, "failed to remap %#x bytes from %#x\n", att->size, att->sa);
> return -ENOMEM;
> }
> priv->mem[b].sys_addr = att->sa;
> @@ -298,7 +298,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>
> priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
> if (IS_ERR(priv->mem[b].cpu_addr)) {
> - dev_err(dev, "devm_ioremap_resource failed\n");
> + dev_err(dev, "failed to remap %pr\n", &res);
> err = PTR_ERR(priv->mem[b].cpu_addr);
> return err;
> }
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 3/8] remoteproc: imx_rproc: correct err message
@ 2021-01-11 20:35 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 20:35 UTC (permalink / raw)
To: peng.fan
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross, linux-imx,
kernel, matthias.bgg, shawnguo, linux-arm-kernel
On Tue, Dec 29, 2020 at 11:30:14AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> It is using devm_ioremap, so not devm_ioremap_resource. Correct
> the error message and print out sa/size.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 6603e00bb6f4..2a093cea4997 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -268,7 +268,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
> att->sa, att->size);
> if (!priv->mem[b].cpu_addr) {
> - dev_err(dev, "devm_ioremap_resource failed\n");
> + dev_err(dev, "failed to remap %#x bytes from %#x\n", att->size, att->sa);
> return -ENOMEM;
> }
> priv->mem[b].sys_addr = att->sa;
> @@ -298,7 +298,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>
> priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
> if (IS_ERR(priv->mem[b].cpu_addr)) {
> - dev_err(dev, "devm_ioremap_resource failed\n");
> + dev_err(dev, "failed to remap %pr\n", &res);
> err = PTR_ERR(priv->mem[b].cpu_addr);
> return err;
> }
> --
> 2.28.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 3/8] remoteproc: imx_rproc: correct err message
2020-12-29 3:30 ` peng.fan
@ 2021-01-11 20:44 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 20:44 UTC (permalink / raw)
To: peng.fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
On Tue, Dec 29, 2020 at 11:30:14AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> It is using devm_ioremap, so not devm_ioremap_resource. Correct
> the error message and print out sa/size.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 6603e00bb6f4..2a093cea4997 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -268,7 +268,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
> att->sa, att->size);
> if (!priv->mem[b].cpu_addr) {
> - dev_err(dev, "devm_ioremap_resource failed\n");
> + dev_err(dev, "failed to remap %#x bytes from %#x\n", att->size, att->sa);
> return -ENOMEM;
> }
> priv->mem[b].sys_addr = att->sa;
> @@ -298,7 +298,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>
> priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
> if (IS_ERR(priv->mem[b].cpu_addr)) {
> - dev_err(dev, "devm_ioremap_resource failed\n");
> + dev_err(dev, "failed to remap %pr\n", &res);
> err = PTR_ERR(priv->mem[b].cpu_addr);
> return err;
> }
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 3/8] remoteproc: imx_rproc: correct err message
@ 2021-01-11 20:44 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 20:44 UTC (permalink / raw)
To: peng.fan
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross, linux-imx,
kernel, matthias.bgg, shawnguo, linux-arm-kernel
On Tue, Dec 29, 2020 at 11:30:14AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> It is using devm_ioremap, so not devm_ioremap_resource. Correct
> the error message and print out sa/size.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 6603e00bb6f4..2a093cea4997 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -268,7 +268,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
> att->sa, att->size);
> if (!priv->mem[b].cpu_addr) {
> - dev_err(dev, "devm_ioremap_resource failed\n");
> + dev_err(dev, "failed to remap %#x bytes from %#x\n", att->size, att->sa);
> return -ENOMEM;
> }
> priv->mem[b].sys_addr = att->sa;
> @@ -298,7 +298,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>
> priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
> if (IS_ERR(priv->mem[b].cpu_addr)) {
> - dev_err(dev, "devm_ioremap_resource failed\n");
> + dev_err(dev, "failed to remap %pr\n", &res);
> err = PTR_ERR(priv->mem[b].cpu_addr);
> return err;
> }
> --
> 2.28.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 4/8] remoteproc: imx_rproc: use devm_ioremap
2020-12-29 3:30 ` peng.fan
@ 2021-01-11 20:46 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 20:46 UTC (permalink / raw)
To: peng.fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard,
Richard Zhu
On Tue, Dec 29, 2020 at 11:30:15AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> We might need to map an region multiple times, becaue the region might
> be shared between remote processors, such i.MX8QM with dual M4 cores.
> So use devm_ioremap, not devm_ioremap_resource.
>
> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 2a093cea4997..47fc1d06be6a 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -296,7 +296,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> if (b >= IMX7D_RPROC_MEM_MAX)
> break;
>
> - priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
> + /* Not use resource version, because we might share region */
> + priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev, res.start, resource_size(&res));
> if (IS_ERR(priv->mem[b].cpu_addr)) {
> dev_err(dev, "failed to remap %pr\n", &res);
> err = PTR_ERR(priv->mem[b].cpu_addr);
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 4/8] remoteproc: imx_rproc: use devm_ioremap
@ 2021-01-11 20:46 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 20:46 UTC (permalink / raw)
To: peng.fan
Cc: ohad, Richard Zhu, patrice.chotard, festevam, s.hauer,
linux-remoteproc, linux-kernel, bjorn.andersson, paul, o.rempel,
agross, linux-imx, kernel, matthias.bgg, shawnguo,
linux-arm-kernel
On Tue, Dec 29, 2020 at 11:30:15AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> We might need to map an region multiple times, becaue the region might
> be shared between remote processors, such i.MX8QM with dual M4 cores.
> So use devm_ioremap, not devm_ioremap_resource.
>
> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 2a093cea4997..47fc1d06be6a 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -296,7 +296,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> if (b >= IMX7D_RPROC_MEM_MAX)
> break;
>
> - priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
> + /* Not use resource version, because we might share region */
> + priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev, res.start, resource_size(&res));
> if (IS_ERR(priv->mem[b].cpu_addr)) {
> dev_err(dev, "failed to remap %pr\n", &res);
> err = PTR_ERR(priv->mem[b].cpu_addr);
> --
> 2.28.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 6/8] remoteproc: imx_rproc: support i.MX8MQ/M
2020-12-29 3:30 ` peng.fan
@ 2021-01-11 21:40 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 21:40 UTC (permalink / raw)
To: peng.fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard,
Richard Zhu
On Tue, Dec 29, 2020 at 11:30:17AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add i.MX8MQ dev/sys addr map and configuration data structure
> i.MX8MM share i.MX8MQ settings.
>
> Reviewed-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/imx_rproc.c | 39 ++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 3c0075dc1787..f80428afb8a7 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -88,6 +88,34 @@ struct imx_rproc {
> struct clk *clk;
> };
>
> +static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
> + /* dev addr , sys addr , size , flags */
> + /* TCML - alias */
> + { 0x00000000, 0x007e0000, 0x00020000, 0 },
> + /* OCRAM_S */
> + { 0x00180000, 0x00180000, 0x00008000, 0 },
> + /* OCRAM */
> + { 0x00900000, 0x00900000, 0x00020000, 0 },
> + /* OCRAM */
> + { 0x00920000, 0x00920000, 0x00020000, 0 },
> + /* QSPI Code - alias */
> + { 0x08000000, 0x08000000, 0x08000000, 0 },
> + /* DDR (Code) - alias */
> + { 0x10000000, 0x80000000, 0x0FFE0000, 0 },
> + /* TCML */
> + { 0x1FFE0000, 0x007E0000, 0x00020000, ATT_OWN },
> + /* TCMU */
> + { 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
> + /* OCRAM_S */
> + { 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
> + /* OCRAM */
> + { 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
> + /* OCRAM */
> + { 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
> + /* DDR (Data) */
> + { 0x40000000, 0x40000000, 0x80000000, 0 },
> +};
> +
> static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
> /* dev addr , sys addr , size , flags */
> /* OCRAM_S (M4 Boot code) - alias */
> @@ -138,6 +166,15 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = {
> { 0x80000000, 0x80000000, 0x60000000, 0 },
> };
>
> +static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
> + .src_reg = IMX7D_SRC_SCR,
> + .src_mask = IMX7D_M4_RST_MASK,
> + .src_start = IMX7D_M4_START,
> + .src_stop = IMX7D_M4_STOP,
> + .att = imx_rproc_att_imx8mq,
> + .att_size = ARRAY_SIZE(imx_rproc_att_imx8mq),
> +};
> +
> static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
> .src_reg = IMX7D_SRC_SCR,
> .src_mask = IMX7D_M4_RST_MASK,
> @@ -496,6 +533,8 @@ static int imx_rproc_remove(struct platform_device *pdev)
> static const struct of_device_id imx_rproc_of_match[] = {
> { .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
> { .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
> + { .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
> + { .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
I don't see a patch that adds those to the imx-rproc.txt bindings document. As far
as I can tell the patch that does that was part of your first patchset [1] but
was not resubmitted after that.
It would be very nice to have an example of how the DT is laid out for those 2
platform, otherwise I have to guess based on the code I am reviewing.
[1]. https://patchwork.kernel.org/project/linux-remoteproc/patch/20200724080813.24884-2-peng.fan@nxp.com/
> {},
> };
> MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 6/8] remoteproc: imx_rproc: support i.MX8MQ/M
@ 2021-01-11 21:40 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 21:40 UTC (permalink / raw)
To: peng.fan
Cc: ohad, Richard Zhu, patrice.chotard, festevam, s.hauer,
linux-remoteproc, linux-kernel, bjorn.andersson, paul, o.rempel,
agross, linux-imx, kernel, matthias.bgg, shawnguo,
linux-arm-kernel
On Tue, Dec 29, 2020 at 11:30:17AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add i.MX8MQ dev/sys addr map and configuration data structure
> i.MX8MM share i.MX8MQ settings.
>
> Reviewed-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/imx_rproc.c | 39 ++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 3c0075dc1787..f80428afb8a7 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -88,6 +88,34 @@ struct imx_rproc {
> struct clk *clk;
> };
>
> +static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
> + /* dev addr , sys addr , size , flags */
> + /* TCML - alias */
> + { 0x00000000, 0x007e0000, 0x00020000, 0 },
> + /* OCRAM_S */
> + { 0x00180000, 0x00180000, 0x00008000, 0 },
> + /* OCRAM */
> + { 0x00900000, 0x00900000, 0x00020000, 0 },
> + /* OCRAM */
> + { 0x00920000, 0x00920000, 0x00020000, 0 },
> + /* QSPI Code - alias */
> + { 0x08000000, 0x08000000, 0x08000000, 0 },
> + /* DDR (Code) - alias */
> + { 0x10000000, 0x80000000, 0x0FFE0000, 0 },
> + /* TCML */
> + { 0x1FFE0000, 0x007E0000, 0x00020000, ATT_OWN },
> + /* TCMU */
> + { 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
> + /* OCRAM_S */
> + { 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
> + /* OCRAM */
> + { 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
> + /* OCRAM */
> + { 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
> + /* DDR (Data) */
> + { 0x40000000, 0x40000000, 0x80000000, 0 },
> +};
> +
> static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
> /* dev addr , sys addr , size , flags */
> /* OCRAM_S (M4 Boot code) - alias */
> @@ -138,6 +166,15 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = {
> { 0x80000000, 0x80000000, 0x60000000, 0 },
> };
>
> +static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
> + .src_reg = IMX7D_SRC_SCR,
> + .src_mask = IMX7D_M4_RST_MASK,
> + .src_start = IMX7D_M4_START,
> + .src_stop = IMX7D_M4_STOP,
> + .att = imx_rproc_att_imx8mq,
> + .att_size = ARRAY_SIZE(imx_rproc_att_imx8mq),
> +};
> +
> static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
> .src_reg = IMX7D_SRC_SCR,
> .src_mask = IMX7D_M4_RST_MASK,
> @@ -496,6 +533,8 @@ static int imx_rproc_remove(struct platform_device *pdev)
> static const struct of_device_id imx_rproc_of_match[] = {
> { .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
> { .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
> + { .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
> + { .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
I don't see a patch that adds those to the imx-rproc.txt bindings document. As far
as I can tell the patch that does that was part of your first patchset [1] but
was not resubmitted after that.
It would be very nice to have an example of how the DT is laid out for those 2
platform, otherwise I have to guess based on the code I am reviewing.
[1]. https://patchwork.kernel.org/project/linux-remoteproc/patch/20200724080813.24884-2-peng.fan@nxp.com/
> {},
> };
> MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
> --
> 2.28.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2020-12-29 3:30 ` peng.fan
@ 2021-01-11 21:50 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 21:50 UTC (permalink / raw)
To: peng.fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> They are handled by remoteproc common code, no need to map in imx
> rproc driver.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index f80428afb8a7..e62a53ee128e 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> struct resource res;
>
> node = of_parse_phandle(np, "memory-region", a);
> + /* Not map vdev region */
> + if (!strcmp(node->name, "vdev"))
> + continue;
I am very confused and because I don't see an example for the DT in the
bindings document I have to guess what is going on.
So I am guessing that you have laid out the memory regions for the vrings
and the vdev0buffer in the DT "memory-region".
For the vrings I don't see the allocation of a carveout, which means that you
will take the memory out of the DMA pool and the reserve memory will be wasted.
For the vdev0buffer, what you have will work *only* if that entry is the
first one in the list of memory regions, as we agreed here [2].
[1]. https://elixir.bootlin.com/linux/v5.11-rc3/source/drivers/remoteproc/remoteproc_core.c#L321
[2]. https://patchwork.kernel.org/project/linux-remoteproc/patch/20200722131543.7024-1-peng.fan@nxp.com/
> err = of_address_to_resource(node, 0, &res);
> if (err) {
> dev_err(dev, "unable to resolve memory region\n");
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2021-01-11 21:50 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-11 21:50 UTC (permalink / raw)
To: peng.fan
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross, linux-imx,
kernel, matthias.bgg, shawnguo, linux-arm-kernel
On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> They are handled by remoteproc common code, no need to map in imx
> rproc driver.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index f80428afb8a7..e62a53ee128e 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> struct resource res;
>
> node = of_parse_phandle(np, "memory-region", a);
> + /* Not map vdev region */
> + if (!strcmp(node->name, "vdev"))
> + continue;
I am very confused and because I don't see an example for the DT in the
bindings document I have to guess what is going on.
So I am guessing that you have laid out the memory regions for the vrings
and the vdev0buffer in the DT "memory-region".
For the vrings I don't see the allocation of a carveout, which means that you
will take the memory out of the DMA pool and the reserve memory will be wasted.
For the vdev0buffer, what you have will work *only* if that entry is the
first one in the list of memory regions, as we agreed here [2].
[1]. https://elixir.bootlin.com/linux/v5.11-rc3/source/drivers/remoteproc/remoteproc_core.c#L321
[2]. https://patchwork.kernel.org/project/linux-remoteproc/patch/20200722131543.7024-1-peng.fan@nxp.com/
> err = of_address_to_resource(node, 0, &res);
> if (err) {
> dev_err(dev, "unable to resolve memory region\n");
> --
> 2.28.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2021-01-11 21:50 ` Mathieu Poirier
@ 2021-01-12 9:41 ` Peng Fan
-1 siblings, 0 replies; 50+ messages in thread
From: Peng Fan @ 2021-01-12 9:41 UTC (permalink / raw)
To: Mathieu Poirier
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, dl-linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
> Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> regions
>
> On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > They are handled by remoteproc common code, no need to map in imx
> > rproc driver.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/remoteproc/imx_rproc.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/remoteproc/imx_rproc.c
> > b/drivers/remoteproc/imx_rproc.c index f80428afb8a7..e62a53ee128e
> > 100644
> > --- a/drivers/remoteproc/imx_rproc.c
> > +++ b/drivers/remoteproc/imx_rproc.c
> > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc
> *priv,
> > struct resource res;
> >
> > node = of_parse_phandle(np, "memory-region", a);
> > + /* Not map vdev region */
> > + if (!strcmp(node->name, "vdev"))
> > + continue;
>
> I am very confused and because I don't see an example for the DT in the
> bindings document I have to guess what is going on.
V6 will include the DT yaml.
>
> So I am guessing that you have laid out the memory regions for the vrings and
> the vdev0buffer in the DT "memory-region".
The dts part will be similar as following:
+ #include <dt-bindings/clock/imx8mm-clock.h>
+ rsc_table: rsc_table@550ff000 {
+ no-map;
+ reg = <0x550ff000 0x1000>;
+ };
+
+ vdev0vring0: vdev0vring0@55000000 {
+ no-map;
+ reg = <0x55000000 0x8000>;
+ };
+
+ vdev0vring1: vdev0vring1@55008000 {
+ reg = <0x55008000 0x8000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@55400000 {
+ compatible = "shared-dma-pool";
+ reg = <0x55400000 0x100000>;
+ no-map;
+ };
+
+ imx8mm-cm4 {
+ compatible = "fsl,imx8mm-cm4";
+ clocks = <&clk IMX8MM_CLK_M4_DIV>;
+ mbox-names = "tx", "rx", "rxdb";
+ mboxes = <&mu 0 1
+ &mu 1 1
+ &mu 3 1>;
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
+ syscon = <&src>;
+ };
>
> For the vrings I don't see the allocation of a carveout, which means that you
> will take the memory out of the DMA pool and the reserve memory will be
> wasted.
imx_rproc_parse_memory_regions will alloc carveout.
>
> For the vdev0buffer, what you have will work *only* if that entry is the first
> one in the list of memory regions, as we agreed here [2].
Yes. I agree and follow this rule from then.
Thanks,
Peng.
>
> [1].
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
> ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZm66b4
> m20%3D&reserved=0
> [2].
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> FHjwA6a8x58geY7eE%3D&reserved=0
>
> > err = of_address_to_resource(node, 0, &res);
> > if (err) {
> > dev_err(dev, "unable to resolve memory region\n");
> > --
> > 2.28.0
> >
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2021-01-12 9:41 ` Peng Fan
0 siblings, 0 replies; 50+ messages in thread
From: Peng Fan @ 2021-01-12 9:41 UTC (permalink / raw)
To: Mathieu Poirier
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross,
dl-linux-imx, kernel, matthias.bgg, shawnguo, linux-arm-kernel
> Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> regions
>
> On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > They are handled by remoteproc common code, no need to map in imx
> > rproc driver.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/remoteproc/imx_rproc.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/remoteproc/imx_rproc.c
> > b/drivers/remoteproc/imx_rproc.c index f80428afb8a7..e62a53ee128e
> > 100644
> > --- a/drivers/remoteproc/imx_rproc.c
> > +++ b/drivers/remoteproc/imx_rproc.c
> > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc
> *priv,
> > struct resource res;
> >
> > node = of_parse_phandle(np, "memory-region", a);
> > + /* Not map vdev region */
> > + if (!strcmp(node->name, "vdev"))
> > + continue;
>
> I am very confused and because I don't see an example for the DT in the
> bindings document I have to guess what is going on.
V6 will include the DT yaml.
>
> So I am guessing that you have laid out the memory regions for the vrings and
> the vdev0buffer in the DT "memory-region".
The dts part will be similar as following:
+ #include <dt-bindings/clock/imx8mm-clock.h>
+ rsc_table: rsc_table@550ff000 {
+ no-map;
+ reg = <0x550ff000 0x1000>;
+ };
+
+ vdev0vring0: vdev0vring0@55000000 {
+ no-map;
+ reg = <0x55000000 0x8000>;
+ };
+
+ vdev0vring1: vdev0vring1@55008000 {
+ reg = <0x55008000 0x8000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@55400000 {
+ compatible = "shared-dma-pool";
+ reg = <0x55400000 0x100000>;
+ no-map;
+ };
+
+ imx8mm-cm4 {
+ compatible = "fsl,imx8mm-cm4";
+ clocks = <&clk IMX8MM_CLK_M4_DIV>;
+ mbox-names = "tx", "rx", "rxdb";
+ mboxes = <&mu 0 1
+ &mu 1 1
+ &mu 3 1>;
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
+ syscon = <&src>;
+ };
>
> For the vrings I don't see the allocation of a carveout, which means that you
> will take the memory out of the DMA pool and the reserve memory will be
> wasted.
imx_rproc_parse_memory_regions will alloc carveout.
>
> For the vdev0buffer, what you have will work *only* if that entry is the first
> one in the list of memory regions, as we agreed here [2].
Yes. I agree and follow this rule from then.
Thanks,
Peng.
>
> [1].
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
> ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZm66b4
> m20%3D&reserved=0
> [2].
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> FHjwA6a8x58geY7eE%3D&reserved=0
>
> > err = of_address_to_resource(node, 0, &res);
> > if (err) {
> > dev_err(dev, "unable to resolve memory region\n");
> > --
> > 2.28.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2021-01-12 9:41 ` Peng Fan
@ 2021-01-12 18:46 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-12 18:46 UTC (permalink / raw)
To: Peng Fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, dl-linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > They are handled by remoteproc common code, no need to map in imx
> > > rproc driver.
> > >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > b/drivers/remoteproc/imx_rproc.c index f80428afb8a7..e62a53ee128e
> > > 100644
> > > --- a/drivers/remoteproc/imx_rproc.c
> > > +++ b/drivers/remoteproc/imx_rproc.c
> > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc
> > *priv,
> > > struct resource res;
> > >
> > > node = of_parse_phandle(np, "memory-region", a);
> > > + /* Not map vdev region */
> > > + if (!strcmp(node->name, "vdev"))
> > > + continue;
> >
> > I am very confused and because I don't see an example for the DT in the
> > bindings document I have to guess what is going on.
>
> V6 will include the DT yaml.
>
> >
> > So I am guessing that you have laid out the memory regions for the vrings and
> > the vdev0buffer in the DT "memory-region".
>
> The dts part will be similar as following:
>
> + #include <dt-bindings/clock/imx8mm-clock.h>
> + rsc_table: rsc_table@550ff000 {
> + no-map;
> + reg = <0x550ff000 0x1000>;
> + };
> +
> + vdev0vring0: vdev0vring0@55000000 {
> + no-map;
> + reg = <0x55000000 0x8000>;
> + };
> +
> + vdev0vring1: vdev0vring1@55008000 {
> + reg = <0x55008000 0x8000>;
> + no-map;
> + };
> +
> + vdevbuffer: vdevbuffer@55400000 {
> + compatible = "shared-dma-pool";
> + reg = <0x55400000 0x100000>;
> + no-map;
> + };
> +
> + imx8mm-cm4 {
> + compatible = "fsl,imx8mm-cm4";
> + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> + mbox-names = "tx", "rx", "rxdb";
> + mboxes = <&mu 0 1
> + &mu 1 1
> + &mu 3 1>;
> + memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
> + syscon = <&src>;
> + };
>
> >
> > For the vrings I don't see the allocation of a carveout, which means that you
> > will take the memory out of the DMA pool and the reserve memory will be
> > wasted.
>
> imx_rproc_parse_memory_regions will alloc carveout.
They _will_ but for now they don't and as such there a discrepancy between the
bindings and the code that was published in V6. At this point you can either
drop the vrings in the DT or send another revision with the carveouts
allocated. I would definitely prefer the latter because it wouldn't involve yet
another modification of the bindings.
>
> >
> > For the vdev0buffer, what you have will work *only* if that entry is the first
> > one in the list of memory regions, as we agreed here [2].
>
> Yes. I agree and follow this rule from then.
>
> Thanks,
> Peng.
>
> >
> > [1].
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
> > ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZm66b4
> > m20%3D&reserved=0
> > [2].
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > FHjwA6a8x58geY7eE%3D&reserved=0
> >
> > > err = of_address_to_resource(node, 0, &res);
> > > if (err) {
> > > dev_err(dev, "unable to resolve memory region\n");
> > > --
> > > 2.28.0
> > >
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2021-01-12 18:46 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-12 18:46 UTC (permalink / raw)
To: Peng Fan
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross,
dl-linux-imx, kernel, matthias.bgg, shawnguo, linux-arm-kernel
On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > They are handled by remoteproc common code, no need to map in imx
> > > rproc driver.
> > >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > b/drivers/remoteproc/imx_rproc.c index f80428afb8a7..e62a53ee128e
> > > 100644
> > > --- a/drivers/remoteproc/imx_rproc.c
> > > +++ b/drivers/remoteproc/imx_rproc.c
> > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc
> > *priv,
> > > struct resource res;
> > >
> > > node = of_parse_phandle(np, "memory-region", a);
> > > + /* Not map vdev region */
> > > + if (!strcmp(node->name, "vdev"))
> > > + continue;
> >
> > I am very confused and because I don't see an example for the DT in the
> > bindings document I have to guess what is going on.
>
> V6 will include the DT yaml.
>
> >
> > So I am guessing that you have laid out the memory regions for the vrings and
> > the vdev0buffer in the DT "memory-region".
>
> The dts part will be similar as following:
>
> + #include <dt-bindings/clock/imx8mm-clock.h>
> + rsc_table: rsc_table@550ff000 {
> + no-map;
> + reg = <0x550ff000 0x1000>;
> + };
> +
> + vdev0vring0: vdev0vring0@55000000 {
> + no-map;
> + reg = <0x55000000 0x8000>;
> + };
> +
> + vdev0vring1: vdev0vring1@55008000 {
> + reg = <0x55008000 0x8000>;
> + no-map;
> + };
> +
> + vdevbuffer: vdevbuffer@55400000 {
> + compatible = "shared-dma-pool";
> + reg = <0x55400000 0x100000>;
> + no-map;
> + };
> +
> + imx8mm-cm4 {
> + compatible = "fsl,imx8mm-cm4";
> + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> + mbox-names = "tx", "rx", "rxdb";
> + mboxes = <&mu 0 1
> + &mu 1 1
> + &mu 3 1>;
> + memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
> + syscon = <&src>;
> + };
>
> >
> > For the vrings I don't see the allocation of a carveout, which means that you
> > will take the memory out of the DMA pool and the reserve memory will be
> > wasted.
>
> imx_rproc_parse_memory_regions will alloc carveout.
They _will_ but for now they don't and as such there a discrepancy between the
bindings and the code that was published in V6. At this point you can either
drop the vrings in the DT or send another revision with the carveouts
allocated. I would definitely prefer the latter because it wouldn't involve yet
another modification of the bindings.
>
> >
> > For the vdev0buffer, what you have will work *only* if that entry is the first
> > one in the list of memory regions, as we agreed here [2].
>
> Yes. I agree and follow this rule from then.
>
> Thanks,
> Peng.
>
> >
> > [1].
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
> > ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZm66b4
> > m20%3D&reserved=0
> > [2].
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > FHjwA6a8x58geY7eE%3D&reserved=0
> >
> > > err = of_address_to_resource(node, 0, &res);
> > > if (err) {
> > > dev_err(dev, "unable to resolve memory region\n");
> > > --
> > > 2.28.0
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2021-01-12 18:46 ` Mathieu Poirier
@ 2021-01-13 2:19 ` Peng Fan
-1 siblings, 0 replies; 50+ messages in thread
From: Peng Fan @ 2021-01-13 2:19 UTC (permalink / raw)
To: Mathieu Poirier
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, dl-linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
> Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> regions
>
> On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > vdev regions
> > >
> > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > They are handled by remoteproc common code, no need to map in imx
> > > > rproc driver.
> > > >
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > b/drivers/remoteproc/imx_rproc.c index f80428afb8a7..e62a53ee128e
> > > > 100644
> > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > imx_rproc
> > > *priv,
> > > > struct resource res;
> > > >
> > > > node = of_parse_phandle(np, "memory-region", a);
> > > > + /* Not map vdev region */
> > > > + if (!strcmp(node->name, "vdev"))
> > > > + continue;
> > >
> > > I am very confused and because I don't see an example for the DT in
> > > the bindings document I have to guess what is going on.
> >
> > V6 will include the DT yaml.
> >
> > >
> > > So I am guessing that you have laid out the memory regions for the
> > > vrings and the vdev0buffer in the DT "memory-region".
> >
> > The dts part will be similar as following:
> >
> > + #include <dt-bindings/clock/imx8mm-clock.h>
> > + rsc_table: rsc_table@550ff000 {
> > + no-map;
> > + reg = <0x550ff000 0x1000>;
> > + };
> > +
> > + vdev0vring0: vdev0vring0@55000000 {
> > + no-map;
> > + reg = <0x55000000 0x8000>;
> > + };
> > +
> > + vdev0vring1: vdev0vring1@55008000 {
> > + reg = <0x55008000 0x8000>;
> > + no-map;
> > + };
> > +
> > + vdevbuffer: vdevbuffer@55400000 {
> > + compatible = "shared-dma-pool";
> > + reg = <0x55400000 0x100000>;
> > + no-map;
> > + };
> > +
> > + imx8mm-cm4 {
> > + compatible = "fsl,imx8mm-cm4";
> > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > + mbox-names = "tx", "rx", "rxdb";
> > + mboxes = <&mu 0 1
> > + &mu 1 1
> > + &mu 3 1>;
> > + memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
> <&rsc_table>;
> > + syscon = <&src>;
> > + };
> >
> > >
> > > For the vrings I don't see the allocation of a carveout, which means
> > > that you will take the memory out of the DMA pool and the reserve
> > > memory will be wasted.
> >
> > imx_rproc_parse_memory_regions will alloc carveout.
>
> They _will_ but for now they don't and as such there a discrepancy between
> the bindings and the code that was published in V6. At this point you can
> either drop the vrings in the DT or send another revision with the carveouts
> allocated. I would definitely prefer the latter because it wouldn't involve yet
> another modification of the bindings.
You mean I drop patch v5 7/8 and send v7, right?
Or are there other changes that I need to do?
Thanks,
Peng.
>
> >
> > >
> > > For the vdev0buffer, what you have will work *only* if that entry is
> > > the first one in the list of memory regions, as we agreed here [2].
> >
> > Yes. I agree and follow this rule from then.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > [1].
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
> > > ixir.b
> > >
> ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > >
> moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > >
> C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > >
> 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZm66
> b4
> > > m20%3D&reserved=0
> > > [2].
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> > > tch
> > >
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > >
> 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > >
> xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > >
> 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > >
> VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > FHjwA6a8x58geY7eE%3D&reserved=0
> > >
> > > > err = of_address_to_resource(node, 0, &res);
> > > > if (err) {
> > > > dev_err(dev, "unable to resolve memory region\n");
> > > > --
> > > > 2.28.0
> > > >
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2021-01-13 2:19 ` Peng Fan
0 siblings, 0 replies; 50+ messages in thread
From: Peng Fan @ 2021-01-13 2:19 UTC (permalink / raw)
To: Mathieu Poirier
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross,
dl-linux-imx, kernel, matthias.bgg, shawnguo, linux-arm-kernel
> Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> regions
>
> On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > vdev regions
> > >
> > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > They are handled by remoteproc common code, no need to map in imx
> > > > rproc driver.
> > > >
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > b/drivers/remoteproc/imx_rproc.c index f80428afb8a7..e62a53ee128e
> > > > 100644
> > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > imx_rproc
> > > *priv,
> > > > struct resource res;
> > > >
> > > > node = of_parse_phandle(np, "memory-region", a);
> > > > + /* Not map vdev region */
> > > > + if (!strcmp(node->name, "vdev"))
> > > > + continue;
> > >
> > > I am very confused and because I don't see an example for the DT in
> > > the bindings document I have to guess what is going on.
> >
> > V6 will include the DT yaml.
> >
> > >
> > > So I am guessing that you have laid out the memory regions for the
> > > vrings and the vdev0buffer in the DT "memory-region".
> >
> > The dts part will be similar as following:
> >
> > + #include <dt-bindings/clock/imx8mm-clock.h>
> > + rsc_table: rsc_table@550ff000 {
> > + no-map;
> > + reg = <0x550ff000 0x1000>;
> > + };
> > +
> > + vdev0vring0: vdev0vring0@55000000 {
> > + no-map;
> > + reg = <0x55000000 0x8000>;
> > + };
> > +
> > + vdev0vring1: vdev0vring1@55008000 {
> > + reg = <0x55008000 0x8000>;
> > + no-map;
> > + };
> > +
> > + vdevbuffer: vdevbuffer@55400000 {
> > + compatible = "shared-dma-pool";
> > + reg = <0x55400000 0x100000>;
> > + no-map;
> > + };
> > +
> > + imx8mm-cm4 {
> > + compatible = "fsl,imx8mm-cm4";
> > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > + mbox-names = "tx", "rx", "rxdb";
> > + mboxes = <&mu 0 1
> > + &mu 1 1
> > + &mu 3 1>;
> > + memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
> <&rsc_table>;
> > + syscon = <&src>;
> > + };
> >
> > >
> > > For the vrings I don't see the allocation of a carveout, which means
> > > that you will take the memory out of the DMA pool and the reserve
> > > memory will be wasted.
> >
> > imx_rproc_parse_memory_regions will alloc carveout.
>
> They _will_ but for now they don't and as such there a discrepancy between
> the bindings and the code that was published in V6. At this point you can
> either drop the vrings in the DT or send another revision with the carveouts
> allocated. I would definitely prefer the latter because it wouldn't involve yet
> another modification of the bindings.
You mean I drop patch v5 7/8 and send v7, right?
Or are there other changes that I need to do?
Thanks,
Peng.
>
> >
> > >
> > > For the vdev0buffer, what you have will work *only* if that entry is
> > > the first one in the list of memory regions, as we agreed here [2].
> >
> > Yes. I agree and follow this rule from then.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > [1].
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
> > > ixir.b
> > >
> ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > >
> moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > >
> C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > >
> 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZm66
> b4
> > > m20%3D&reserved=0
> > > [2].
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> > > tch
> > >
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > >
> 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > >
> xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > >
> 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > >
> VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > FHjwA6a8x58geY7eE%3D&reserved=0
> > >
> > > > err = of_address_to_resource(node, 0, &res);
> > > > if (err) {
> > > > dev_err(dev, "unable to resolve memory region\n");
> > > > --
> > > > 2.28.0
> > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2021-01-13 2:19 ` Peng Fan
@ 2021-01-13 16:17 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-13 16:17 UTC (permalink / raw)
To: Peng Fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, dl-linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
On Wed, Jan 13, 2021 at 02:19:32AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > > vdev regions
> > > >
> > > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > >
> > > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > > They are handled by remoteproc common code, no need to map in imx
> > > > > rproc driver.
> > > > >
> > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > ---
> > > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > b/drivers/remoteproc/imx_rproc.c index f80428afb8a7..e62a53ee128e
> > > > > 100644
> > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > > imx_rproc
> > > > *priv,
> > > > > struct resource res;
> > > > >
> > > > > node = of_parse_phandle(np, "memory-region", a);
> > > > > + /* Not map vdev region */
> > > > > + if (!strcmp(node->name, "vdev"))
> > > > > + continue;
> > > >
> > > > I am very confused and because I don't see an example for the DT in
> > > > the bindings document I have to guess what is going on.
> > >
> > > V6 will include the DT yaml.
> > >
> > > >
> > > > So I am guessing that you have laid out the memory regions for the
> > > > vrings and the vdev0buffer in the DT "memory-region".
> > >
> > > The dts part will be similar as following:
> > >
> > > + #include <dt-bindings/clock/imx8mm-clock.h>
> > > + rsc_table: rsc_table@550ff000 {
> > > + no-map;
> > > + reg = <0x550ff000 0x1000>;
> > > + };
> > > +
> > > + vdev0vring0: vdev0vring0@55000000 {
> > > + no-map;
> > > + reg = <0x55000000 0x8000>;
> > > + };
> > > +
> > > + vdev0vring1: vdev0vring1@55008000 {
> > > + reg = <0x55008000 0x8000>;
> > > + no-map;
> > > + };
> > > +
> > > + vdevbuffer: vdevbuffer@55400000 {
> > > + compatible = "shared-dma-pool";
> > > + reg = <0x55400000 0x100000>;
> > > + no-map;
> > > + };
> > > +
> > > + imx8mm-cm4 {
> > > + compatible = "fsl,imx8mm-cm4";
> > > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > > + mbox-names = "tx", "rx", "rxdb";
> > > + mboxes = <&mu 0 1
> > > + &mu 1 1
> > > + &mu 3 1>;
> > > + memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
> > <&rsc_table>;
> > > + syscon = <&src>;
> > > + };
> > >
> > > >
> > > > For the vrings I don't see the allocation of a carveout, which means
> > > > that you will take the memory out of the DMA pool and the reserve
> > > > memory will be wasted.
> > >
> > > imx_rproc_parse_memory_regions will alloc carveout.
> >
> > They _will_ but for now they don't and as such there a discrepancy between
> > the bindings and the code that was published in V6. At this point you can
> > either drop the vrings in the DT or send another revision with the carveouts
> > allocated. I would definitely prefer the latter because it wouldn't involve yet
> > another modification of the bindings.
>
> You mean I drop patch v5 7/8 and send v7, right?
>
If you do that than the implementation won't reflect the bindings.
> Or are there other changes that I need to do?
If you want to keep the bindings the same way you have them in V6, carveouts are
required in the implementation.
>
> Thanks,
> Peng.
>
> >
> > >
> > > >
> > > > For the vdev0buffer, what you have will work *only* if that entry is
> > > > the first one in the list of memory regions, as we agreed here [2].
> > >
> > > Yes. I agree and follow this rule from then.
> > >
> > > Thanks,
> > > Peng.
> > >
> > > >
> > > > [1].
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
> > > > ixir.b
> > > >
> > ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > > >
> > moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > > >
> > C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > > >
> > 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > > >
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZm66
> > b4
> > > > m20%3D&reserved=0
> > > > [2].
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> > > > tch
> > > >
> > work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > > >
> > 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > > >
> > xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > > >
> > 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > > >
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > >
> > VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > > FHjwA6a8x58geY7eE%3D&reserved=0
> > > >
> > > > > err = of_address_to_resource(node, 0, &res);
> > > > > if (err) {
> > > > > dev_err(dev, "unable to resolve memory region\n");
> > > > > --
> > > > > 2.28.0
> > > > >
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2021-01-13 16:17 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-13 16:17 UTC (permalink / raw)
To: Peng Fan
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross,
dl-linux-imx, kernel, matthias.bgg, shawnguo, linux-arm-kernel
On Wed, Jan 13, 2021 at 02:19:32AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > > vdev regions
> > > >
> > > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com wrote:
> > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > >
> > > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > > They are handled by remoteproc common code, no need to map in imx
> > > > > rproc driver.
> > > > >
> > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > ---
> > > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > b/drivers/remoteproc/imx_rproc.c index f80428afb8a7..e62a53ee128e
> > > > > 100644
> > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > > imx_rproc
> > > > *priv,
> > > > > struct resource res;
> > > > >
> > > > > node = of_parse_phandle(np, "memory-region", a);
> > > > > + /* Not map vdev region */
> > > > > + if (!strcmp(node->name, "vdev"))
> > > > > + continue;
> > > >
> > > > I am very confused and because I don't see an example for the DT in
> > > > the bindings document I have to guess what is going on.
> > >
> > > V6 will include the DT yaml.
> > >
> > > >
> > > > So I am guessing that you have laid out the memory regions for the
> > > > vrings and the vdev0buffer in the DT "memory-region".
> > >
> > > The dts part will be similar as following:
> > >
> > > + #include <dt-bindings/clock/imx8mm-clock.h>
> > > + rsc_table: rsc_table@550ff000 {
> > > + no-map;
> > > + reg = <0x550ff000 0x1000>;
> > > + };
> > > +
> > > + vdev0vring0: vdev0vring0@55000000 {
> > > + no-map;
> > > + reg = <0x55000000 0x8000>;
> > > + };
> > > +
> > > + vdev0vring1: vdev0vring1@55008000 {
> > > + reg = <0x55008000 0x8000>;
> > > + no-map;
> > > + };
> > > +
> > > + vdevbuffer: vdevbuffer@55400000 {
> > > + compatible = "shared-dma-pool";
> > > + reg = <0x55400000 0x100000>;
> > > + no-map;
> > > + };
> > > +
> > > + imx8mm-cm4 {
> > > + compatible = "fsl,imx8mm-cm4";
> > > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > > + mbox-names = "tx", "rx", "rxdb";
> > > + mboxes = <&mu 0 1
> > > + &mu 1 1
> > > + &mu 3 1>;
> > > + memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
> > <&rsc_table>;
> > > + syscon = <&src>;
> > > + };
> > >
> > > >
> > > > For the vrings I don't see the allocation of a carveout, which means
> > > > that you will take the memory out of the DMA pool and the reserve
> > > > memory will be wasted.
> > >
> > > imx_rproc_parse_memory_regions will alloc carveout.
> >
> > They _will_ but for now they don't and as such there a discrepancy between
> > the bindings and the code that was published in V6. At this point you can
> > either drop the vrings in the DT or send another revision with the carveouts
> > allocated. I would definitely prefer the latter because it wouldn't involve yet
> > another modification of the bindings.
>
> You mean I drop patch v5 7/8 and send v7, right?
>
If you do that than the implementation won't reflect the bindings.
> Or are there other changes that I need to do?
If you want to keep the bindings the same way you have them in V6, carveouts are
required in the implementation.
>
> Thanks,
> Peng.
>
> >
> > >
> > > >
> > > > For the vdev0buffer, what you have will work *only* if that entry is
> > > > the first one in the list of memory regions, as we agreed here [2].
> > >
> > > Yes. I agree and follow this rule from then.
> > >
> > > Thanks,
> > > Peng.
> > >
> > > >
> > > > [1].
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
> > > > ixir.b
> > > >
> > ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > > >
> > moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > > >
> > C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > > >
> > 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > > >
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZm66
> > b4
> > > > m20%3D&reserved=0
> > > > [2].
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> > > > tch
> > > >
> > work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > > >
> > 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > > >
> > xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > > >
> > 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > > >
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > >
> > VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > > FHjwA6a8x58geY7eE%3D&reserved=0
> > > >
> > > > > err = of_address_to_resource(node, 0, &res);
> > > > > if (err) {
> > > > > dev_err(dev, "unable to resolve memory region\n");
> > > > > --
> > > > > 2.28.0
> > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2021-01-13 16:17 ` Mathieu Poirier
@ 2021-01-14 9:52 ` Peng Fan
-1 siblings, 0 replies; 50+ messages in thread
From: Peng Fan @ 2021-01-14 9:52 UTC (permalink / raw)
To: Mathieu Poirier
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, dl-linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
> Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> regions
>
> On Wed, Jan 13, 2021 at 02:19:32AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > vdev regions
> > >
> > > On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore
> > > > > mapping vdev regions
> > > > >
> > > > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com
> wrote:
> > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > >
> > > > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > > > They are handled by remoteproc common code, no need to map in
> > > > > > imx rproc driver.
> > > > > >
> > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > > ---
> > > > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > > > 1 file changed, 3 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > > b/drivers/remoteproc/imx_rproc.c index
> > > > > > f80428afb8a7..e62a53ee128e
> > > > > > 100644
> > > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > > > imx_rproc
> > > > > *priv,
> > > > > > struct resource res;
> > > > > >
> > > > > > node = of_parse_phandle(np, "memory-region", a);
> > > > > > + /* Not map vdev region */
> > > > > > + if (!strcmp(node->name, "vdev"))
> > > > > > + continue;
> > > > >
> > > > > I am very confused and because I don't see an example for the DT
> > > > > in the bindings document I have to guess what is going on.
> > > >
> > > > V6 will include the DT yaml.
> > > >
> > > > >
> > > > > So I am guessing that you have laid out the memory regions for
> > > > > the vrings and the vdev0buffer in the DT "memory-region".
> > > >
> > > > The dts part will be similar as following:
> > > >
> > > > + #include <dt-bindings/clock/imx8mm-clock.h>
> > > > + rsc_table: rsc_table@550ff000 {
> > > > + no-map;
> > > > + reg = <0x550ff000 0x1000>;
> > > > + };
> > > > +
> > > > + vdev0vring0: vdev0vring0@55000000 {
> > > > + no-map;
> > > > + reg = <0x55000000 0x8000>;
> > > > + };
> > > > +
> > > > + vdev0vring1: vdev0vring1@55008000 {
> > > > + reg = <0x55008000 0x8000>;
> > > > + no-map;
> > > > + };
> > > > +
> > > > + vdevbuffer: vdevbuffer@55400000 {
> > > > + compatible = "shared-dma-pool";
> > > > + reg = <0x55400000 0x100000>;
> > > > + no-map;
> > > > + };
> > > > +
> > > > + imx8mm-cm4 {
> > > > + compatible = "fsl,imx8mm-cm4";
> > > > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > > > + mbox-names = "tx", "rx", "rxdb";
> > > > + mboxes = <&mu 0 1
> > > > + &mu 1 1
> > > > + &mu 3 1>;
> > > > + memory-region = <&vdevbuffer>, <&vdev0vring0>,
> > > > + <&vdev0vring1>,
> > > <&rsc_table>;
> > > > + syscon = <&src>;
> > > > + };
> > > >
> > > > >
> > > > > For the vrings I don't see the allocation of a carveout, which
> > > > > means that you will take the memory out of the DMA pool and the
> > > > > reserve memory will be wasted.
> > > >
> > > > imx_rproc_parse_memory_regions will alloc carveout.
> > >
> > > They _will_ but for now they don't and as such there a discrepancy
> > > between the bindings and the code that was published in V6. At this
> > > point you can either drop the vrings in the DT or send another
> > > revision with the carveouts allocated. I would definitely prefer
> > > the latter because it wouldn't involve yet another modification of the
> bindings.
> >
> > You mean I drop patch v5 7/8 and send v7, right?
> >
>
> If you do that than the implementation won't reflect the bindings.
>
> > Or are there other changes that I need to do?
>
> If you want to keep the bindings the same way you have them in V6,
> carveouts are required in the implementation.
ok. Could you share more info about carveouts are required?
imx_rproc_parse_memory_regions in my pachset already have
rproc_add_carveout. I am not clear what else needs to be done.
Thanks,
Peng.
>
> >
> > Thanks,
> > Peng.
> >
> > >
> > > >
> > > > >
> > > > > For the vdev0buffer, what you have will work *only* if that
> > > > > entry is the first one in the list of memory regions, as we agreed here
> [2].
> > > >
> > > > Yes. I agree and follow this rule from then.
> > > >
> > > > Thanks,
> > > > Peng.
> > > >
> > > > >
> > > > > [1].
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2Fel
> > > > > ixir.b
> > > > >
> > >
> ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > > > >
> > >
> moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > > > >
> > >
> C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > > > >
> > >
> 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > > > >
> > >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZ
> m66
> > > b4
> > > > > m20%3D&reserved=0
> > > > > [2].
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2Fpa
> > > > > tch
> > > > >
> > >
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > > > >
> > >
> 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > > > >
> > >
> xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > > > >
> > >
> 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > > > >
> > >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > >
> > >
> VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > > > FHjwA6a8x58geY7eE%3D&reserved=0
> > > > >
> > > > > > err = of_address_to_resource(node, 0, &res);
> > > > > > if (err) {
> > > > > > dev_err(dev, "unable to resolve memory region\n");
> > > > > > --
> > > > > > 2.28.0
> > > > > >
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2021-01-14 9:52 ` Peng Fan
0 siblings, 0 replies; 50+ messages in thread
From: Peng Fan @ 2021-01-14 9:52 UTC (permalink / raw)
To: Mathieu Poirier
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross,
dl-linux-imx, kernel, matthias.bgg, shawnguo, linux-arm-kernel
> Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> regions
>
> On Wed, Jan 13, 2021 at 02:19:32AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > vdev regions
> > >
> > > On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore
> > > > > mapping vdev regions
> > > > >
> > > > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com
> wrote:
> > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > >
> > > > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > > > They are handled by remoteproc common code, no need to map in
> > > > > > imx rproc driver.
> > > > > >
> > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > > ---
> > > > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > > > 1 file changed, 3 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > > b/drivers/remoteproc/imx_rproc.c index
> > > > > > f80428afb8a7..e62a53ee128e
> > > > > > 100644
> > > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > > > imx_rproc
> > > > > *priv,
> > > > > > struct resource res;
> > > > > >
> > > > > > node = of_parse_phandle(np, "memory-region", a);
> > > > > > + /* Not map vdev region */
> > > > > > + if (!strcmp(node->name, "vdev"))
> > > > > > + continue;
> > > > >
> > > > > I am very confused and because I don't see an example for the DT
> > > > > in the bindings document I have to guess what is going on.
> > > >
> > > > V6 will include the DT yaml.
> > > >
> > > > >
> > > > > So I am guessing that you have laid out the memory regions for
> > > > > the vrings and the vdev0buffer in the DT "memory-region".
> > > >
> > > > The dts part will be similar as following:
> > > >
> > > > + #include <dt-bindings/clock/imx8mm-clock.h>
> > > > + rsc_table: rsc_table@550ff000 {
> > > > + no-map;
> > > > + reg = <0x550ff000 0x1000>;
> > > > + };
> > > > +
> > > > + vdev0vring0: vdev0vring0@55000000 {
> > > > + no-map;
> > > > + reg = <0x55000000 0x8000>;
> > > > + };
> > > > +
> > > > + vdev0vring1: vdev0vring1@55008000 {
> > > > + reg = <0x55008000 0x8000>;
> > > > + no-map;
> > > > + };
> > > > +
> > > > + vdevbuffer: vdevbuffer@55400000 {
> > > > + compatible = "shared-dma-pool";
> > > > + reg = <0x55400000 0x100000>;
> > > > + no-map;
> > > > + };
> > > > +
> > > > + imx8mm-cm4 {
> > > > + compatible = "fsl,imx8mm-cm4";
> > > > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > > > + mbox-names = "tx", "rx", "rxdb";
> > > > + mboxes = <&mu 0 1
> > > > + &mu 1 1
> > > > + &mu 3 1>;
> > > > + memory-region = <&vdevbuffer>, <&vdev0vring0>,
> > > > + <&vdev0vring1>,
> > > <&rsc_table>;
> > > > + syscon = <&src>;
> > > > + };
> > > >
> > > > >
> > > > > For the vrings I don't see the allocation of a carveout, which
> > > > > means that you will take the memory out of the DMA pool and the
> > > > > reserve memory will be wasted.
> > > >
> > > > imx_rproc_parse_memory_regions will alloc carveout.
> > >
> > > They _will_ but for now they don't and as such there a discrepancy
> > > between the bindings and the code that was published in V6. At this
> > > point you can either drop the vrings in the DT or send another
> > > revision with the carveouts allocated. I would definitely prefer
> > > the latter because it wouldn't involve yet another modification of the
> bindings.
> >
> > You mean I drop patch v5 7/8 and send v7, right?
> >
>
> If you do that than the implementation won't reflect the bindings.
>
> > Or are there other changes that I need to do?
>
> If you want to keep the bindings the same way you have them in V6,
> carveouts are required in the implementation.
ok. Could you share more info about carveouts are required?
imx_rproc_parse_memory_regions in my pachset already have
rproc_add_carveout. I am not clear what else needs to be done.
Thanks,
Peng.
>
> >
> > Thanks,
> > Peng.
> >
> > >
> > > >
> > > > >
> > > > > For the vdev0buffer, what you have will work *only* if that
> > > > > entry is the first one in the list of memory regions, as we agreed here
> [2].
> > > >
> > > > Yes. I agree and follow this rule from then.
> > > >
> > > > Thanks,
> > > > Peng.
> > > >
> > > > >
> > > > > [1].
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2Fel
> > > > > ixir.b
> > > > >
> > >
> ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > > > >
> > >
> moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > > > >
> > >
> C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > > > >
> > >
> 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > > > >
> > >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZ
> m66
> > > b4
> > > > > m20%3D&reserved=0
> > > > > [2].
> > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2Fpa
> > > > > tch
> > > > >
> > >
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > > > >
> > >
> 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > > > >
> > >
> xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > > > >
> > >
> 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > > > >
> > >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > >
> > >
> VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > > > FHjwA6a8x58geY7eE%3D&reserved=0
> > > > >
> > > > > > err = of_address_to_resource(node, 0, &res);
> > > > > > if (err) {
> > > > > > dev_err(dev, "unable to resolve memory region\n");
> > > > > > --
> > > > > > 2.28.0
> > > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2021-01-14 9:52 ` Peng Fan
@ 2021-01-14 17:10 ` Mathieu Poirier
-1 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-14 17:10 UTC (permalink / raw)
To: Peng Fan
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, dl-linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
On Thu, Jan 14, 2021 at 09:52:13AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Wed, Jan 13, 2021 at 02:19:32AM +0000, Peng Fan wrote:
> > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > > vdev regions
> > > >
> > > > On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore
> > > > > > mapping vdev regions
> > > > > >
> > > > > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com
> > wrote:
> > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > >
> > > > > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > > > > They are handled by remoteproc common code, no need to map in
> > > > > > > imx rproc driver.
> > > > > > >
> > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > > > ---
> > > > > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > > > > 1 file changed, 3 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > > > b/drivers/remoteproc/imx_rproc.c index
> > > > > > > f80428afb8a7..e62a53ee128e
> > > > > > > 100644
> > > > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > > > > imx_rproc
> > > > > > *priv,
> > > > > > > struct resource res;
> > > > > > >
> > > > > > > node = of_parse_phandle(np, "memory-region", a);
> > > > > > > + /* Not map vdev region */
> > > > > > > + if (!strcmp(node->name, "vdev"))
> > > > > > > + continue;
> > > > > >
> > > > > > I am very confused and because I don't see an example for the DT
> > > > > > in the bindings document I have to guess what is going on.
> > > > >
> > > > > V6 will include the DT yaml.
> > > > >
> > > > > >
> > > > > > So I am guessing that you have laid out the memory regions for
> > > > > > the vrings and the vdev0buffer in the DT "memory-region".
> > > > >
> > > > > The dts part will be similar as following:
> > > > >
> > > > > + #include <dt-bindings/clock/imx8mm-clock.h>
> > > > > + rsc_table: rsc_table@550ff000 {
> > > > > + no-map;
> > > > > + reg = <0x550ff000 0x1000>;
> > > > > + };
> > > > > +
> > > > > + vdev0vring0: vdev0vring0@55000000 {
> > > > > + no-map;
> > > > > + reg = <0x55000000 0x8000>;
> > > > > + };
> > > > > +
> > > > > + vdev0vring1: vdev0vring1@55008000 {
> > > > > + reg = <0x55008000 0x8000>;
> > > > > + no-map;
> > > > > + };
> > > > > +
> > > > > + vdevbuffer: vdevbuffer@55400000 {
> > > > > + compatible = "shared-dma-pool";
> > > > > + reg = <0x55400000 0x100000>;
> > > > > + no-map;
> > > > > + };
> > > > > +
> > > > > + imx8mm-cm4 {
> > > > > + compatible = "fsl,imx8mm-cm4";
> > > > > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > > > > + mbox-names = "tx", "rx", "rxdb";
> > > > > + mboxes = <&mu 0 1
> > > > > + &mu 1 1
> > > > > + &mu 3 1>;
> > > > > + memory-region = <&vdevbuffer>, <&vdev0vring0>,
> > > > > + <&vdev0vring1>,
> > > > <&rsc_table>;
> > > > > + syscon = <&src>;
> > > > > + };
> > > > >
> > > > > >
> > > > > > For the vrings I don't see the allocation of a carveout, which
> > > > > > means that you will take the memory out of the DMA pool and the
> > > > > > reserve memory will be wasted.
> > > > >
> > > > > imx_rproc_parse_memory_regions will alloc carveout.
> > > >
> > > > They _will_ but for now they don't and as such there a discrepancy
> > > > between the bindings and the code that was published in V6. At this
> > > > point you can either drop the vrings in the DT or send another
> > > > revision with the carveouts allocated. I would definitely prefer
> > > > the latter because it wouldn't involve yet another modification of the
> > bindings.
> > >
> > > You mean I drop patch v5 7/8 and send v7, right?
> > >
> >
> > If you do that than the implementation won't reflect the bindings.
> >
> > > Or are there other changes that I need to do?
> >
> > If you want to keep the bindings the same way you have them in V6,
> > carveouts are required in the implementation.
>
> ok. Could you share more info about carveouts are required?
> imx_rproc_parse_memory_regions in my pachset already have
> rproc_add_carveout. I am not clear what else needs to be done.
Ah yes, I see now. In your answer above you wrote
"imx_rproc_parse_memory_regions will alloc carveout", which I interpreted as
"will do so in a future patchset".
I will review V6 - no need to change anything at this time.
>
> Thanks,
> Peng.
>
> >
> > >
> > > Thanks,
> > > Peng.
> > >
> > > >
> > > > >
> > > > > >
> > > > > > For the vdev0buffer, what you have will work *only* if that
> > > > > > entry is the first one in the list of memory regions, as we agreed here
> > [2].
> > > > >
> > > > > Yes. I agree and follow this rule from then.
> > > > >
> > > > > Thanks,
> > > > > Peng.
> > > > >
> > > > > >
> > > > > > [1].
> > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > > 2Fel
> > > > > > ixir.b
> > > > > >
> > > >
> > ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > > > > >
> > > >
> > moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > > > > >
> > > >
> > C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > > > > >
> > > >
> > 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > > > > >
> > > >
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > > > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZ
> > m66
> > > > b4
> > > > > > m20%3D&reserved=0
> > > > > > [2].
> > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > > 2Fpa
> > > > > > tch
> > > > > >
> > > >
> > work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > > > > >
> > > >
> > 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > > > > >
> > > >
> > xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > > > > >
> > > >
> > 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > > > > >
> > > >
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > > >
> > > >
> > VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > > > > FHjwA6a8x58geY7eE%3D&reserved=0
> > > > > >
> > > > > > > err = of_address_to_resource(node, 0, &res);
> > > > > > > if (err) {
> > > > > > > dev_err(dev, "unable to resolve memory region\n");
> > > > > > > --
> > > > > > > 2.28.0
> > > > > > >
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2021-01-14 17:10 ` Mathieu Poirier
0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2021-01-14 17:10 UTC (permalink / raw)
To: Peng Fan
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross,
dl-linux-imx, kernel, matthias.bgg, shawnguo, linux-arm-kernel
On Thu, Jan 14, 2021 at 09:52:13AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Wed, Jan 13, 2021 at 02:19:32AM +0000, Peng Fan wrote:
> > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > > vdev regions
> > > >
> > > > On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore
> > > > > > mapping vdev regions
> > > > > >
> > > > > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com
> > wrote:
> > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > >
> > > > > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > > > > They are handled by remoteproc common code, no need to map in
> > > > > > > imx rproc driver.
> > > > > > >
> > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > > > ---
> > > > > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > > > > 1 file changed, 3 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > > > b/drivers/remoteproc/imx_rproc.c index
> > > > > > > f80428afb8a7..e62a53ee128e
> > > > > > > 100644
> > > > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > > > > imx_rproc
> > > > > > *priv,
> > > > > > > struct resource res;
> > > > > > >
> > > > > > > node = of_parse_phandle(np, "memory-region", a);
> > > > > > > + /* Not map vdev region */
> > > > > > > + if (!strcmp(node->name, "vdev"))
> > > > > > > + continue;
> > > > > >
> > > > > > I am very confused and because I don't see an example for the DT
> > > > > > in the bindings document I have to guess what is going on.
> > > > >
> > > > > V6 will include the DT yaml.
> > > > >
> > > > > >
> > > > > > So I am guessing that you have laid out the memory regions for
> > > > > > the vrings and the vdev0buffer in the DT "memory-region".
> > > > >
> > > > > The dts part will be similar as following:
> > > > >
> > > > > + #include <dt-bindings/clock/imx8mm-clock.h>
> > > > > + rsc_table: rsc_table@550ff000 {
> > > > > + no-map;
> > > > > + reg = <0x550ff000 0x1000>;
> > > > > + };
> > > > > +
> > > > > + vdev0vring0: vdev0vring0@55000000 {
> > > > > + no-map;
> > > > > + reg = <0x55000000 0x8000>;
> > > > > + };
> > > > > +
> > > > > + vdev0vring1: vdev0vring1@55008000 {
> > > > > + reg = <0x55008000 0x8000>;
> > > > > + no-map;
> > > > > + };
> > > > > +
> > > > > + vdevbuffer: vdevbuffer@55400000 {
> > > > > + compatible = "shared-dma-pool";
> > > > > + reg = <0x55400000 0x100000>;
> > > > > + no-map;
> > > > > + };
> > > > > +
> > > > > + imx8mm-cm4 {
> > > > > + compatible = "fsl,imx8mm-cm4";
> > > > > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > > > > + mbox-names = "tx", "rx", "rxdb";
> > > > > + mboxes = <&mu 0 1
> > > > > + &mu 1 1
> > > > > + &mu 3 1>;
> > > > > + memory-region = <&vdevbuffer>, <&vdev0vring0>,
> > > > > + <&vdev0vring1>,
> > > > <&rsc_table>;
> > > > > + syscon = <&src>;
> > > > > + };
> > > > >
> > > > > >
> > > > > > For the vrings I don't see the allocation of a carveout, which
> > > > > > means that you will take the memory out of the DMA pool and the
> > > > > > reserve memory will be wasted.
> > > > >
> > > > > imx_rproc_parse_memory_regions will alloc carveout.
> > > >
> > > > They _will_ but for now they don't and as such there a discrepancy
> > > > between the bindings and the code that was published in V6. At this
> > > > point you can either drop the vrings in the DT or send another
> > > > revision with the carveouts allocated. I would definitely prefer
> > > > the latter because it wouldn't involve yet another modification of the
> > bindings.
> > >
> > > You mean I drop patch v5 7/8 and send v7, right?
> > >
> >
> > If you do that than the implementation won't reflect the bindings.
> >
> > > Or are there other changes that I need to do?
> >
> > If you want to keep the bindings the same way you have them in V6,
> > carveouts are required in the implementation.
>
> ok. Could you share more info about carveouts are required?
> imx_rproc_parse_memory_regions in my pachset already have
> rproc_add_carveout. I am not clear what else needs to be done.
Ah yes, I see now. In your answer above you wrote
"imx_rproc_parse_memory_regions will alloc carveout", which I interpreted as
"will do so in a future patchset".
I will review V6 - no need to change anything at this time.
>
> Thanks,
> Peng.
>
> >
> > >
> > > Thanks,
> > > Peng.
> > >
> > > >
> > > > >
> > > > > >
> > > > > > For the vdev0buffer, what you have will work *only* if that
> > > > > > entry is the first one in the list of memory regions, as we agreed here
> > [2].
> > > > >
> > > > > Yes. I agree and follow this rule from then.
> > > > >
> > > > > Thanks,
> > > > > Peng.
> > > > >
> > > > > >
> > > > > > [1].
> > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > > 2Fel
> > > > > > ixir.b
> > > > > >
> > > >
> > ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > > > > >
> > > >
> > moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > > > > >
> > > >
> > C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > > > > >
> > > >
> > 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > > > > >
> > > >
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > > > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAItqZ
> > m66
> > > > b4
> > > > > > m20%3D&reserved=0
> > > > > > [2].
> > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > > 2Fpa
> > > > > > tch
> > > > > >
> > > >
> > work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > > > > >
> > > >
> > 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > > > > >
> > > >
> > xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > > > > >
> > > >
> > 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > > > > >
> > > >
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > > >
> > > >
> > VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > > > > FHjwA6a8x58geY7eE%3D&reserved=0
> > > > > >
> > > > > > > err = of_address_to_resource(node, 0, &res);
> > > > > > > if (err) {
> > > > > > > dev_err(dev, "unable to resolve memory region\n");
> > > > > > > --
> > > > > > > 2.28.0
> > > > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
2021-01-14 17:10 ` Mathieu Poirier
@ 2021-01-15 3:29 ` Peng Fan
-1 siblings, 0 replies; 50+ messages in thread
From: Peng Fan @ 2021-01-15 3:29 UTC (permalink / raw)
To: Mathieu Poirier
Cc: ohad, bjorn.andersson, o.rempel, shawnguo, s.hauer, kernel,
festevam, dl-linux-imx, linux-remoteproc, linux-arm-kernel,
linux-kernel, paul, matthias.bgg, agross, patrice.chotard
> Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> regions
>
> On Thu, Jan 14, 2021 at 09:52:13AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > vdev regions
> > >
> > > On Wed, Jan 13, 2021 at 02:19:32AM +0000, Peng Fan wrote:
> > > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore
> > > > > mapping vdev regions
> > > > >
> > > > > On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > > > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore
> > > > > > > mapping vdev regions
> > > > > > >
> > > > > > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com
> > > wrote:
> > > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > > >
> > > > > > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and
> similar.
> > > > > > > > They are handled by remoteproc common code, no need to map
> > > > > > > > in imx rproc driver.
> > > > > > > >
> > > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > > > > ---
> > > > > > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > > > > > 1 file changed, 3 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > > > > b/drivers/remoteproc/imx_rproc.c index
> > > > > > > > f80428afb8a7..e62a53ee128e
> > > > > > > > 100644
> > > > > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > > > > > imx_rproc
> > > > > > > *priv,
> > > > > > > > struct resource res;
> > > > > > > >
> > > > > > > > node = of_parse_phandle(np, "memory-region", a);
> > > > > > > > + /* Not map vdev region */
> > > > > > > > + if (!strcmp(node->name, "vdev"))
> > > > > > > > + continue;
> > > > > > >
> > > > > > > I am very confused and because I don't see an example for
> > > > > > > the DT in the bindings document I have to guess what is going on.
> > > > > >
> > > > > > V6 will include the DT yaml.
> > > > > >
> > > > > > >
> > > > > > > So I am guessing that you have laid out the memory regions
> > > > > > > for the vrings and the vdev0buffer in the DT "memory-region".
> > > > > >
> > > > > > The dts part will be similar as following:
> > > > > >
> > > > > > + #include <dt-bindings/clock/imx8mm-clock.h>
> > > > > > + rsc_table: rsc_table@550ff000 {
> > > > > > + no-map;
> > > > > > + reg = <0x550ff000 0x1000>;
> > > > > > + };
> > > > > > +
> > > > > > + vdev0vring0: vdev0vring0@55000000 {
> > > > > > + no-map;
> > > > > > + reg = <0x55000000 0x8000>;
> > > > > > + };
> > > > > > +
> > > > > > + vdev0vring1: vdev0vring1@55008000 {
> > > > > > + reg = <0x55008000 0x8000>;
> > > > > > + no-map;
> > > > > > + };
> > > > > > +
> > > > > > + vdevbuffer: vdevbuffer@55400000 {
> > > > > > + compatible = "shared-dma-pool";
> > > > > > + reg = <0x55400000 0x100000>;
> > > > > > + no-map;
> > > > > > + };
> > > > > > +
> > > > > > + imx8mm-cm4 {
> > > > > > + compatible = "fsl,imx8mm-cm4";
> > > > > > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > > > > > + mbox-names = "tx", "rx", "rxdb";
> > > > > > + mboxes = <&mu 0 1
> > > > > > + &mu 1 1
> > > > > > + &mu 3 1>;
> > > > > > + memory-region = <&vdevbuffer>, <&vdev0vring0>,
> > > > > > + <&vdev0vring1>,
> > > > > <&rsc_table>;
> > > > > > + syscon = <&src>;
> > > > > > + };
> > > > > >
> > > > > > >
> > > > > > > For the vrings I don't see the allocation of a carveout,
> > > > > > > which means that you will take the memory out of the DMA
> > > > > > > pool and the reserve memory will be wasted.
> > > > > >
> > > > > > imx_rproc_parse_memory_regions will alloc carveout.
> > > > >
> > > > > They _will_ but for now they don't and as such there a
> > > > > discrepancy between the bindings and the code that was published
> > > > > in V6. At this point you can either drop the vrings in the DT
> > > > > or send another revision with the carveouts allocated. I would
> > > > > definitely prefer the latter because it wouldn't involve yet
> > > > > another modification of the
> > > bindings.
> > > >
> > > > You mean I drop patch v5 7/8 and send v7, right?
> > > >
> > >
> > > If you do that than the implementation won't reflect the bindings.
> > >
> > > > Or are there other changes that I need to do?
> > >
> > > If you want to keep the bindings the same way you have them in V6,
> > > carveouts are required in the implementation.
> >
> > ok. Could you share more info about carveouts are required?
> > imx_rproc_parse_memory_regions in my pachset already have
> > rproc_add_carveout. I am not clear what else needs to be done.
>
> Ah yes, I see now. In your answer above you wrote
> "imx_rproc_parse_memory_regions will alloc carveout", which I interpreted
> as "will do so in a future patchset".
>
> I will review V6 - no need to change anything at this time.
Thanks, since we are almost clear and no major code change, I'll post V7
after addressing the comments in V6.
Thanks,
Peng.
>
> >
> > Thanks,
> > Peng.
> >
> > >
> > > >
> > > > Thanks,
> > > > Peng.
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > For the vdev0buffer, what you have will work *only* if that
> > > > > > > entry is the first one in the list of memory regions, as we
> > > > > > > agreed here
> > > [2].
> > > > > >
> > > > > > Yes. I agree and follow this rule from then.
> > > > > >
> > > > > > Thanks,
> > > > > > Peng.
> > > > > >
> > > > > > >
> > > > > > > [1].
> > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > %2F%25
> > > > > > > 2Fel
> > > > > > > ixir.b
> > > > > > >
> > > > >
> > >
> ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > > > > > >
> > > > >
> > >
> moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > > > > > >
> > > > >
> > >
> C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > > > > > >
> > > > >
> > >
> 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > > > > > >
> > > > >
> > >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > > > > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAIt
> qZ
> > > m66
> > > > > b4
> > > > > > > m20%3D&reserved=0
> > > > > > > [2].
> > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > %2F%25
> > > > > > > 2Fpa
> > > > > > > tch
> > > > > > >
> > > > >
> > >
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > > > > > >
> > > > >
> > >
> 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > > > > > >
> > > > >
> > >
> xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > > > > > >
> > > > >
> > >
> 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > > > > > >
> > > > >
> > >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > > > >
> > > > >
> > >
> VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > > > > > FHjwA6a8x58geY7eE%3D&reserved=0
> > > > > > >
> > > > > > > > err = of_address_to_resource(node, 0, &res);
> > > > > > > > if (err) {
> > > > > > > > dev_err(dev, "unable to resolve memory
> region\n");
> > > > > > > > --
> > > > > > > > 2.28.0
> > > > > > > >
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions
@ 2021-01-15 3:29 ` Peng Fan
0 siblings, 0 replies; 50+ messages in thread
From: Peng Fan @ 2021-01-15 3:29 UTC (permalink / raw)
To: Mathieu Poirier
Cc: ohad, patrice.chotard, festevam, s.hauer, linux-remoteproc,
linux-kernel, bjorn.andersson, paul, o.rempel, agross,
dl-linux-imx, kernel, matthias.bgg, shawnguo, linux-arm-kernel
> Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> regions
>
> On Thu, Jan 14, 2021 at 09:52:13AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > vdev regions
> > >
> > > On Wed, Jan 13, 2021 at 02:19:32AM +0000, Peng Fan wrote:
> > > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore
> > > > > mapping vdev regions
> > > > >
> > > > > On Tue, Jan 12, 2021 at 09:41:12AM +0000, Peng Fan wrote:
> > > > > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore
> > > > > > > mapping vdev regions
> > > > > > >
> > > > > > > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@nxp.com
> > > wrote:
> > > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > > >
> > > > > > > > vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and
> similar.
> > > > > > > > They are handled by remoteproc common code, no need to map
> > > > > > > > in imx rproc driver.
> > > > > > > >
> > > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > > > > ---
> > > > > > > > drivers/remoteproc/imx_rproc.c | 3 +++
> > > > > > > > 1 file changed, 3 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > > > > b/drivers/remoteproc/imx_rproc.c index
> > > > > > > > f80428afb8a7..e62a53ee128e
> > > > > > > > 100644
> > > > > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > > > > @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct
> > > > > > > > imx_rproc
> > > > > > > *priv,
> > > > > > > > struct resource res;
> > > > > > > >
> > > > > > > > node = of_parse_phandle(np, "memory-region", a);
> > > > > > > > + /* Not map vdev region */
> > > > > > > > + if (!strcmp(node->name, "vdev"))
> > > > > > > > + continue;
> > > > > > >
> > > > > > > I am very confused and because I don't see an example for
> > > > > > > the DT in the bindings document I have to guess what is going on.
> > > > > >
> > > > > > V6 will include the DT yaml.
> > > > > >
> > > > > > >
> > > > > > > So I am guessing that you have laid out the memory regions
> > > > > > > for the vrings and the vdev0buffer in the DT "memory-region".
> > > > > >
> > > > > > The dts part will be similar as following:
> > > > > >
> > > > > > + #include <dt-bindings/clock/imx8mm-clock.h>
> > > > > > + rsc_table: rsc_table@550ff000 {
> > > > > > + no-map;
> > > > > > + reg = <0x550ff000 0x1000>;
> > > > > > + };
> > > > > > +
> > > > > > + vdev0vring0: vdev0vring0@55000000 {
> > > > > > + no-map;
> > > > > > + reg = <0x55000000 0x8000>;
> > > > > > + };
> > > > > > +
> > > > > > + vdev0vring1: vdev0vring1@55008000 {
> > > > > > + reg = <0x55008000 0x8000>;
> > > > > > + no-map;
> > > > > > + };
> > > > > > +
> > > > > > + vdevbuffer: vdevbuffer@55400000 {
> > > > > > + compatible = "shared-dma-pool";
> > > > > > + reg = <0x55400000 0x100000>;
> > > > > > + no-map;
> > > > > > + };
> > > > > > +
> > > > > > + imx8mm-cm4 {
> > > > > > + compatible = "fsl,imx8mm-cm4";
> > > > > > + clocks = <&clk IMX8MM_CLK_M4_DIV>;
> > > > > > + mbox-names = "tx", "rx", "rxdb";
> > > > > > + mboxes = <&mu 0 1
> > > > > > + &mu 1 1
> > > > > > + &mu 3 1>;
> > > > > > + memory-region = <&vdevbuffer>, <&vdev0vring0>,
> > > > > > + <&vdev0vring1>,
> > > > > <&rsc_table>;
> > > > > > + syscon = <&src>;
> > > > > > + };
> > > > > >
> > > > > > >
> > > > > > > For the vrings I don't see the allocation of a carveout,
> > > > > > > which means that you will take the memory out of the DMA
> > > > > > > pool and the reserve memory will be wasted.
> > > > > >
> > > > > > imx_rproc_parse_memory_regions will alloc carveout.
> > > > >
> > > > > They _will_ but for now they don't and as such there a
> > > > > discrepancy between the bindings and the code that was published
> > > > > in V6. At this point you can either drop the vrings in the DT
> > > > > or send another revision with the carveouts allocated. I would
> > > > > definitely prefer the latter because it wouldn't involve yet
> > > > > another modification of the
> > > bindings.
> > > >
> > > > You mean I drop patch v5 7/8 and send v7, right?
> > > >
> > >
> > > If you do that than the implementation won't reflect the bindings.
> > >
> > > > Or are there other changes that I need to do?
> > >
> > > If you want to keep the bindings the same way you have them in V6,
> > > carveouts are required in the implementation.
> >
> > ok. Could you share more info about carveouts are required?
> > imx_rproc_parse_memory_regions in my pachset already have
> > rproc_add_carveout. I am not clear what else needs to be done.
>
> Ah yes, I see now. In your answer above you wrote
> "imx_rproc_parse_memory_regions will alloc carveout", which I interpreted
> as "will do so in a future patchset".
>
> I will review V6 - no need to change anything at this time.
Thanks, since we are almost clear and no major code change, I'll post V7
after addressing the comments in V6.
Thanks,
Peng.
>
> >
> > Thanks,
> > Peng.
> >
> > >
> > > >
> > > > Thanks,
> > > > Peng.
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > For the vdev0buffer, what you have will work *only* if that
> > > > > > > entry is the first one in the list of memory regions, as we
> > > > > > > agreed here
> > > [2].
> > > > > >
> > > > > > Yes. I agree and follow this rule from then.
> > > > > >
> > > > > > Thanks,
> > > > > > Peng.
> > > > > >
> > > > > > >
> > > > > > > [1].
> > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > %2F%25
> > > > > > > 2Fel
> > > > > > > ixir.b
> > > > > > >
> > > > >
> > >
> ootlin.com%2Flinux%2Fv5.11-rc3%2Fsource%2Fdrivers%2Fremoteproc%2Fre
> > > > > > >
> > > > >
> > >
> moteproc_core.c%23L321&data=04%7C01%7Cpeng.fan%40nxp.com%7
> > > > > > >
> > > > >
> > >
> C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa92cd99c5c
> > > > > > >
> > > > >
> > >
> 301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTWFpbGZsb3
> > > > > > >
> > > > >
> > >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > > > > > %3D%7C1000&sdata=Qur6YiTWlak0ZRnrUZRzawfoO38EBrAIt
> qZ
> > > m66
> > > > > b4
> > > > > > > m20%3D&reserved=0
> > > > > > > [2].
> > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > %2F%25
> > > > > > > 2Fpa
> > > > > > > tch
> > > > > > >
> > > > >
> > >
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2F202007221315
> > > > > > >
> > > > >
> > >
> 43.7024-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n
> > > > > > >
> > > > >
> > >
> xp.com%7C581784529b1646b9d34b08d8b67ae8c7%7C686ea1d3bc2b4c6fa9
> > > > > > >
> > > > >
> > >
> 2cd99c5c301635%7C0%7C0%7C637459986311799770%7CUnknown%7CTW
> > > > > > >
> > > > >
> > >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > > > >
> > > > >
> > >
> VCI6Mn0%3D%7C1000&sdata=b%2F8muWtb3yxKIsnXmKmRGYYV33%2
> > > > > > > FHjwA6a8x58geY7eE%3D&reserved=0
> > > > > > >
> > > > > > > > err = of_address_to_resource(node, 0, &res);
> > > > > > > > if (err) {
> > > > > > > > dev_err(dev, "unable to resolve memory
> region\n");
> > > > > > > > --
> > > > > > > > 2.28.0
> > > > > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2021-01-15 3:33 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-29 3:30 [PATCH V5 0/8] remoteproc: imx_rproc: support iMX8MQ/M peng.fan
2020-12-29 3:30 ` peng.fan
2020-12-29 3:30 ` [PATCH V5 1/8] remoteproc: introduce is_iomem to rproc_mem_entry peng.fan
2020-12-29 3:30 ` peng.fan
2021-01-11 18:53 ` Mathieu Poirier
2021-01-11 18:53 ` Mathieu Poirier
2020-12-29 3:30 ` [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va peng.fan
2020-12-29 3:30 ` peng.fan
2020-12-30 15:14 ` kernel test robot
2020-12-30 15:14 ` kernel test robot
2020-12-30 15:20 ` kernel test robot
2020-12-30 15:20 ` kernel test robot
2021-01-11 20:25 ` Mathieu Poirier
2021-01-11 20:25 ` Mathieu Poirier
2020-12-29 3:30 ` [PATCH V5 3/8] remoteproc: imx_rproc: correct err message peng.fan
2020-12-29 3:30 ` peng.fan
2021-01-11 20:35 ` Mathieu Poirier
2021-01-11 20:35 ` Mathieu Poirier
2021-01-11 20:44 ` Mathieu Poirier
2021-01-11 20:44 ` Mathieu Poirier
2020-12-29 3:30 ` [PATCH V5 4/8] remoteproc: imx_rproc: use devm_ioremap peng.fan
2020-12-29 3:30 ` peng.fan
2021-01-11 20:46 ` Mathieu Poirier
2021-01-11 20:46 ` Mathieu Poirier
2020-12-29 3:30 ` [PATCH V5 5/8] remoteproc: imx_rproc: add i.MX specific parse fw hook peng.fan
2020-12-29 3:30 ` peng.fan
2020-12-29 3:30 ` [PATCH V5 6/8] remoteproc: imx_rproc: support i.MX8MQ/M peng.fan
2020-12-29 3:30 ` peng.fan
2021-01-11 21:40 ` Mathieu Poirier
2021-01-11 21:40 ` Mathieu Poirier
2020-12-29 3:30 ` [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions peng.fan
2020-12-29 3:30 ` peng.fan
2021-01-11 21:50 ` Mathieu Poirier
2021-01-11 21:50 ` Mathieu Poirier
2021-01-12 9:41 ` Peng Fan
2021-01-12 9:41 ` Peng Fan
2021-01-12 18:46 ` Mathieu Poirier
2021-01-12 18:46 ` Mathieu Poirier
2021-01-13 2:19 ` Peng Fan
2021-01-13 2:19 ` Peng Fan
2021-01-13 16:17 ` Mathieu Poirier
2021-01-13 16:17 ` Mathieu Poirier
2021-01-14 9:52 ` Peng Fan
2021-01-14 9:52 ` Peng Fan
2021-01-14 17:10 ` Mathieu Poirier
2021-01-14 17:10 ` Mathieu Poirier
2021-01-15 3:29 ` Peng Fan
2021-01-15 3:29 ` Peng Fan
2020-12-29 3:30 ` [PATCH V5 8/8] remoteproc: imx_proc: enable virtio/mailbox peng.fan
2020-12-29 3:30 ` peng.fan
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.