Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: remoteproc DMA API abuse status
To:     Mathieu Poirier <mathieu.poirier@linaro.org>
CC:     Christoph Hellwig <hch@lst.de>, Ohad Ben-Cohen <ohad@wizery.com>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        <linux-remoteproc@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <20210623134307.GA29505@lst.de> <20210624193514.GA1090275@p14s>
 <011dac94-cfe0-d276-980a-b8ffe1447521@foss.st.com>
 <20210628201419.GC1200359@p14s>
From:   Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Message-ID: <3f0a2e44-c439-46ea-1100-881d19c9005d@foss.st.com>
Date:   Tue, 29 Jun 2021 12:10:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210628201419.GC1200359@p14s>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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