> -----Original Message----- > From: Bjorn Andersson [mailto:bjorn.andersson@xxxxxxxxxx] > Sent: Thursday, May 10, 2018 2:59 AM > To: Loic PALLARDY <loic.pallardy@xxxxxx> > Cc: ohad@xxxxxxxxxx; linux-remoteproc@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; Arnaud POULIQUEN <arnaud.pouliquen@xxxxxx>; > benjamin.gaignard@xxxxxxxxxx > Subject: Re: [PATCH v3 10/13] remoteproc: modify vring allocation to support > pre-registered region > > On Thu 01 Mar 08:23 PST 2018, Loic Pallardy wrote: > [..] > > @@ -265,23 +269,45 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, > int i) > > struct device *dev = &rproc->dev; > > struct rproc_vring *rvring = &rvdev->vring[i]; > > struct fw_rsc_vdev *rsc; > > - dma_addr_t dma; > > - void *va; > > int ret, size, notifyid; > > + struct fw_rsc_carveout rsc_carveout; > > + struct rproc_mem_entry *mem; > > > > /* actual size of vring (in bytes) */ > > size = PAGE_ALIGN(vring_size(rvring->len, rvring->align)); > > > > - /* > > - * Allocate non-cacheable memory for the vring. In the future > > - * this call will also configure the IOMMU for us > > - */ > > - va = dma_alloc_coherent(dev->parent, size, &dma, GFP_KERNEL); > > - if (!va) { > > - dev_err(dev->parent, "dma_alloc_coherent failed\n"); > > + rsc = (void *)rproc->table_ptr + rvdev->rsc_offset; > > + > > + /* Create virtual firmware carveout resource */ > > + rsc_carveout.da = rsc->vring[i].da; > > + rsc_carveout.pa = FW_RSC_ADDR_ANY; > > + rsc_carveout.len = size; > > + rsc_carveout.flags = 0; > > + rsc_carveout.reserved = 0; > > + snprintf(rsc_carveout.name, sizeof(rsc_carveout.name), > "vdev%dvring%d", > > + rvdev->index, i); > [..] > > @@ -437,6 +460,7 @@ static int rproc_handle_vdev(struct rproc *rproc, > struct fw_rsc_vdev *rsc, > > > > rvdev->id = rsc->id; > > rvdev->rproc = rproc; > > + rvdev->index = index++; > > This index isn't deterministic over multiple remoteproc instances and > multiple restarts of the remoteproc. It probably needs to be based > generated based on the ordering in the resource table. Yes it was my intention, but static use make it wrong. I'll revisit this point Regards, Loic > > Regards, > Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html