1
0
Fork 0
alistair23-linux/drivers/remoteproc/remoteproc_virtio.c

363 lines
9.4 KiB
C
Raw Normal View History

remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
/*
* Remote processor messaging transport (OMAP platform-specific bits)
*
* Copyright (C) 2011 Texas Instruments, Inc.
* Copyright (C) 2011 Google, Inc.
*
* Ohad Ben-Cohen <ohad@wizery.com>
* Brian Swetland <swetland@google.com>
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <linux/export.h>
#include <linux/remoteproc.h>
#include <linux/virtio.h>
#include <linux/virtio_config.h>
#include <linux/virtio_ids.h>
#include <linux/virtio_ring.h>
#include <linux/err.h>
#include <linux/kref.h>
#include <linux/slab.h>
#include "remoteproc_internal.h"
/* kick the remote processor, and let it know which virtqueue to poke at */
static bool rproc_virtio_notify(struct virtqueue *vq)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
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>
2012-02-13 14:30:39 -07:00
struct rproc_vring *rvring = vq->priv;
struct rproc *rproc = rvring->rvdev->rproc;
int notifyid = rvring->notifyid;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
remoteproc: maintain a generic child device for each rproc For each registered rproc, maintain a generic remoteproc device whose parent is the low level platform-specific device (commonly a pdev, but it may certainly be any other type of device too). With this in hand, the resulting device hierarchy might then look like: omap-rproc.0 | - remoteproc0 <---- new ! | - virtio0 | - virtio1 | - rpmsg0 | - rpmsg1 | - rpmsg2 Where: - omap-rproc.0 is the low level device that's bound to the driver which invokes rproc_register() - remoteproc0 is the result of this patch, and will be added by the remoteproc framework when rproc_register() is invoked - virtio0 and virtio1 are vdevs that are registered by remoteproc when it realizes that they are supported by the firmware of the physical remote processor represented by omap-rproc.0 - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg channels, and are registerd by the rpmsg bus when it gets notified about their existence Technically, this patch: - changes 'struct rproc' to contain this generic remoteproc.x device - creates a new "remoteproc" type, to which this new generic remoteproc.x device belong to. - adds a super simple enumeration method for the indices of the remoteproc.x devices - updates all dev_* messaging to use the generic remoteproc.x device instead of the low level platform-specific device - updates all dma_* allocations to use the parent of remoteproc.x (where the platform-specific memory pools, most commonly CMA, are to be found) Adding this generic device has several merits: - we can now add remoteproc runtime PM support simply by hooking onto the new "remoteproc" type - all remoteproc log messages will now carry a common name prefix instead of having a platform-specific one - having a device as part of the rproc struct makes it possible to simplify refcounting (see subsequent patch) Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and discussing these ideas in one of the remoteproc review threads and to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out with the (upcoming) runtime PM support for remoteproc. Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-05-30 13:01:25 -06:00
dev_dbg(&rproc->dev, "kicking vq index: %d\n", notifyid);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
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>
2012-02-13 14:30:39 -07:00
rproc->ops->kick(rproc, notifyid);
return true;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
/**
* rproc_vq_interrupt() - tell remoteproc that a virtqueue is interrupted
* @rproc: handle to the remote processor
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>
2012-02-13 14:30:39 -07:00
* @notifyid: index of the signalled virtqueue (unique per this @rproc)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
*
* This function should be called by the platform-specific rproc driver,
* when the remote processor signals that a specific virtqueue has pending
* messages available.
*
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>
2012-02-13 14:30:39 -07:00
* Returns IRQ_NONE if no message was found in the @notifyid virtqueue,
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
* and otherwise returns IRQ_HANDLED.
*/
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>
2012-02-13 14:30:39 -07:00
irqreturn_t rproc_vq_interrupt(struct rproc *rproc, int notifyid)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
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>
2012-02-13 14:30:39 -07:00
struct rproc_vring *rvring;
remoteproc: maintain a generic child device for each rproc For each registered rproc, maintain a generic remoteproc device whose parent is the low level platform-specific device (commonly a pdev, but it may certainly be any other type of device too). With this in hand, the resulting device hierarchy might then look like: omap-rproc.0 | - remoteproc0 <---- new ! | - virtio0 | - virtio1 | - rpmsg0 | - rpmsg1 | - rpmsg2 Where: - omap-rproc.0 is the low level device that's bound to the driver which invokes rproc_register() - remoteproc0 is the result of this patch, and will be added by the remoteproc framework when rproc_register() is invoked - virtio0 and virtio1 are vdevs that are registered by remoteproc when it realizes that they are supported by the firmware of the physical remote processor represented by omap-rproc.0 - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg channels, and are registerd by the rpmsg bus when it gets notified about their existence Technically, this patch: - changes 'struct rproc' to contain this generic remoteproc.x device - creates a new "remoteproc" type, to which this new generic remoteproc.x device belong to. - adds a super simple enumeration method for the indices of the remoteproc.x devices - updates all dev_* messaging to use the generic remoteproc.x device instead of the low level platform-specific device - updates all dma_* allocations to use the parent of remoteproc.x (where the platform-specific memory pools, most commonly CMA, are to be found) Adding this generic device has several merits: - we can now add remoteproc runtime PM support simply by hooking onto the new "remoteproc" type - all remoteproc log messages will now carry a common name prefix instead of having a platform-specific one - having a device as part of the rproc struct makes it possible to simplify refcounting (see subsequent patch) Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and discussing these ideas in one of the remoteproc review threads and to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out with the (upcoming) runtime PM support for remoteproc. Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-05-30 13:01:25 -06:00
dev_dbg(&rproc->dev, "vq index %d is interrupted\n", notifyid);
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>
2012-02-13 14:30:39 -07:00
rvring = idr_find(&rproc->notifyids, notifyid);
if (!rvring || !rvring->vq)
return IRQ_NONE;
return vring_interrupt(0, rvring->vq);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
EXPORT_SYMBOL(rproc_vq_interrupt);
static struct virtqueue *rp_find_vq(struct virtio_device *vdev,
unsigned int id,
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
void (*callback)(struct virtqueue *vq),
const char *name, bool ctx)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
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>
2012-02-13 14:30:39 -07:00
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
struct rproc *rproc = vdev_to_rproc(vdev);
remoteproc: maintain a generic child device for each rproc For each registered rproc, maintain a generic remoteproc device whose parent is the low level platform-specific device (commonly a pdev, but it may certainly be any other type of device too). With this in hand, the resulting device hierarchy might then look like: omap-rproc.0 | - remoteproc0 <---- new ! | - virtio0 | - virtio1 | - rpmsg0 | - rpmsg1 | - rpmsg2 Where: - omap-rproc.0 is the low level device that's bound to the driver which invokes rproc_register() - remoteproc0 is the result of this patch, and will be added by the remoteproc framework when rproc_register() is invoked - virtio0 and virtio1 are vdevs that are registered by remoteproc when it realizes that they are supported by the firmware of the physical remote processor represented by omap-rproc.0 - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg channels, and are registerd by the rpmsg bus when it gets notified about their existence Technically, this patch: - changes 'struct rproc' to contain this generic remoteproc.x device - creates a new "remoteproc" type, to which this new generic remoteproc.x device belong to. - adds a super simple enumeration method for the indices of the remoteproc.x devices - updates all dev_* messaging to use the generic remoteproc.x device instead of the low level platform-specific device - updates all dma_* allocations to use the parent of remoteproc.x (where the platform-specific memory pools, most commonly CMA, are to be found) Adding this generic device has several merits: - we can now add remoteproc runtime PM support simply by hooking onto the new "remoteproc" type - all remoteproc log messages will now carry a common name prefix instead of having a platform-specific one - having a device as part of the rproc struct makes it possible to simplify refcounting (see subsequent patch) Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and discussing these ideas in one of the remoteproc review threads and to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out with the (upcoming) runtime PM support for remoteproc. Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-05-30 13:01:25 -06:00
struct device *dev = &rproc->dev;
struct rproc_mem_entry *mem;
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>
2012-02-13 14:30:39 -07:00
struct rproc_vring *rvring;
struct fw_rsc_vdev *rsc;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
struct virtqueue *vq;
void *addr;
int len, size;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
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>
2012-02-13 14:30:39 -07:00
/* we're temporarily limited to two virtqueues per rvdev */
if (id >= ARRAY_SIZE(rvdev->vring))
return ERR_PTR(-EINVAL);
if (!name)
return NULL;
/* Search allocated memory region by name */
mem = rproc_find_carveout_by_name(rproc, "vdev%dvring%d", rvdev->index,
id);
if (!mem || !mem->va)
return ERR_PTR(-ENOMEM);
rvring = &rvdev->vring[id];
addr = mem->va;
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>
2012-02-13 14:30:39 -07:00
len = rvring->len;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
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>
2012-02-13 14:30:39 -07:00
/* zero vring */
size = vring_size(len, rvring->align);
memset(addr, 0, size);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
dev_dbg(dev, "vring%d: va %pK qsz %d notifyid %d\n",
id, addr, len, rvring->notifyid);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
/*
* Create the new vq, and tell virtio we're not interested in
* the 'weak' smp barriers, since we're talking with a real device.
*/
vq = vring_new_virtqueue(id, len, rvring->align, vdev, false, ctx,
addr, rproc_virtio_notify, callback, name);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
if (!vq) {
remoteproc: maintain a generic child device for each rproc For each registered rproc, maintain a generic remoteproc device whose parent is the low level platform-specific device (commonly a pdev, but it may certainly be any other type of device too). With this in hand, the resulting device hierarchy might then look like: omap-rproc.0 | - remoteproc0 <---- new ! | - virtio0 | - virtio1 | - rpmsg0 | - rpmsg1 | - rpmsg2 Where: - omap-rproc.0 is the low level device that's bound to the driver which invokes rproc_register() - remoteproc0 is the result of this patch, and will be added by the remoteproc framework when rproc_register() is invoked - virtio0 and virtio1 are vdevs that are registered by remoteproc when it realizes that they are supported by the firmware of the physical remote processor represented by omap-rproc.0 - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg channels, and are registerd by the rpmsg bus when it gets notified about their existence Technically, this patch: - changes 'struct rproc' to contain this generic remoteproc.x device - creates a new "remoteproc" type, to which this new generic remoteproc.x device belong to. - adds a super simple enumeration method for the indices of the remoteproc.x devices - updates all dev_* messaging to use the generic remoteproc.x device instead of the low level platform-specific device - updates all dma_* allocations to use the parent of remoteproc.x (where the platform-specific memory pools, most commonly CMA, are to be found) Adding this generic device has several merits: - we can now add remoteproc runtime PM support simply by hooking onto the new "remoteproc" type - all remoteproc log messages will now carry a common name prefix instead of having a platform-specific one - having a device as part of the rproc struct makes it possible to simplify refcounting (see subsequent patch) Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and discussing these ideas in one of the remoteproc review threads and to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out with the (upcoming) runtime PM support for remoteproc. Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-05-30 13:01:25 -06:00
dev_err(dev, "vring_new_virtqueue %s failed\n", name);
rproc_free_vring(rvring);
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>
2012-02-13 14:30:39 -07:00
return ERR_PTR(-ENOMEM);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
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>
2012-02-13 14:30:39 -07:00
rvring->vq = vq;
vq->priv = rvring;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
/* Update vring in resource table */
rsc = (void *)rproc->table_ptr + rvdev->rsc_offset;
rsc->vring[id].da = mem->da;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
return vq;
}
static void __rproc_virtio_del_vqs(struct virtio_device *vdev)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
struct virtqueue *vq, *n;
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>
2012-02-13 14:30:39 -07:00
struct rproc_vring *rvring;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
list_for_each_entry_safe(vq, n, &vdev->vqs, list) {
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>
2012-02-13 14:30:39 -07:00
rvring = vq->priv;
rvring->vq = NULL;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
vring_del_virtqueue(vq);
}
}
static void rproc_virtio_del_vqs(struct virtio_device *vdev)
{
__rproc_virtio_del_vqs(vdev);
}
static int rproc_virtio_find_vqs(struct virtio_device *vdev, unsigned int nvqs,
struct virtqueue *vqs[],
vq_callback_t *callbacks[],
const char * const names[],
const bool * ctx,
struct irq_affinity *desc)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
int i, ret;
for (i = 0; i < nvqs; ++i) {
vqs[i] = rp_find_vq(vdev, i, callbacks[i], names[i],
ctx ? ctx[i] : false);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
if (IS_ERR(vqs[i])) {
ret = PTR_ERR(vqs[i]);
goto error;
}
}
return 0;
error:
__rproc_virtio_del_vqs(vdev);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
return ret;
}
static u8 rproc_virtio_get_status(struct virtio_device *vdev)
{
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct fw_rsc_vdev *rsc;
rsc = (void *)rvdev->rproc->table_ptr + rvdev->rsc_offset;
return rsc->status;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
static void rproc_virtio_set_status(struct virtio_device *vdev, u8 status)
{
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct fw_rsc_vdev *rsc;
rsc = (void *)rvdev->rproc->table_ptr + rvdev->rsc_offset;
rsc->status = status;
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>
2012-02-13 14:30:39 -07:00
dev_dbg(&vdev->dev, "status: %d\n", status);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
static void rproc_virtio_reset(struct virtio_device *vdev)
{
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct fw_rsc_vdev *rsc;
rsc = (void *)rvdev->rproc->table_ptr + rvdev->rsc_offset;
rsc->status = 0;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
dev_dbg(&vdev->dev, "reset !\n");
}
/* provide the vdev features as retrieved from the firmware */
static u64 rproc_virtio_get_features(struct virtio_device *vdev)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
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>
2012-02-13 14:30:39 -07:00
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct fw_rsc_vdev *rsc;
rsc = (void *)rvdev->rproc->table_ptr + rvdev->rsc_offset;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
return rsc->dfeatures;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
static int rproc_virtio_finalize_features(struct virtio_device *vdev)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
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>
2012-02-13 14:30:39 -07:00
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct fw_rsc_vdev *rsc;
rsc = (void *)rvdev->rproc->table_ptr + rvdev->rsc_offset;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
/* Give virtio_ring a chance to accept features */
vring_transport_features(vdev);
/* Make sure we don't have any features > 32 bits! */
BUG_ON((u32)vdev->features != vdev->features);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
/*
* Remember the finalized features of our vdev, and provide it
* to the remote processor once it is powered on.
*/
rsc->gfeatures = vdev->features;
return 0;
}
static void rproc_virtio_get(struct virtio_device *vdev, unsigned int offset,
void *buf, unsigned int len)
{
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct fw_rsc_vdev *rsc;
void *cfg;
rsc = (void *)rvdev->rproc->table_ptr + rvdev->rsc_offset;
cfg = &rsc->vring[rsc->num_of_vrings];
if (offset + len > rsc->config_len || offset + len < len) {
dev_err(&vdev->dev, "rproc_virtio_get: access out of bounds\n");
return;
}
memcpy(buf, cfg + offset, len);
}
static void rproc_virtio_set(struct virtio_device *vdev, unsigned int offset,
const void *buf, unsigned int len)
{
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct fw_rsc_vdev *rsc;
void *cfg;
rsc = (void *)rvdev->rproc->table_ptr + rvdev->rsc_offset;
cfg = &rsc->vring[rsc->num_of_vrings];
if (offset + len > rsc->config_len || offset + len < len) {
dev_err(&vdev->dev, "rproc_virtio_set: access out of bounds\n");
return;
}
memcpy(cfg + offset, buf, len);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
static const struct virtio_config_ops rproc_virtio_config_ops = {
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
.get_features = rproc_virtio_get_features,
.finalize_features = rproc_virtio_finalize_features,
.find_vqs = rproc_virtio_find_vqs,
.del_vqs = rproc_virtio_del_vqs,
.reset = rproc_virtio_reset,
.set_status = rproc_virtio_set_status,
.get_status = rproc_virtio_get_status,
.get = rproc_virtio_get,
.set = rproc_virtio_set,
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
};
/*
* This function is called whenever vdev is released, and is responsible
* to decrement the remote processor's refcount which was taken when vdev was
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
* added.
*
* Never call this function directly; it will be called by the driver
* core when needed.
*/
static void rproc_virtio_dev_release(struct device *dev)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
struct virtio_device *vdev = dev_to_virtio(dev);
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
struct rproc *rproc = vdev_to_rproc(vdev);
kref_put(&rvdev->refcount, rproc_vdev_release);
put_device(&rproc->dev);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
/**
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>
2012-02-13 14:30:39 -07:00
* rproc_add_virtio_dev() - register an rproc-induced virtio device
* @rvdev: the remote vdev
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
*
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>
2012-02-13 14:30:39 -07:00
* This function registers a virtio device. This vdev's partent is
* the rproc device.
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
*
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>
2012-02-13 14:30:39 -07:00
* Returns 0 on success or an appropriate error value otherwise.
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
*/
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>
2012-02-13 14:30:39 -07:00
int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
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>
2012-02-13 14:30:39 -07:00
struct rproc *rproc = rvdev->rproc;
remoteproc: maintain a generic child device for each rproc For each registered rproc, maintain a generic remoteproc device whose parent is the low level platform-specific device (commonly a pdev, but it may certainly be any other type of device too). With this in hand, the resulting device hierarchy might then look like: omap-rproc.0 | - remoteproc0 <---- new ! | - virtio0 | - virtio1 | - rpmsg0 | - rpmsg1 | - rpmsg2 Where: - omap-rproc.0 is the low level device that's bound to the driver which invokes rproc_register() - remoteproc0 is the result of this patch, and will be added by the remoteproc framework when rproc_register() is invoked - virtio0 and virtio1 are vdevs that are registered by remoteproc when it realizes that they are supported by the firmware of the physical remote processor represented by omap-rproc.0 - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg channels, and are registerd by the rpmsg bus when it gets notified about their existence Technically, this patch: - changes 'struct rproc' to contain this generic remoteproc.x device - creates a new "remoteproc" type, to which this new generic remoteproc.x device belong to. - adds a super simple enumeration method for the indices of the remoteproc.x devices - updates all dev_* messaging to use the generic remoteproc.x device instead of the low level platform-specific device - updates all dma_* allocations to use the parent of remoteproc.x (where the platform-specific memory pools, most commonly CMA, are to be found) Adding this generic device has several merits: - we can now add remoteproc runtime PM support simply by hooking onto the new "remoteproc" type - all remoteproc log messages will now carry a common name prefix instead of having a platform-specific one - having a device as part of the rproc struct makes it possible to simplify refcounting (see subsequent patch) Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and discussing these ideas in one of the remoteproc review threads and to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out with the (upcoming) runtime PM support for remoteproc. Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-05-30 13:01:25 -06:00
struct device *dev = &rproc->dev;
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>
2012-02-13 14:30:39 -07:00
struct virtio_device *vdev = &rvdev->vdev;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
int ret;
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>
2012-02-13 14:30:39 -07:00
vdev->id.device = id,
vdev->config = &rproc_virtio_config_ops,
vdev->dev.parent = dev;
vdev->dev.release = rproc_virtio_dev_release;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
/*
* We're indirectly making a non-temporary copy of the rproc pointer
* here, because drivers probed with this vdev will indirectly
* access the wrapping rproc.
*
* Therefore we must increment the rproc refcount here, and decrement
* it _only_ when the vdev is released.
*/
get_device(&rproc->dev);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
/* Reference the vdev and vring allocations */
kref_get(&rvdev->refcount);
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>
2012-02-13 14:30:39 -07:00
ret = register_virtio_device(vdev);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
if (ret) {
put_device(&vdev->dev);
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
dev_err(dev, "failed to register vdev: %d\n", ret);
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>
2012-02-13 14:30:39 -07:00
goto out;
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
}
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>
2012-02-13 14:30:39 -07:00
dev_info(dev, "registered %s (type %d)\n", dev_name(&vdev->dev), id);
out:
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
return ret;
}
/**
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>
2012-02-13 14:30:39 -07:00
* rproc_remove_virtio_dev() - remove an rproc-induced virtio device
* @rvdev: the remote vdev
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
*
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>
2012-02-13 14:30:39 -07:00
* This function unregisters an existing virtio device.
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
*/
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>
2012-02-13 14:30:39 -07:00
void rproc_remove_virtio_dev(struct rproc_vdev *rvdev)
remoteproc: create rpmsg virtio device 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>
2011-10-20 10:15:13 -06:00
{
unregister_virtio_device(&rvdev->vdev);
}