Change all the Intel and Wind River code license from BSD-3 to Apache 2.
Change-Id: Id8be2c1c161a06ea8a0b9f38e17660e11dbb384b
Signed-off-by: Javier B Perez Hernandez <javier.b.perez.hernandez@linux.intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
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>
