| 1 | ============================================
|
| 2 | Remote Processor Messaging (rpmsg) Framework
|
| 3 | ============================================
|
| 4 |
|
| 5 | .. note::
|
| 6 |
|
| 7 | This document describes the rpmsg bus and how to write rpmsg drivers.
|
| 8 | To learn how to add rpmsg support for new platforms, check out remoteproc.txt
|
| 9 | (also a resident of Documentation/).
|
| 10 |
|
| 11 | Introduction
|
| 12 | ============
|
| 13 |
|
| 14 | Modern SoCs typically employ heterogeneous remote processor devices in
|
| 15 | asymmetric multiprocessing (AMP) configurations, which may be running
|
| 16 | different instances of operating system, whether it's Linux or any other
|
| 17 | flavor of real-time OS.
|
| 18 |
|
| 19 | OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP.
|
| 20 | Typically, the dual cortex-A9 is running Linux in a SMP configuration,
|
| 21 | and each of the other three cores (two M3 cores and a DSP) is running
|
| 22 | its own instance of RTOS in an AMP configuration.
|
| 23 |
|
| 24 | Typically AMP remote processors employ dedicated DSP codecs and multimedia
|
| 25 | hardware accelerators, and therefore are often used to offload CPU-intensive
|
| 26 | multimedia tasks from the main application processor.
|
| 27 |
|
| 28 | These remote processors could also be used to control latency-sensitive
|
| 29 | sensors, drive random hardware blocks, or just perform background tasks
|
| 30 | while the main CPU is idling.
|
| 31 |
|
| 32 | Users of those remote processors can either be userland apps (e.g. multimedia
|
| 33 | frameworks talking with remote OMX components) or kernel drivers (controlling
|
| 34 | hardware accessible only by the remote processor, reserving kernel-controlled
|
| 35 | resources on behalf of the remote processor, etc..).
|
| 36 |
|
| 37 | Rpmsg is a virtio-based messaging bus that allows kernel drivers to communicate
|
| 38 | with remote processors available on the system. In turn, drivers could then
|
| 39 | expose appropriate user space interfaces, if needed.
|
| 40 |
|
| 41 | When writing a driver that exposes rpmsg communication to userland, please
|
| 42 | keep in mind that remote processors might have direct access to the
|
| 43 | system's physical memory and other sensitive hardware resources (e.g. on
|
| 44 | OMAP4, remote cores and hardware accelerators may have direct access to the
|
| 45 | physical memory, gpio banks, dma controllers, i2c bus, gptimers, mailbox
|
| 46 | devices, hwspinlocks, etc..). Moreover, those remote processors might be
|
| 47 | running RTOS where every task can access the entire memory/devices exposed
|
| 48 | to the processor. To minimize the risks of rogue (or buggy) userland code
|
| 49 | exploiting remote bugs, and by that taking over the system, it is often
|
| 50 | desired to limit userland to specific rpmsg channels (see definition below)
|
| 51 | it can send messages on, and if possible, minimize how much control
|
| 52 | it has over the content of the messages.
|
| 53 |
|
| 54 | Every rpmsg device is a communication channel with a remote processor (thus
|
| 55 | rpmsg devices are called channels). Channels are identified by a textual name
|
| 56 | and have a local ("source") rpmsg address, and remote ("destination") rpmsg
|
| 57 | address.
|
| 58 |
|
| 59 | When a driver starts listening on a channel, its rx callback is bound with
|
| 60 | a unique rpmsg local address (a 32-bit integer). This way when inbound messages
|
| 61 | arrive, the rpmsg core dispatches them to the appropriate driver according
|
| 62 | to their destination address (this is done by invoking the driver's rx handler
|
| 63 | with the payload of the inbound message).
|
| 64 |
|
| 65 |
|
| 66 | User API
|
| 67 | ========
|
| 68 |
|
| 69 | ::
|
| 70 |
|
| 71 | int rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
|
| 72 |
|
| 73 | sends a message across to the remote processor from the given endpoint.
|
| 74 | The caller should specify the endpoint, the data it wants to send,
|
| 75 | and its length (in bytes). The message will be sent on the specified
|
| 76 | endpoint's channel, i.e. its source and destination address fields will be
|
| 77 | respectively set to the endpoint's src address and its parent channel
|
| 78 | dst addresses.
|
| 79 |
|
| 80 | In case there are no TX buffers available, the function will block until
|
| 81 | one becomes available (i.e. until the remote processor consumes
|
| 82 | a tx buffer and puts it back on virtio's used descriptor ring),
|
| 83 | or a timeout of 15 seconds elapses. When the latter happens,
|
| 84 | -ERESTARTSYS is returned.
|
| 85 |
|
| 86 | The function can only be called from a process context (for now).
|
| 87 | Returns 0 on success and an appropriate error value on failure.
|
| 88 |
|
| 89 | ::
|
| 90 |
|
| 91 | int rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len, u32 dst);
|
| 92 |
|
| 93 | sends a message across to the remote processor from a given endpoint,
|
| 94 | to a destination address provided by the caller.
|
| 95 |
|
| 96 | The caller should specify the endpoint, the data it wants to send,
|
| 97 | its length (in bytes), and an explicit destination address.
|
| 98 |
|
| 99 | The message will then be sent to the remote processor to which the
|
| 100 | endpoints's channel belongs, using the endpoints's src address,
|
| 101 | and the user-provided dst address (thus the channel's dst address
|
| 102 | will be ignored).
|
| 103 |
|
| 104 | In case there are no TX buffers available, the function will block until
|
| 105 | one becomes available (i.e. until the remote processor consumes
|
| 106 | a tx buffer and puts it back on virtio's used descriptor ring),
|
| 107 | or a timeout of 15 seconds elapses. When the latter happens,
|
| 108 | -ERESTARTSYS is returned.
|
| 109 |
|
| 110 | The function can only be called from a process context (for now).
|
| 111 | Returns 0 on success and an appropriate error value on failure.
|
| 112 |
|
| 113 | ::
|
| 114 |
|
| 115 | int rpmsg_trysend(struct rpmsg_endpoint *ept, void *data, int len);
|
| 116 |
|
| 117 | sends a message across to the remote processor from a given endpoint.
|
| 118 | The caller should specify the endpoint, the data it wants to send,
|
| 119 | and its length (in bytes). The message will be sent on the specified
|
| 120 | endpoint's channel, i.e. its source and destination address fields will be
|
| 121 | respectively set to the endpoint's src address and its parent channel
|
| 122 | dst addresses.
|
| 123 |
|
| 124 | In case there are no TX buffers available, the function will immediately
|
| 125 | return -ENOMEM without waiting until one becomes available.
|
| 126 |
|
| 127 | The function can only be called from a process context (for now).
|
| 128 | Returns 0 on success and an appropriate error value on failure.
|
| 129 |
|
| 130 | ::
|
| 131 |
|
| 132 | int rpmsg_trysendto(struct rpmsg_endpoint *ept, void *data, int len, u32 dst)
|
| 133 |
|
| 134 |
|
| 135 | sends a message across to the remote processor from a given endpoint,
|
| 136 | to a destination address provided by the user.
|
| 137 |
|
| 138 | The user should specify the channel, the data it wants to send,
|
| 139 | its length (in bytes), and an explicit destination address.
|
| 140 |
|
| 141 | The message will then be sent to the remote processor to which the
|
| 142 | channel belongs, using the channel's src address, and the user-provided
|
| 143 | dst address (thus the channel's dst address will be ignored).
|
| 144 |
|
| 145 | In case there are no TX buffers available, the function will immediately
|
| 146 | return -ENOMEM without waiting until one becomes available.
|
| 147 |
|
| 148 | The function can only be called from a process context (for now).
|
| 149 | Returns 0 on success and an appropriate error value on failure.
|
| 150 |
|
| 151 | ::
|
| 152 |
|
| 153 | struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
|
| 154 | rpmsg_rx_cb_t cb, void *priv,
|
| 155 | struct rpmsg_channel_info chinfo);
|
| 156 |
|
| 157 | every rpmsg address in the system is bound to an rx callback (so when
|
| 158 | inbound messages arrive, they are dispatched by the rpmsg bus using the
|
| 159 | appropriate callback handler) by means of an rpmsg_endpoint struct.
|
| 160 |
|
| 161 | This function allows drivers to create such an endpoint, and by that,
|
| 162 | bind a callback, and possibly some private data too, to an rpmsg address
|
| 163 | (either one that is known in advance, or one that will be dynamically
|
| 164 | assigned for them).
|
| 165 |
|
| 166 | Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint
|
| 167 | is already created for them when they are probed by the rpmsg bus
|
| 168 | (using the rx callback they provide when they registered to the rpmsg bus).
|
| 169 |
|
| 170 | So things should just work for simple drivers: they already have an
|
| 171 | endpoint, their rx callback is bound to their rpmsg address, and when
|
| 172 | relevant inbound messages arrive (i.e. messages which their dst address
|
| 173 | equals to the src address of their rpmsg channel), the driver's handler
|
| 174 | is invoked to process it.
|
| 175 |
|
| 176 | That said, more complicated drivers might do need to allocate
|
| 177 | additional rpmsg addresses, and bind them to different rx callbacks.
|
| 178 | To accomplish that, those drivers need to call this function.
|
| 179 | Drivers should provide their channel (so the new endpoint would bind
|
| 180 | to the same remote processor their channel belongs to), an rx callback
|
| 181 | function, an optional private data (which is provided back when the
|
| 182 | rx callback is invoked), and an address they want to bind with the
|
| 183 | callback. If addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will
|
| 184 | dynamically assign them an available rpmsg address (drivers should have
|
| 185 | a very good reason why not to always use RPMSG_ADDR_ANY here).
|
| 186 |
|
| 187 | Returns a pointer to the endpoint on success, or NULL on error.
|
| 188 |
|
| 189 | ::
|
| 190 |
|
| 191 | void rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
|
| 192 |
|
| 193 |
|
| 194 | destroys an existing rpmsg endpoint. user should provide a pointer
|
| 195 | to an rpmsg endpoint that was previously created with rpmsg_create_ept().
|
| 196 |
|
| 197 | ::
|
| 198 |
|
| 199 | int register_rpmsg_driver(struct rpmsg_driver *rpdrv);
|
| 200 |
|
| 201 |
|
| 202 | registers an rpmsg driver with the rpmsg bus. user should provide
|
| 203 | a pointer to an rpmsg_driver struct, which contains the driver's
|
| 204 | ->probe() and ->remove() functions, an rx callback, and an id_table
|
| 205 | specifying the names of the channels this driver is interested to
|
| 206 | be probed with.
|
| 207 |
|
| 208 | ::
|
| 209 |
|
| 210 | void unregister_rpmsg_driver(struct rpmsg_driver *rpdrv);
|
| 211 |
|
| 212 |
|
| 213 | unregisters an rpmsg driver from the rpmsg bus. user should provide
|
| 214 | a pointer to a previously-registered rpmsg_driver struct.
|
| 215 |
|
| 216 |
|
| 217 | Typical usage
|
| 218 | =============
|
| 219 |
|
| 220 | The following is a simple rpmsg driver, that sends an "hello!" message
|
| 221 | on probe(), and whenever it receives an incoming message, it dumps its
|
| 222 | content to the console.
|
| 223 |
|
| 224 | ::
|
| 225 |
|
| 226 | #include <linux/dev_printk.h>
|
| 227 | #include <linux/mod_devicetable.h>
|
| 228 | #include <linux/module.h>
|
| 229 | #include <linux/printk.h>
|
| 230 | #include <linux/rpmsg.h>
|
| 231 | #include <linux/types.h>
|
| 232 |
|
| 233 | static void rpmsg_sample_cb(struct rpmsg_channel *rpdev, void *data, int len,
|
| 234 | void *priv, u32 src)
|
| 235 | {
|
| 236 | print_hex_dump(KERN_INFO, "incoming message:", DUMP_PREFIX_NONE,
|
| 237 | 16, 1, data, len, true);
|
| 238 | }
|
| 239 |
|
| 240 | static int rpmsg_sample_probe(struct rpmsg_channel *rpdev)
|
| 241 | {
|
| 242 | int err;
|
| 243 |
|
| 244 | dev_info(&rpdev->dev, "chnl: 0x%x -> 0x%x\n", rpdev->src, rpdev->dst);
|
| 245 |
|
| 246 | /* send a message on our channel */
|
| 247 | err = rpmsg_send(rpdev->ept, "hello!", 6);
|
| 248 | if (err) {
|
| 249 | dev_err(&rpdev->dev, "rpmsg_send failed: %d\n", err);
|
| 250 | return err;
|
| 251 | }
|
| 252 |
|
| 253 | return 0;
|
| 254 | }
|
| 255 |
|
| 256 | static void rpmsg_sample_remove(struct rpmsg_channel *rpdev)
|
| 257 | {
|
| 258 | dev_info(&rpdev->dev, "rpmsg sample client driver is removed\n");
|
| 259 | }
|
| 260 |
|
| 261 | static struct rpmsg_device_id rpmsg_driver_sample_id_table[] = {
|
| 262 | { .name = "rpmsg-client-sample" },
|
| 263 | { },
|
| 264 | };
|
| 265 | MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_sample_id_table);
|
| 266 |
|
| 267 | static struct rpmsg_driver rpmsg_sample_client = {
|
| 268 | .drv.name = KBUILD_MODNAME,
|
| 269 | .id_table = rpmsg_driver_sample_id_table,
|
| 270 | .probe = rpmsg_sample_probe,
|
| 271 | .callback = rpmsg_sample_cb,
|
| 272 | .remove = rpmsg_sample_remove,
|
| 273 | };
|
| 274 | module_rpmsg_driver(rpmsg_sample_client);
|
| 275 |
|
| 276 | .. note::
|
| 277 |
|
| 278 | a similar sample which can be built and loaded can be found
|
| 279 | in samples/rpmsg/.
|
| 280 |
|
| 281 | Allocations of rpmsg channels
|
| 282 | =============================
|
| 283 |
|
| 284 | At this point we only support dynamic allocations of rpmsg channels.
|
| 285 |
|
| 286 | This is possible only with remote processors that have the VIRTIO_RPMSG_F_NS
|
| 287 | virtio device feature set. This feature bit means that the remote
|
| 288 | processor supports dynamic name service announcement messages.
|
| 289 |
|
| 290 | When this feature is enabled, creation of rpmsg devices (i.e. channels)
|
| 291 | is completely dynamic: the remote processor announces the existence of a
|
| 292 | remote rpmsg service by sending a name service message (which contains
|
| 293 | the name and rpmsg addr of the remote service, see struct rpmsg_ns_msg).
|
| 294 |
|
| 295 | This message is then handled by the rpmsg bus, which in turn dynamically
|
| 296 | creates and registers an rpmsg channel (which represents the remote service).
|
| 297 | If/when a relevant rpmsg driver is registered, it will be immediately probed
|
| 298 | by the bus, and can then start sending messages to the remote service.
|
| 299 |
|
| 300 | The plan is also to add static creation of rpmsg channels via the virtio
|
| 301 | config space, but it's not implemented yet.
|