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 <[email protected]>
Cc: Brian Swetland <[email protected]>
Cc: Iliyan Malchev <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Grant Likely <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: Mark Grosen <[email protected]>
Cc: John Williams <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Loic PALLARDY <[email protected]>
Cc: Ludovic BARRE <[email protected]>
Cc: Omar Ramirez Luna <[email protected]>
Cc: Guzman Lugo Fernando <[email protected]>
Cc: Anna Suman <[email protected]>
Cc: Clark Rob <[email protected]>
Cc: Stephen Boyd <[email protected]>
Cc: Saravana Kannan <[email protected]>
Cc: David Brown <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Tony Lindgren <[email protected]>

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