diff options
author | Ohad Ben-Cohen <ohad@wizery.com> | 2012-02-13 16:30:39 -0500 |
---|---|---|
committer | Ohad Ben-Cohen <ohad@wizery.com> | 2012-03-06 12:14:12 -0500 |
commit | 7a186941626d19f668b08108db158379b32e6e02 (patch) | |
tree | d478210fa3ae45ef8b3eaf6a6432eadc49cbb55a /Documentation | |
parent | 41a6ee09ee8dd7ac3a6ac12a24e26279b5d93385 (diff) |
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')
-rw-r--r-- | Documentation/remoteproc.txt | 9 |
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 | |||
20 | handlers, and then all rpmsg drivers will then just work | 20 | handlers, and then all rpmsg drivers will then just work |
21 | (for more information about the virtio-based rpmsg bus and its drivers, | 21 | (for more information about the virtio-based rpmsg bus and its drivers, |
22 | please read Documentation/rpmsg.txt). | 22 | please read Documentation/rpmsg.txt). |
23 | Registration of other types of virtio devices is now also possible. Firmwares | ||
24 | just need to publish what kind of virtio devices do they support, and then | ||
25 | remoteproc will add those devices. This makes it possible to reuse the | ||
26 | existing virtio drivers with remote processor backends at a minimal development | ||
27 | cost. | ||
23 | 28 | ||
24 | 2. User API | 29 | 2. User API |
25 | 30 | ||
@@ -136,8 +141,6 @@ int dummy_rproc_example(struct rproc *my_rproc) | |||
136 | If found, those virtio devices will be created and added, so as a result | 141 | If found, those virtio devices will be created and added, so as a result |
137 | of registering this remote processor, additional virtio drivers might get | 142 | of registering this remote processor, additional virtio drivers might get |
138 | probed. | 143 | probed. |
139 | Currently, though, we only support a single RPMSG virtio vdev per remote | ||
140 | processor. | ||
141 | 144 | ||
142 | int rproc_unregister(struct rproc *rproc) | 145 | int rproc_unregister(struct rproc *rproc) |
143 | - Unregister a remote processor, and decrement its refcount. | 146 | - Unregister a remote processor, and decrement its refcount. |
@@ -174,7 +177,7 @@ struct rproc_ops { | |||
174 | }; | 177 | }; |
175 | 178 | ||
176 | Every remoteproc implementation should at least provide the ->start and ->stop | 179 | Every remoteproc implementation should at least provide the ->start and ->stop |
177 | handlers. If rpmsg functionality is also desired, then the ->kick handler | 180 | handlers. If rpmsg/virtio functionality is also desired, then the ->kick handler |
178 | should be provided as well. | 181 | should be provided as well. |
179 | 182 | ||
180 | The ->start() handler takes an rproc handle and should then power on the | 183 | The ->start() handler takes an rproc handle and should then power on the |