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
56       handle on success, and NULL on failure. This function increments
69 	/* let's power on and boot our remote processor */
73 		 * something went wrong. handle it and leave.
93       the name of the firmware to boot this rproc with, and the
98       After creating an rproc handle using this function, and when ready,
101       On success, the new rproc is returned, and on failure, NULL.
110       only if there are no other references to rproc and its refcount now
118       Returns 0 on success and an appropriate error code otherwise.
122       If found, those virtio devices will be created and added, so as a result
133       After rproc_del() returns, @rproc is still valid, and its
136       Returns 0 on success and -EINVAL if @rproc isn't valid.
152  * @start:	power on the device and boot it
162 Every remoteproc implementation should at least provide the ->start and ->stop
166 The ->start() handler takes an rproc handle and should then power on the
167 device and boot it (use rproc->priv to access platform-specific private data).
170 On success, 0 should be returned, and on failure, an appropriate error code.
172 The ->stop() handler takes an rproc handle and powers the device down.
173 On success, 0 is returned, and on failure, an appropriate error code.
175 The ->kick() handler takes an rproc handle, and an index of a virtqueue
177 processor and let it know it has pending messages. Notifying remote processors
178 the exact virtqueue index to look in is optional: it is easy (and not
179 too expensive) to go through the existing virtqueues and look for new buffers
207 or configurations by the remote processor, such as trace buffers and
208 supported virtio devices (and their configurations).
221  * future), the number of available resource entries, and their offsets
241  * this header, and it should be parsed according to the resource type.
251 is expected, where the firmware requests a resource, and once allocated,
265  * @RSC_VDEV:       declare support for a virtio device, and serve as its
287 type, and hand those resources to the platform-specific rproc driver to handle.
289 7. Virtio and remoteproc
292 that it supports, and their configurations: a RSC_VDEV resource entry
297 will look for its resource table and will register the virtio devices
298 it supports. A firmware may support any number of virtio devices, and