[lkml]   [2021]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: remoteproc DMA API abuse status
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

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)


 \ /
  Last update: 2021-06-29 12:11    [W:0.087 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site