On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng.fan@xxxxxxx wrote: > From: Peng Fan <peng.fan@xxxxxxx> > > 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@xxxxxxx> > --- > 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@xxxxxxx/ > err = of_address_to_resource(node, 0, &res); > if (err) { > dev_err(dev, "unable to resolve memory region\n"); > -- > 2.28.0 >
