zephyr/include/ipm.h

214 lines
6.2 KiB
C
Raw Normal View History

/**
* @file
*
* @brief Generic low-level inter-processor mailbox communication API.
*/
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 07:38:38 +08:00
/*
* Copyright (c) 2015 Intel Corporation
*
* 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 07:38:38 +08:00
*/
#ifndef __INCipmh
#define __INCipmh
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 07:38:38 +08:00
/**
* @brief IPM Interface
* @defgroup ipm_interface IPM Interface
* @ingroup io_interfaces
* @{
*/
#include <kernel.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 07:38:38 +08:00
#include <device.h>
#ifdef __cplusplus
extern "C" {
#endif
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 07:38:38 +08:00
/**
* @typedef ipm_callback_t
* @brief Callback API for incoming IPM messages
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 07:38:38 +08:00
*
* These callbacks execute in interrupt context. Therefore, use only
* interrupt-safe APIS. Registration of callbacks is done via
* @a ipm_register_callback
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 07:38:38 +08:00
*
* @param "void *context" Arbitrary context pointer provided at
* registration time.
* @param "uint32_t id" Message type identifier.
* @param "volatile void *data" Message data pointer. The correct
* amount of data to read out
* must be inferred using the message id/upper level protocol.
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 07:38:38 +08:00
*/
typedef void (*ipm_callback_t)(void *context, uint32_t id, volatile void *data);
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 07:38:38 +08:00
/**
* @typedef ipm_send_t
* @brief Callback API to send IPM messages
*
* See @a ipm_send() for argument definitions.
*/
typedef int (*ipm_send_t)(struct device *ipmdev, int wait, uint32_t id,
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 07:38:38 +08:00
const void *data, int size);
/**
* @typedef ipm_max_data_size_get_t
* @brief Callback API to get maximum data size
*
* See @a ipm_max_data_size_get() for argument definitions.
*/
typedef int (*ipm_max_data_size_get_t)(struct device *ipmdev);
/**
* @typedef ipm_max_id_val_get_t
* @brief Callback API to get the ID's maximum value
*
* See @a ipm_max_id_val_get() for argument definitions.
*/
typedef uint32_t (*ipm_max_id_val_get_t)(struct device *ipmdev);
/**
* @typedef ipm_register_callback_t
* @brief Callback API upon registration
*
* See @a ipm_register_callback() for argument definitions.
*/
typedef void (*ipm_register_callback_t)(struct device *port, ipm_callback_t cb,
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 07:38:38 +08:00
void *cb_context);
/**
* @typedef ipm_set_enabled_t
* @brief Callback API upon emablement of interrupts
*
* See @a ipm_set_enabled() for argument definitions.
*/
typedef int (*ipm_set_enabled_t)(struct device *ipmdev, int enable);
struct ipm_driver_api {
ipm_send_t send;
ipm_register_callback_t register_callback;
ipm_max_data_size_get_t max_data_size_get;
ipm_max_id_val_get_t max_id_val_get;
ipm_set_enabled_t set_enabled;
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 07:38:38 +08:00
};
/**
* @brief Try to send a message over the IPM device.
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 07:38:38 +08:00
*
* A message is considered consumed once the remote interrupt handler
* finishes. If there is deferred processing on the remote side,
* or if outgoing messages must be queued and wait on an
* event/semaphore, a high-level driver can implement that.
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 07:38:38 +08:00
*
* There are constraints on how much data can be sent or the maximum value
* of id. Use the @a ipm_max_data_size_get and @a ipm_max_id_val_get routines
* to determine them.
*
* The @a size parameter is used only on the sending side to determine
* the amount of data to put in the message registers. It is not passed along
* to the receiving side. The upper-level protocol dictates the amount of
* data read back.
*
* @param ipmdev Driver instance
* @param wait If nonzero, busy-wait for remote to consume the message. The
* message is considered consumed once the remote interrupt handler
* finishes. If there is deferred processing on the remote side,
* or you would like to queue outgoing messages and wait on an
* event/semaphore, you can implement that in a high-level driver
* @param id Message identifier. Values are constrained by
* @a ipm_max_data_size_get since many boards only allow for a
* subset of bits in a 32-bit register to store the ID.
* @param data Pointer to the data sent in the message.
* @param size Size of the data.
*
* @retval EBUSY If the remote hasn't yet read the last data sent.
* @retval EMSGSIZE If the supplied data size is unsupported by the driver.
* @retval EINVAL If there was a bad parameter, such as: too-large id value.
* or the device isn't an outbound IPM channel.
* @retval 0 On success.
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 07:38:38 +08:00
*/
static inline int ipm_send(struct device *ipmdev, int wait, uint32_t id,
const void *data, int size)
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 07:38:38 +08:00
{
const struct ipm_driver_api *api = ipmdev->driver_api;
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 07:38:38 +08:00
return api->send(ipmdev, wait, id, data, size);
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 07:38:38 +08:00
}
/**
* @brief Register a callback function for incoming messages.
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 07:38:38 +08:00
*
* @param ipmdev Driver instance pointer.
* @param cb Callback function to execute on incoming message interrupts.
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 07:38:38 +08:00
* @param context Application-specific context pointer which will be passed
* to the callback function when executed.
*/
static inline void ipm_register_callback(struct device *ipmdev,
ipm_callback_t cb, void *context)
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 07:38:38 +08:00
{
const struct ipm_driver_api *api = ipmdev->driver_api;
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 07:38:38 +08:00
api->register_callback(ipmdev, cb, context);
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 07:38:38 +08:00
}
/**
* @brief Return the maximum number of bytes possible in an outbound message.
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 07:38:38 +08:00
*
* IPM implementations vary on the amount of data that can be sent in a
* single message since the data payload is typically stored in registers.
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 07:38:38 +08:00
*
* @param ipmdev Driver instance pointer.
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 07:38:38 +08:00
*
* @return Maximum possible size of a message in bytes.
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 07:38:38 +08:00
*/
static inline int ipm_max_data_size_get(struct device *ipmdev)
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 07:38:38 +08:00
{
const struct ipm_driver_api *api = ipmdev->driver_api;
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 07:38:38 +08:00
return api->max_data_size_get(ipmdev);
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 07:38:38 +08:00
}
/**
* @brief Return the maximum id value possible in an outbound message.
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 07:38:38 +08:00
*
* Many IPM implementations store the message's ID in a register with
* some bits reserved for other uses.
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 07:38:38 +08:00
*
* @param ipmdev Driver instance pointer.
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 07:38:38 +08:00
*
* @return Maximum possible value of a message ID.
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 07:38:38 +08:00
*/
static inline uint32_t ipm_max_id_val_get(struct device *ipmdev)
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 07:38:38 +08:00
{
const struct ipm_driver_api *api = ipmdev->driver_api;
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 07:38:38 +08:00
return api->max_id_val_get(ipmdev);
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 07:38:38 +08:00
}
/**
* @brief Enable interrupts and callbacks for inbound channels.
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 07:38:38 +08:00
*
* @param ipmdev Driver instance pointer.
* @param enable Set to 0 to disable and to nonzero to enable.
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 07:38:38 +08:00
*
* @retval 0 On success.
* @retval EINVAL If it isn't an inbound channel.
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 07:38:38 +08:00
*/
static inline int ipm_set_enabled(struct device *ipmdev, int enable)
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 07:38:38 +08:00
{
const struct ipm_driver_api *api = ipmdev->driver_api;
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 07:38:38 +08:00
return api->set_enabled(ipmdev, enable);
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 07:38:38 +08:00
}
#ifdef __cplusplus
}
#endif
/**
* @}
*/
#endif /* __INCipmh */