Lines Matching refs:and

9 OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP.
11 configuration, and each of the other three cores (two M3 cores and a DSP)
20 handlers, and then all rpmsg drivers will then just work
21 (for more information about the virtio-based rpmsg bus and its drivers,
24 just need to publish what kind of virtio devices do they support, and then
35       Returns 0 on success, and an appropriate error value otherwise.
44       this function will just decrement the power refcount and exit,
51         rproc_shutdown() returns, and users can still use it with a subsequent
63 	/* let's power on and boot our remote processor */
67 		 * something went wrong. handle it and leave.
87       the name of the firmware to boot this rproc with, and the
92       After creating an rproc handle using this function, and when ready,
95       On success, the new rproc is returned, and on failure, NULL.
104       only if there are no other references to rproc and its refcount now
112       Returns 0 on success and an appropriate error code otherwise.
116       If found, those virtio devices will be created and added, so as a result
127       After rproc_del() returns, @rproc is still valid, and its
130       Returns 0 on success and -EINVAL if @rproc isn't valid.
146  * @start:	power on the device and boot it
156 Every remoteproc implementation should at least provide the ->start and ->stop
160 The ->start() handler takes an rproc handle and should then power on the
161 device and boot it (use rproc->priv to access platform-specific private data).
164 On success, 0 should be returned, and on failure, an appropriate error code.
166 The ->stop() handler takes an rproc handle and powers the device down.
167 On success, 0 is returned, and on failure, an appropriate error code.
169 The ->kick() handler takes an rproc handle, and an index of a virtqueue
171 processor and let it know it has pending messages. Notifying remote processors
172 the exact virtqueue index to look in is optional: it is easy (and not
173 too expensive) to go through the existing virtqueues and look for new buffers
201 or configurations by the remote processor, such as trace buffers and
202 supported virtio devices (and their configurations).
215  * future), the number of available resource entries, and their offsets
235  * this header, and it should be parsed according to the resource type.
245 is expected, where the firmware requests a resource, and once allocated,
259  * @RSC_VDEV:       declare support for a virtio device, and serve as its
281 type, and hand those resources to the platform-specific rproc driver to handle.
283 7. Virtio and remoteproc
286 that it supports, and their configurations: a RSC_VDEV resource entry
291 will look for its resource table and will register the virtio devices
292 it supports. A firmware may support any number of virtio devices, and