On Thu 05 May 06:29 PDT 2016, Lee Jones wrote:[..]
Normally used for management of; carveout, devmem and trace memory.
Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx>
---
drivers/remoteproc/remoteproc_core.c | 174 +++++++++++++++++++++++++++++++++--
1 file changed, 167 insertions(+), 7 deletions(-)
Hi Bjorn,+}
+EXPORT_SYMBOL(rproc_subdev_add);
I worked up a prototype that allows remoteproc drivers toNo sure to catch your exact use case, but let me try to explain what we have today.
programmatically specify carveout resources, which then are matched and
merged with entires from the resource table. I've given these
programmatically allocated carveouts a device so that the associated
allocation comes out of the specified region - or the rproc region if no
match is found.
This solves my use case of carving out memory from two disjoint memory
regions for one of my remoteprocs, but differs from your approach in
that you specify one large carveout (and vrings) region and any
carveouts (or vrings) will chip away from this.
Would this approach work for you, or do you depend on having 1:N
relationship between your memory region and your resources?
Regards,
Bjorn
_______________________________________________
Kernel mailing list
Kernel@xxxxxxxxxxx
http://www.stlinux.com/mailman/listinfo/kernel