This function allows the application to close an ipc_service instance.
It is intended for use when the remote agent it is communicating with
has gone down and allows for cleanup.
It first checks that the endpoints have been separately deregistered
with the instance using the deregister_endpoint function before
calling into previously added functions in ipc_static_vrings.c
and ipc_rpmsg.c to close those instances.
Signed-off-by: Jackson Cooper-Driver <jackson.cooper---driver@amd.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In the case that an endpoint goes down, it needs to be deregistered
from the ipc_service for cleanup. This function deregisters the endpoint
from the ipc_rpmsg instance and sets the endpoint to zero.
Signed-off-by: Jackson Cooper-Driver <jackson.cooper---driver@amd.com>
Currently, it is possible to call various ipc_service functions
which take in an endpoint pointer (such as send, get_tx_buffer)
with an endpoint which has not been registered with the instance.
This leads to dereferencing a NULL pointer when the function tries
to access the api field of ept->instance.
This patch adds in multiple checks to ensure that the endpoint is
registered before continuing, one in the frontend, when ensures
that the ept->instance pointer is not NULL and one in the backend
which checks the value of the token pointer. If either of these fail,
we return -ENOENT.
Signed-off-by: Jackson Cooper-Driver <jackson.cooper---driver@amd.com>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add several new functions to the IPC service API:
- ipc_service_get_tx_buffer()
- ipc_service_drop_tx_buffer()
- ipc_service_send_nocopy()
- ipc_service_release_rx_buffer()
- ipc_service_hold_rx_buffer()
This set of function is used to support backends with nocopy capability.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Extend the RPMsg structs to accommodate for the introduction of new
backends and contextually fix the ipc_rpmsg_static_vrings_mi backend
(the only user).
Rework also some comments and ipc_service glue code.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
As know, an instance is the representation of a physical communication
channel between two domains / CPUs.
This communication channel must be usually known and initialized (that
is "opened") by both parties in the communication before a proper
communication can be instaurated using endpoints.
Depending on the backend and on the library / protocol used by the
backend, this "opening" can go through some handshaking or
synchronization procedure run by the parties that sometimes can be
blocking or time-consuming.
For example in the simplest case of a backend using OpenAMP, the remote
side of the communication is waiting for the local part to be up and
running by loop-waiting on some flag set in the shared memory by the
local party.
This is a blocking process so a particular attention must be paid to
where this is going to be placed in the backend code.
Currently it is only possible to have this synchronization procedure in
two points: (1) the init function of the instance, (2) during
ipc_service_register_endpoint().
It should be highly discouraged to put any blocking routine in the init
code, so (1) must be excluded. It is also frowned upon using the
endpoint registration function (2) because the synchronization is
something concerning the instance, not the single endpoints.
This patch is adding a new optional ipc_service_open_instance() function
that can be used to host the handshaking or synchronization code between
the two parties of the instance.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The IPC service code is currently assuming that only one IPC instance
does exist and the user can use the IPC service API to interface with
that singleton instance.
This is a huge limitation and this patch is trying to fix this
assumption introducing three major changes to the IPC service API:
- All the IPC instances are now supposed to be instantiated as a struct
device. A new test is introduced to be used as skeleton for all the
other backends.
- ipc_service_register_backend() is now removed (because multiple
backends are now supported at the same time).
- All the other ipc_service_*() functions are now taking a struct device
pointer as parameter to specify on which instance the user is going to
act and operate.
In this patch the documentation is also extended to better clarify the
terminology used.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
IPC Service allow plugging in different transport backends.
Specifies a generic API that is implemented by the backend.
Signed-off-by: Marcin Jeliński <marcin.jelinski@nordicsemi.no>
