At this point remoteproc can only register a single VIRTIO_ID_RPMSG virtio
device.
This limitation is going away soon: remoteproc is getting support for
registering any number of virtio devices and of any type (as
published by the firmware of the remote processor).
Rename remoteproc_rpmsg.c to remoteproc_virtio.c in preparation of
this generalization work.
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>
When creating a virtqueue for rpmsg, tell virtio we're not interested
in "weak" smp barriers, since we're talking to a real device.
On ARM, this means using a DSB instead of a DMB, which is needed
for platforms that kick the remote processor using some kind of
a mailbox device mapped to Device memory (otherwise the kick can
jump ahead and wake the remote processor before it has observed
the changes to the vrings).
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Create an rpmsg virtio device to allow message-based communication
with the remote processor (but only if supported by its firmware).
There are several advantages to provide this functionality at
the remoteproc-level:
- to support it, platforms only have to provide their own ->kick()
handler; no need to duplicate the rest of the code.
- the virtio device is created only when the remote processor is
registered and ready to go. No need to depend on initcall magic.
moreover, we only add the virtio device if the firmware really
supports it, and only after we know the supported virtio device features.
- correct device model hierarchy can be set, and that is useful
for natural power management and DMA API behavior.
- when the remote processor crashes (or removed) we only need
to remove the virtio device, and the driver core will take care of
the rest. No need to implement any out-of-bound notifiers.
- we can now easily bind the virtio device to its rproc handle, and
this way we don't need any name-based remoteproc ->get() API.
Currently we only support creating a single rpmsg virtio device per
remote processor, but later this is going to be extended to support
creating numerous virtio devices of other types too (block, net,
console...).
Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
