Messages in this thread | | | Subject | Re: remoteproc DMA API abuse status | From | Arnaud POULIQUEN <> | Date | Tue, 29 Jun 2021 12:10:26 +0200 |
| |
Hi Mathieu
On 6/28/21 10:14 PM, Mathieu Poirier wrote: > I thought your current work on refactoring the rpmsg_char driver was part of the > early steps on the way to splitting that patchset up...
No it is de-correlated. Here the point is the vdev0buffer memory region declared in rproc that we associate to the rproc_virtio device to be able to use is for RPMsg.
When I have a look this here is the approach we had trying to fix it (this correspond to my patchset):
The objective is to suppress the dma_declare_coherent_memory usage.
=> In this case the "vdev0buffer" virtio buffer memory pool has do be associated to the a virtio device by a declaration in device tree. Probably as a subnode of the remoteproc device node.
&rproc { #address-cells = <1>; #size-cells = <0>;
+ vdev@0 { + memory-region = <&vdev0vring0>, <&vdev0vring1>, <&vdev0buffer>; + compatible = "rproc-virtio"; + reg = <0>; + status = "okay"; + }; };
=> a reproc virtio platform driver compatible should be created (based on remoteproc core and remote_virtio restructuring). The memory region will be in this case associated in a clean way to the remoteproc virtio device.
=> As consequence we would have 2 module devices the remoteproc and remoteproc virtio. Both as to be synchronized to ensure that all is ready before starting the remote processor => reuse of the proc->subdev mechanism + (component bind/unbind similar to DRM?)
The last but not the least we probably have to maintain the legacy a while to let time to move on this new device tree architecture.
Now the question are: - Is this the good approach or could a simpler patch can fix the issue. - how to address models with one big memory pool used (TI implementation)
Regards, Arnaud
| |