zephyr/include/ipm.h

16 lines
322 B
C
Raw Normal View History

ipi.h: introduce low-level inter-processor interrupt API This interface is an abstraction for sending messages between processors with irq-context callbacks and no definition of protocol. We assume that for all IPC implementations, we can send over a message identifier and a sized data payload, and that the receiving side gets an interrupt on an incoming message. APIs exist to indicate the max value of the message id and how much data can be sent over a single message. This will be a foundation to build various high-level drivers which can be bound at runtime to this low-level interface. Some examples: * IPC where IPC messages are used as a doorbell to signal new data in a shared queue * IPC with various kinds of message buffering and deferred message processing via semaphores * IPC for serial console debug output, either a byte or a message at a time * IPC over UARTS in a non-shared memory environment where large-ish messages are exchanged * Shared memory IPC where data pointers are exchanged and a protocol for freeing the data once the receiver is done with it The size parameter passed to ipc_send() isn't propagated to the receiving side. The receiver needs to infer how many bytes of data to read in the callback function based on the protocol implemented in the high-level driver; it can be based on message ID, or bits reserved in the message ID for the message size, or some other mechanism. Change-Id: I9a9529beb61cdebdfb1bafd29d037f926fab3c1b Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2015-09-03 01:38:38 +02:00
/*
* Copyright (c) 2019 Intel Corporation
ipi.h: introduce low-level inter-processor interrupt API This interface is an abstraction for sending messages between processors with irq-context callbacks and no definition of protocol. We assume that for all IPC implementations, we can send over a message identifier and a sized data payload, and that the receiving side gets an interrupt on an incoming message. APIs exist to indicate the max value of the message id and how much data can be sent over a single message. This will be a foundation to build various high-level drivers which can be bound at runtime to this low-level interface. Some examples: * IPC where IPC messages are used as a doorbell to signal new data in a shared queue * IPC with various kinds of message buffering and deferred message processing via semaphores * IPC for serial console debug output, either a byte or a message at a time * IPC over UARTS in a non-shared memory environment where large-ish messages are exchanged * Shared memory IPC where data pointers are exchanged and a protocol for freeing the data once the receiver is done with it The size parameter passed to ipc_send() isn't propagated to the receiving side. The receiver needs to infer how many bytes of data to read in the callback function based on the protocol implemented in the high-level driver; it can be based on message ID, or bits reserved in the message ID for the message size, or some other mechanism. Change-Id: I9a9529beb61cdebdfb1bafd29d037f926fab3c1b Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2015-09-03 01:38:38 +02:00
*
* SPDX-License-Identifier: Apache-2.0
ipi.h: introduce low-level inter-processor interrupt API This interface is an abstraction for sending messages between processors with irq-context callbacks and no definition of protocol. We assume that for all IPC implementations, we can send over a message identifier and a sized data payload, and that the receiving side gets an interrupt on an incoming message. APIs exist to indicate the max value of the message id and how much data can be sent over a single message. This will be a foundation to build various high-level drivers which can be bound at runtime to this low-level interface. Some examples: * IPC where IPC messages are used as a doorbell to signal new data in a shared queue * IPC with various kinds of message buffering and deferred message processing via semaphores * IPC for serial console debug output, either a byte or a message at a time * IPC over UARTS in a non-shared memory environment where large-ish messages are exchanged * Shared memory IPC where data pointers are exchanged and a protocol for freeing the data once the receiver is done with it The size parameter passed to ipc_send() isn't propagated to the receiving side. The receiver needs to infer how many bytes of data to read in the callback function based on the protocol implemented in the high-level driver; it can be based on message ID, or bits reserved in the message ID for the message size, or some other mechanism. Change-Id: I9a9529beb61cdebdfb1bafd29d037f926fab3c1b Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2015-09-03 01:38:38 +02:00
*/
#ifndef ZEPHYR_INCLUDE_IPM_H_
#define ZEPHYR_INCLUDE_IPM_H_
ipi.h: introduce low-level inter-processor interrupt API This interface is an abstraction for sending messages between processors with irq-context callbacks and no definition of protocol. We assume that for all IPC implementations, we can send over a message identifier and a sized data payload, and that the receiving side gets an interrupt on an incoming message. APIs exist to indicate the max value of the message id and how much data can be sent over a single message. This will be a foundation to build various high-level drivers which can be bound at runtime to this low-level interface. Some examples: * IPC where IPC messages are used as a doorbell to signal new data in a shared queue * IPC with various kinds of message buffering and deferred message processing via semaphores * IPC for serial console debug output, either a byte or a message at a time * IPC over UARTS in a non-shared memory environment where large-ish messages are exchanged * Shared memory IPC where data pointers are exchanged and a protocol for freeing the data once the receiver is done with it The size parameter passed to ipc_send() isn't propagated to the receiving side. The receiver needs to infer how many bytes of data to read in the callback function based on the protocol implemented in the high-level driver; it can be based on message ID, or bits reserved in the message ID for the message size, or some other mechanism. Change-Id: I9a9529beb61cdebdfb1bafd29d037f926fab3c1b Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2015-09-03 01:38:38 +02:00
#ifndef CONFIG_COMPAT_INCLUDES
#warning "This header file has moved, include <drivers/ipm.h> instead."
#endif
#include <drivers/ipm.h>
#endif /* ZEPHYR_INCLUDE_IPM_H_ */