summaryrefslogtreecommitdiffstats
path: root/Documentation/remoteproc.txt
diff options
context:
space:
mode:
authorOhad Ben-Cohen <ohad@wizery.com>2012-02-13 22:30:39 +0100
committerOhad Ben-Cohen <ohad@wizery.com>2012-03-06 19:14:12 +0200
commit7a186941626d19f668b08108db158379b32e6e02 (patch)
treed478210fa3ae45ef8b3eaf6a6432eadc49cbb55a /Documentation/remoteproc.txt
parent41a6ee09ee8dd7ac3a6ac12a24e26279b5d93385 (diff)
downloadtalos-op-linux-7a186941626d19f668b08108db158379b32e6e02.tar.gz
talos-op-linux-7a186941626d19f668b08108db158379b32e6e02.zip
remoteproc: remove the single rpmsg vdev limitation
Now that the resource table supports publishing a virtio device in a single resource entry, firmware images can start supporting more than a single vdev. This patch removes the single vdev limitation of the remoteproc framework so multi-vdev firmwares can be leveraged: VDEV resource entries are parsed when the rproc is registered, and as a result their vrings are set up and the virtio devices are registered (and they go away when the rproc goes away). Moreover, we no longer only support VIRTIO_ID_RPMSG vdevs; any virtio device type goes now. As a result, there's no more any rpmsg-specific APIs or code in remoteproc: it all becomes generic virtio handling. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: Brian Swetland <swetland@google.com> Cc: Iliyan Malchev <malchev@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Mark Grosen <mgrosen@ti.com> Cc: John Williams <john.williams@petalogix.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Loic PALLARDY <loic.pallardy@stericsson.com> Cc: Ludovic BARRE <ludovic.barre@stericsson.com> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Cc: Guzman Lugo Fernando <fernando.lugo@ti.com> Cc: Anna Suman <s-anna@ti.com> Cc: Clark Rob <rob@ti.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Saravana Kannan <skannan@codeaurora.org> Cc: David Brown <davidb@codeaurora.org> Cc: Kieran Bingham <kieranbingham@gmail.com> Cc: Tony Lindgren <tony@atomide.com>
Diffstat (limited to 'Documentation/remoteproc.txt')
-rw-r--r--Documentation/remoteproc.txt9
1 files changed, 6 insertions, 3 deletions
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index 07057cacfeae..70a048cd3fa3 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -20,6 +20,11 @@ platform-specific remoteproc drivers only need to provide a few low-level
handlers, and then all rpmsg drivers will then just work
(for more information about the virtio-based rpmsg bus and its drivers,
please read Documentation/rpmsg.txt).
+Registration of other types of virtio devices is now also possible. Firmwares
+just need to publish what kind of virtio devices do they support, and then
+remoteproc will add those devices. This makes it possible to reuse the
+existing virtio drivers with remote processor backends at a minimal development
+cost.
2. User API
@@ -136,8 +141,6 @@ int dummy_rproc_example(struct rproc *my_rproc)
If found, those virtio devices will be created and added, so as a result
of registering this remote processor, additional virtio drivers might get
probed.
- Currently, though, we only support a single RPMSG virtio vdev per remote
- processor.
int rproc_unregister(struct rproc *rproc)
- Unregister a remote processor, and decrement its refcount.
@@ -174,7 +177,7 @@ struct rproc_ops {
};
Every remoteproc implementation should at least provide the ->start and ->stop
-handlers. If rpmsg functionality is also desired, then the ->kick handler
+handlers. If rpmsg/virtio functionality is also desired, then the ->kick handler
should be provided as well.
The ->start() handler takes an rproc handle and should then power on the
OpenPOWER on IntegriCloud