archive mirror
 help / color / mirror / Atom feed
From: Arnaud POULIQUEN <>
To: Mathieu Poirier <>
Cc: Christoph Hellwig <>, Ohad Ben-Cohen <>,
	Bjorn Andersson <>,
Subject: Re: remoteproc DMA API abuse status
Date: Tue, 29 Jun 2021 12:10:26 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210628201419.GC1200359@p14s>

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)


      reply	other threads:[~2021-06-29 10:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 13:43 remoteproc DMA API abuse status Christoph Hellwig
2021-06-24 19:35 ` Mathieu Poirier
2021-06-25  7:27   ` Arnaud POULIQUEN
2021-06-28 13:36     ` Christoph Hellwig
2021-06-28 20:14     ` Mathieu Poirier
2021-06-29 10:10       ` Arnaud POULIQUEN [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).