Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Thu, Sep 15, 2011 at 3:12 AM, Rusty Russell ru...@rustcorp.com.au wrote: 7... numbers are cheap :) 7 it is :) Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
Hi Rusty, On Wed, Jun 22, 2011 at 1:46 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell ru...@rustcorp.com.au wrote: On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen o...@wizery.com wrote: +#define VIRTIO_ID_RPMSG 10 /* virtio remote processor messaging */ I think you want 6. Plan 9 jumped ahead to grab 9 :) 6 it is :) Looking at the virtio-spec, it seems that 6 is taken by 'ioMemory'. There's no indication for it in virtio_ids.h though, and the virtio-spec has no appendix for this id, so maybe it's available after all ? If it is available, I'll take it for rpmsg, and will also update virtio-spec appropriately. Otherwise, we'll settle on 7 ? :) Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Wed, 14 Sep 2011 21:38:43 +0300, Ohad Ben-Cohen o...@wizery.com wrote: Hi Rusty, On Wed, Jun 22, 2011 at 1:46 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell ru...@rustcorp.com.au wrote: On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen o...@wizery.com wrote: +#define VIRTIO_ID_RPMSG 10 /* virtio remote processor messaging */ I think you want 6. Plan 9 jumped ahead to grab 9 :) 6 it is :) Looking at the virtio-spec, it seems that 6 is taken by 'ioMemory'. There's no indication for it in virtio_ids.h though, and the virtio-spec has no appendix for this id, so maybe it's available after all ? If it is available, I'll take it for rpmsg, and will also update virtio-spec appropriately. Otherwise, we'll settle on 7 ? :) 7... numbers are cheap :) Cheers, Rusty. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
Hi! @@ -0,0 +1,75 @@ +What:/sys/bus/rpmsg/devices/.../name +Date:June 2011 +KernelVersion: 3.2 +Contact: Ohad Ben-Cohen o...@wizery.com +Description: + Every rpmsg device is a communication channel with a remote + processor. Channels are identified with a (textual) name, + which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in + rpmsg.h). + + This sysfs entry contains the name of this channel. + +What:/sys/bus/rpmsg/devices/.../src +Date:June 2011 +KernelVersion: 3.2 +Contact: Ohad Ben-Cohen o...@wizery.com +Description: + Every rpmsg device is a communication channel with a remote + processor. Channels have a local (source) rpmsg address, + and remote (destination) rpmsg address. When an entity + starts listening on one end of a channel, it assigns it with + a unique rpmsg address (a 32 bits integer). This way when + inbound messages arrive to this address, the rpmsg core + dispatches them to the listening entity (a kernel driver). + + This sysfs entry contains the src (local) rpmsg address + of this channel. If it contains 0x, then an address + wasn't assigned (can happen if no driver exists for this + channel). So this is basically networking... right? Why not implement it as sockets? (accept, connect, read, write)? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
Hi Pavel, On Thu, Jun 9, 2011 at 8:12 PM, Pavel Machek pa...@ucw.cz wrote: So this is basically networking... right? Why not implement it as sockets? (accept, connect, read, write)? This patch focuses on adding the core rpmsg kernel infrastructure. The next step, after getting the basic stuff in, would be adding rpmsg drivers, and exposing user space API. For some use cases, where userland talks directly with remote entities (and otherwise requires no kernel involvement besides exposing the transport), socket API is very nice as it's flexible and prevalent. We already have several rpmsg drivers and a rpmsg-based socket API implementation too, but we'll get to it only after the core stuff gets in. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Wed, Jun 29, 2011 at 6:43 PM, Grant Likely grant.lik...@secretlab.ca wrote: So you are right that device_unregister drops the refcount to zero, but the code still needs to be fixed to not call kfree() directly. Good point, thanks ! It also looks like rpmsg_destroy_channel() needs to be fixed to remove the kfree call Yes, I need to remove this direct kfree as well, and indeed just let rpmsg_release_device do its thing when the last reference is dropped. I should also remove the direct kfree when device_register fails: in that case, I need only to put_device and let the release handler do its thing too. and an extra put_device() call. We need that extra put_device in rpmsg_destroy_channel because device_find_child() is doing get_device before returning it. Thanks, Grant! Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
Hi Randy, Thanks for your comments ! On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote: +hardware accelerators, and therefore are often used to offload cpu-intensive prefer: CPU- throughout. Isn't that changing the meaning a bit ? Let's stick with the original version, I think it's more clear. +system's physical memory and/or other sensitive hardware resources (e.g. on +OMAP4, remote cores (/hardware accelerators) may have direct access to the +physical memory, gpio banks, dma controllers, i2c bus, gptimers, mailbox +devices, hwspinlocks, etc..). Moreover, those remote processors might be +running RTOS where every task can access the entire memory/devices exposed +to the processor. To minimize the risks of rogue (/buggy) userland code What is with the leading / here and above (/hardware) and below? / here means or. You can read the sentence twice, either without the (/ ..) options or with them, and then you get two (different) examples. Any idea how to make it more readable ? I prefer not to drop the second example, as it's adding information. +if RPMSG + +# OK, it's a little counter-intuitive to do this, but it puts it neatly under +# the rpmsg menu (and it's the approach preferred by the virtio folks). + +source drivers/virtio/Kconfig It seems odd to have that Kconfig file sourced in multiple places. Are the kconfig tools happy with that? They are, probably because these places are mutually exclusive today: $ git grep drivers/virtio/Kconfig arch/ia64/kvm/Kconfig:source drivers/virtio/Kconfig arch/mips/Kconfig:source drivers/virtio/Kconfig arch/powerpc/kvm/Kconfig:source drivers/virtio/Kconfig arch/s390/kvm/Kconfig:source drivers/virtio/Kconfig arch/sh/Kconfig:source drivers/virtio/Kconfig arch/tile/kvm/Kconfig:source drivers/virtio/Kconfig arch/x86/kvm/Kconfig:source drivers/virtio/Kconfig Now that we start using virtio for inter-processor communications, too, we might soon bump into a situation where virtio will be sourced twice. Probably the solution is to move 'source drivers/virtio/Kconfig' into drivers/Kconfig, and remove all other instances. Rusty, are you ok with that ? Thanks, Ohad. Sorry about the delay. I had most of this in my drafts folder and forgot about it... Np, thanks a lot ! Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Wednesday 29 June 2011, Ohad Ben-Cohen wrote: On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote: +hardware accelerators, and therefore are often used to offload cpu-intensive prefer: CPU- throughout. Isn't that changing the meaning a bit ? Let's stick with the original version, I think it's more clear. I think you misunderstood Randy, he meant you should do 's/cpu/CPU/' globally, which does not change the meaning. +system's physical memory and/or other sensitive hardware resources (e.g. on +OMAP4, remote cores (/hardware accelerators) may have direct access to the +physical memory, gpio banks, dma controllers, i2c bus, gptimers, mailbox +devices, hwspinlocks, etc..). Moreover, those remote processors might be +running RTOS where every task can access the entire memory/devices exposed +to the processor. To minimize the risks of rogue (/buggy) userland code What is with the leading / here and above (/hardware) and below? / here means or. You can read the sentence twice, either without the (/ ..) options or with them, and then you get two (different) examples. Any idea how to make it more readable ? I prefer not to drop the second example, as it's adding information. The easiest way would be to replace it with 'or', as in ... remote cores (or hardware accelerators) may have ... I would also suggest you drop the parentheses, especially in the first case where you have two levels of them: system's physical memory and/or other sensitive hardware resources, e.g. on OMAP4, remote cores and hardware accelerators may have direct access to the specific hardware blocks such as physical memory, gpio banks or dma controllers. Moreover, those remote processors might be... +if RPMSG + +# OK, it's a little counter-intuitive to do this, but it puts it neatly under +# the rpmsg menu (and it's the approach preferred by the virtio folks). + +source drivers/virtio/Kconfig It seems odd to have that Kconfig file sourced in multiple places. Are the kconfig tools happy with that? They are, probably because these places are mutually exclusive today: $ git grep drivers/virtio/Kconfig arch/ia64/kvm/Kconfig:source drivers/virtio/Kconfig arch/mips/Kconfig:source drivers/virtio/Kconfig arch/powerpc/kvm/Kconfig:source drivers/virtio/Kconfig arch/s390/kvm/Kconfig:source drivers/virtio/Kconfig arch/sh/Kconfig:source drivers/virtio/Kconfig arch/tile/kvm/Kconfig:source drivers/virtio/Kconfig arch/x86/kvm/Kconfig:source drivers/virtio/Kconfig Now that we start using virtio for inter-processor communications, too, we might soon bump into a situation where virtio will be sourced twice. Probably the solution is to move 'source drivers/virtio/Kconfig' into drivers/Kconfig, and remove all other instances. I think changing that would be good. However, you need to at least restructure the contents, or they will show up in the main driver menu. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Wed, Jun 29, 2011 at 2:59 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 29 June 2011, Ohad Ben-Cohen wrote: On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote: +hardware accelerators, and therefore are often used to offload cpu-intensive prefer: CPU- throughout. Isn't that changing the meaning a bit ? Let's stick with the original version, I think it's more clear. I think you misunderstood Randy, he meant you should do 's/cpu/CPU/' globally, Oh, sorry, Randy. For some reason I thought you meant s/cpu-intensive/CPU-throughout/ which didn't make a lot of sense to me :) s/cpu/CPU/ is of course nicer. thanks ! The easiest way would be to replace it with 'or', as in ... remote cores (or hardware accelerators) may have ... yeah, i'll do it, thanks. It's a bit harder to get rid of the parentheses in the second sentence, but I'll think of something too. Probably the solution is to move 'source drivers/virtio/Kconfig' into drivers/Kconfig, and remove all other instances. I think changing that would be good. However, you need to at least restructure the contents, or they will show up in the main driver menu. I'll do that. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Tue, Jun 28, 2011 at 5:00 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Wed, Jun 29, 2011 at 1:51 AM, Grant Likely grant.lik...@secretlab.ca wrote: It's not the device_for_each_child() that you're 'putting' back from here. Its the original kref initialization when the device was created. device_unregister() is already calling put_device(), doesn't that deal with the original kref init for us ? /me digs deeper: device_register() has 2 parts; device_initialize() and device_add() device_init() initialized the kref to 1 (via kobject_init() device_add() calls get_device() to increment it to 2 Then similarly for device_unregister(): device_del() calls put_device() to decrement the kref to 1 a final put_device() call decrements the kref to 0 - which triggers a call to the release method that kfrees the object. So you are right that device_unregister drops the refcount to zero, but the code still needs to be fixed to not call kfree() directly. It also looks like rpmsg_destroy_channel() needs to be fixed to remove the kfree call and an extra put_device() call. This is important because the last put_device() call above might /not/ decrement the refcount to zero is for some reason something still holds a reference to the device. But the device will still get freed correctly when the other holder finally calls device_put(). g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
Hi Grant,
On Tue, Jun 28, 2011 at 1:21 AM, Grant Likely grant.lik...@secretlab.ca wrote:
Nice patch. I'm quite thrilled to see this implemented. Some
comments below, but otherwise I think it looks pretty good.
Thanks !
+source drivers/virtio/Kconfig
What happens when kvm and rpmsg both get enabled on the same kernel.
Sounds to me that eventually we'll have to source virtio's Kconfig in
drivers/Kconfig, and remove all the other locations it is sourced at
(currently it is directly sourced by several arch Kconfigs when
VIRTUALIZATION is selected).
+ if (strncmp(id-name, rpdev-id.name, RPMSG_NAME_SIZE))
+ return 0;
+
+ return 1;
+}
or simply: 'return strncmp(id-name, rpdev-id.name, RPMSG_NAME_SIZE) == 0;'
:-)
that works too ;)
+ spin_lock(vrp-endpoints_lock);
Is a spin_lock the right choice for endpoints, or should it be a
mutex (do the endpoints operations need to be atomic)?
Today it can be a mutex: it protects idr operations invoked either by
users (creating new endpoints, definitely not requiring atomicity) or
by platform code indicating that a new message has arrived (today it's
omap's mailbox driver, which calls from a process context).
I can change that, and if someone requires atomic operations later on,
move to spinlocks again.
But it probably won't matter too much as there's no contention on that
lock today (notifications coming from omap's mailbox are serialized,
and users creating new endpoints show up very infrequently).
At put_device time, it is conceivable that the dev pointer is no
longer valid. You'll need to get do the to_rpmsg_channel() before
putting the dev.
sure.
+static void rpmsg_upref_sleepers(struct virtproc_info *vrp)
+{
+ /* support multiple concurrent senders */
+ spin_lock(vrp-tx_lock);
+
+ /* are we the first sleeping context waiting for tx buffers ? */
+ if (!vrp-sleepers++)
Maybe use a kref?
I can change it to an atomic variable, but I don't think kref's memory
barriers are needed here: we already have memory barriers induced by
the spinlock.
+static int rpmsg_remove_device(struct device *dev, void *data)
+{
+ struct rpmsg_channel *rpdev = to_rpmsg_channel(dev);
+
+ device_unregister(dev);
+
+ kfree(rpdev);
put_device() I think.
Don't think so, we get the device handle from device_for_each_child
here, which doesn't call get_device (unlike device_find_child).
+static int __init init(void)
Even for static functions, it's a really good idea to prefix all
function names and file scoped symbol with a common prefix like
rpmsg_. Doing so avoids even the outside chance of a namespace
conflict.
Sure thing.
+ ret = bus_register(rpmsg_bus);
+ if (ret) {
+ pr_err(failed to register rpmsg bus: %d\n, ret);
+ return ret;
+ }
+
+ return register_virtio_driver(virtio_ipc_driver);
And if register_virtio_driver fails?
I'll handle that, thanks.
+struct rpmsg_device_id {
+ char name[RPMSG_NAME_SIZE];
+ kernel_ulong_t driver_data /* Data private to the driver */
+ __attribute__((aligned(sizeof(kernel_ulong_t;
+};
Should this be co-located with vio_device_id?
Sure, can't hurt (I assume you meant virtio_device_id here).
It makes it easier to dereference in kernel code if you do:
#ifdef __KERNEL__
void *data;
#else
kernel_ulong_t data;
#endif
Sure thing.
Thanks!
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Tue, Jun 28, 2011 at 4:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Hi Grant,
On Tue, Jun 28, 2011 at 1:21 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
+static int rpmsg_remove_device(struct device *dev, void *data)
+{
+ struct rpmsg_channel *rpdev = to_rpmsg_channel(dev);
+
+ device_unregister(dev);
+
+ kfree(rpdev);
put_device() I think.
Don't think so, we get the device handle from device_for_each_child
here, which doesn't call get_device (unlike device_find_child).
It's not the device_for_each_child() that you're 'putting' back from
here. Its the original kref initialization when the device was
created. Once a device is initialized, it must never be directly
kfree()'d.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Wed, Jun 29, 2011 at 1:51 AM, Grant Likely grant.lik...@secretlab.ca wrote: It's not the device_for_each_child() that you're 'putting' back from here. Its the original kref initialization when the device was created. device_unregister() is already calling put_device(), doesn't that deal with the original kref init for us ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Tue, 21 Jun 2011 10:18:33 +0300 Ohad Ben-Cohen wrote: Add a virtio-based IPC bus, which enables kernel users to communicate with remote processors over shared memory using a simple messaging protocol. Assign a local address for every local endpoint that is created, and bind it to the user's callback. Invoke that callback when the destination of an inbound message is the user's address. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- Documentation/ABI/testing/sysfs-bus-rpmsg | 75 +++ Documentation/rpmsg.txt | 308 + drivers/Kconfig |1 + drivers/Makefile |1 + drivers/rpmsg/Kconfig | 14 + drivers/rpmsg/Makefile|1 + drivers/rpmsg/virtio_rpmsg_bus.c | 1036 + include/linux/mod_devicetable.h | 10 + include/linux/rpmsg.h | 421 include/linux/virtio_ids.h|1 + 10 files changed, 1868 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-rpmsg create mode 100644 Documentation/rpmsg.txt create mode 100644 drivers/rpmsg/Kconfig create mode 100644 drivers/rpmsg/Makefile create mode 100644 drivers/rpmsg/virtio_rpmsg_bus.c create mode 100644 include/linux/rpmsg.h diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt new file mode 100644 index 000..0a7c820 --- /dev/null +++ b/Documentation/rpmsg.txt @@ -0,0 +1,308 @@ +Remote Processor Messaging (rpmsg) Framework + +1. Introduction + +Modern SoCs typically employ heterogeneous remote processor devices in +asymmetric multiprocessing (AMP) configurations, which may be running +different instances of operating system, whether it's Linux or any other +flavor of real-time OS. + +OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP. +Typically, the dual cortex-A9 is running Linux in a SMP configuration, +and each of the other three cores (two M3 cores and a DSP) is running +its own instance of RTOS in an AMP configuration. + +Typically AMP remote processors employ dedicated DSP codecs and multimedia +hardware accelerators, and therefore are often used to offload cpu-intensive prefer: CPU- throughout. +multimedia tasks from the main application processor. + +These remote processors could also be used to control latency-sensitive +sensors, drive random hardware blocks, or just perform background tasks +while the main CPU is idling. + +Users of those remote processors can either be userland apps (e.g. multimedia +frameworks talking with remote OMX components) or kernel drivers (controlling +hardware accessible only by the remote processor, reserving kernel-controlled +resources on behalf of the remote processor, etc..). + +Rpmsg is a virtio-based messaging bus that allows kernel drivers to communicate +with remote processors available on the system. In turn, drivers could then +expose appropriate user space interfaces, if needed. + +When writing a driver that exposes rpmsg communication to userland, please +keep in mind that remote processors might have direct access to the +system's physical memory and/or other sensitive hardware resources (e.g. on +OMAP4, remote cores (/hardware accelerators) may have direct access to the +physical memory, gpio banks, dma controllers, i2c bus, gptimers, mailbox +devices, hwspinlocks, etc..). Moreover, those remote processors might be +running RTOS where every task can access the entire memory/devices exposed +to the processor. To minimize the risks of rogue (/buggy) userland code What is with the leading / here and above (/hardware) and below? Looks like they can all be dropped. +exploiting (/triggering) remote bugs, and by that taking over (/down) the +system, it is often desired to limit userland to specific rpmsg channels (see +definition below) it is allowed to send messages on, and if possible/relevant, +minimize the amount of control it has over the content of the messages. + +Every rpmsg device is a communication channel with a remote processor (thus +rpmsg devices are called channels). Channels are identified by a textual name +and have a local (source) rpmsg address, and remote (destination) rpmsg +address. + +When a driver starts listening on a channel, it binds it with a unique +rpmsg src address (a 32 bits integer). This way when inbound messages arrive (a 32-bit integer). +to this src address, the rpmsg core dispatches them to that driver (by invoking +the driver's rx handler with the payload of the incoming message). + + +2. User API + + int rpmsg_send(struct rpmsg_channel *rpdev, void *data, int len); + - sends a message across to the remote processor on a given channel. + The caller should specify the channel, the data it
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Tue, Jun 21, 2011 at 10:18:33AM +0300, Ohad Ben-Cohen wrote:
Add a virtio-based IPC bus, which enables kernel users to communicate
with remote processors over shared memory using a simple messaging
protocol.
Assign a local address for every local endpoint that is created,
and bind it to the user's callback. Invoke that callback when the
destination of an inbound message is the user's address.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Hey Ohad,
Nice patch. I'm quite thrilled to see this implemented. Some
comments below, but otherwise I think it looks pretty good.
---
Documentation/ABI/testing/sysfs-bus-rpmsg | 75 +++
Documentation/rpmsg.txt | 308 +
drivers/Kconfig |1 +
drivers/Makefile |1 +
drivers/rpmsg/Kconfig | 14 +
drivers/rpmsg/Makefile|1 +
drivers/rpmsg/virtio_rpmsg_bus.c | 1036
+
include/linux/mod_devicetable.h | 10 +
include/linux/rpmsg.h | 421
include/linux/virtio_ids.h|1 +
10 files changed, 1868 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-rpmsg
create mode 100644 Documentation/rpmsg.txt
create mode 100644 drivers/rpmsg/Kconfig
create mode 100644 drivers/rpmsg/Makefile
create mode 100644 drivers/rpmsg/virtio_rpmsg_bus.c
create mode 100644 include/linux/rpmsg.h
diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
new file mode 100644
index 000..0a7c820
--- /dev/null
+++ b/Documentation/rpmsg.txt
[...]
Great documentation! Thanks!
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 1f6d6d3..840f835 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -128,4 +128,5 @@ source drivers/clocksource/Kconfig
source drivers/remoteproc/Kconfig
+source drivers/rpmsg/Kconfig
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 4d53a18..2980a15 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_ARM_AMBA) += amba/
obj-$(CONFIG_DMA_ENGINE) += dma/
obj-$(CONFIG_VIRTIO) += virtio/
+obj-$(CONFIG_RPMSG) += rpmsg/
obj-$(CONFIG_XEN)+= xen/
# regulators early, since some subsystems rely on them to initialize
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
new file mode 100644
index 000..41303f5
--- /dev/null
+++ b/drivers/rpmsg/Kconfig
@@ -0,0 +1,14 @@
+# RPMSG always gets selected by whoever wants it
+config RPMSG
+ tristate
+ select VIRTIO
+ select VIRTIO_RING
+
+if RPMSG
+
+# OK, it's a little counter-intuitive to do this, but it puts it neatly under
+# the rpmsg menu (and it's the approach preferred by the virtio folks).
+
+source drivers/virtio/Kconfig
What happens when kvm and rpmsg both get enabled on the same kernel.
ARM virtualization is currently being worked on, so it will happen.
Also, I can see this finding use in the x86 world to talk to
coprocessor boards (like the Xilinx FPGA plugin board which can have a
soft core on it).
+
+endif # RPMSG
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
new file mode 100644
index 000..7617fcb
--- /dev/null
+++ b/drivers/rpmsg/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_RPMSG) += virtio_rpmsg_bus.o
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
b/drivers/rpmsg/virtio_rpmsg_bus.c
new file mode 100644
index 000..3e98b02
--- /dev/null
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
[...]
+/* rpmsg devices and drivers are matched using the service name */
+static inline int rpmsg_id_match(const struct rpmsg_channel *rpdev,
+ const struct rpmsg_device_id *id)
+{
+ if (strncmp(id-name, rpdev-id.name, RPMSG_NAME_SIZE))
+ return 0;
+
+ return 1;
+}
or simply: 'return strncmp(id-name, rpdev-id.name, RPMSG_NAME_SIZE) == 0;'
:-)
+/* for more info, see below documentation of rpmsg_create_ept() */
+static struct rpmsg_endpoint *__rpmsg_create_ept(struct virtproc_info *vrp,
+ struct rpmsg_channel *rpdev,
+ void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
+ void *priv, u32 addr)
+{
+ int err, tmpaddr, request;
+ struct rpmsg_endpoint *ept;
+ struct device *dev = rpdev ? rpdev-dev : vrp-vdev-dev;
+
+ if (!idr_pre_get(vrp-endpoints, GFP_KERNEL))
+ return NULL;
+
+ ept = kzalloc(sizeof(*ept), GFP_KERNEL);
+ if (!ept) {
+ dev_err(dev, failed to kzalloc a new ept\n);
+ return NULL;
+ }
+
+ ept-rpdev = rpdev;
+ ept-cb = cb;
+ ept-priv = priv;
+
+ /* do we need to allocate a local address ? */
+ request = addr == RPMSG_ADDR_ANY ? RPMSG_RESERVED_ADDRESSES : addr;
+
+ spin_lock(vrp-endpoints_lock);
Is a spin_lock the right
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell ru...@rustcorp.com.au wrote:
On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen o...@wizery.com wrote:
Add a virtio-based IPC bus, which enables kernel users to communicate
with remote processors over shared memory using a simple messaging
protocol.
Wow, sometimes one writes a standard and people use it. Thanks!
And we really liked it: virtio_rpmsg_bus.c, the virtio driver which
does most of the magic here ended up pretty small thanks to virtio.
and the performance numbers are really good, too.
+ /* Platform must supply pre-allocated uncached buffers for now */
+ vdev-config-get(vdev, VPROC_BUF_ADDR, addr, sizeof(addr));
+ vdev-config-get(vdev, VPROC_BUF_NUM, num_bufs, sizeof(num_bufs));
+ vdev-config-get(vdev, VPROC_BUF_SZ, buf_size, sizeof(buf_size));
+ vdev-config-get(vdev, VPROC_BUF_PADDR, vrp-phys_base,
+ sizeof(vrp-phys_base));
The normal way is to think of the config space as a structure, and use
offsets rather than using an enum value to distinguish the fields.
Yes, I was (mis-)using the config space for now to talk with
platform-specific code (on the host), and not with the peer, so I
opted for simplicity.
But this is definitely one thing that is going away: I don't see any
reason why not just use dma_alloc_coherent (or even dma_pool_create)
directly from the driver here in order to get those buffers.
+#define RPMSG_NAME_SIZE 32
+#define RPMSG_DEVICE_MODALIAS_FMT rpmsg:%s
+
+struct rpmsg_device_id {
+ char name[RPMSG_NAME_SIZE];
+ kernel_ulong_t driver_data /* Data private to the driver */
+ __attribute__((aligned(sizeof(kernel_ulong_t;
+};
This alignment directive seems overkill...
Yes, looks like I can remove this. thanks.
+#define VIRTIO_ID_RPMSG 10 /* virtio remote processor
messaging */
I think you want 6. Plan 9 jumped ahead to grab 9 :)
6 it is :)
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen o...@wizery.com wrote:
Add a virtio-based IPC bus, which enables kernel users to communicate
with remote processors over shared memory using a simple messaging
protocol.
Wow, sometimes one writes a standard and people use it. Thanks!
I'm still digesting exactly what you're doing, but this is a bit
unconventional:
+ /* Platform must supply pre-allocated uncached buffers for now */
+ vdev-config-get(vdev, VPROC_BUF_ADDR, addr, sizeof(addr));
+ vdev-config-get(vdev, VPROC_BUF_NUM, num_bufs, sizeof(num_bufs));
+ vdev-config-get(vdev, VPROC_BUF_SZ, buf_size, sizeof(buf_size));
+ vdev-config-get(vdev, VPROC_BUF_PADDR, vrp-phys_base,
+ sizeof(vrp-phys_base));
The normal way is to think of the config space as a structure, and use
offsets rather than using an enum value to distinguish the fields.
+#define RPMSG_NAME_SIZE 32
+#define RPMSG_DEVICE_MODALIAS_FMTrpmsg:%s
+
+struct rpmsg_device_id {
+ char name[RPMSG_NAME_SIZE];
+ kernel_ulong_t driver_data /* Data private to the driver */
+ __attribute__((aligned(sizeof(kernel_ulong_t;
+};
This alignment directive seems overkill...
+#define VIRTIO_ID_RPMSG 10 /* virtio remote processor messaging
*/
I think you want 6. Plan 9 jumped ahead to grab 9 :)
Cheers,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Wed, 2011-06-22 at 12:12 +0930, Rusty Russell wrote: +#define VIRTIO_ID_RPMSG10 /* virtio remote processor messaging */ I think you want 6. Plan 9 jumped ahead to grab 9 :) Maybe it's worth adding an appendix to the virtio spec as part of this (and really any) patch series which takes a virtio ID. Also, I understand that virtio itself as an idea isn't Linux specific, but maybe it's worth including the spec (or at least a variation of it) as part of the kernel documentation. -- Sasha. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
