This function deinitialises the static vrings used by the ipc_service
instance. It acheieves this by tearing down the initialised
virtqueues before closing the various aspects of libmetal which
are in use.
Signed-off-by: Jackson Cooper-Driver <jackson.cooper---driver@amd.com>
This function does the opposite of the ipc_rpmsg_init function and
allows the rpmsg instance to be torndown in the case that the application
wishes to do so. It is intended to be used by the ipc_service subsystem.
Signed-off-by: Jackson Cooper-Driver <jackson.cooper---driver@amd.com>
After magic is read during bound procedure, trigger an
initial data read. This is to ensure data is not missed
when piggybacked on magic's exchange interrupt.
Signed-off-by: Pawel Dunaj <pawel.dunaj@nordicsemi.no>
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>
This patch fixes an issues where the TX virtqueue is misaligned by
2 bytes due to the way the virtqueue start address is calculated.
It is currently set to immediatelly follow the RX virtqueue:
vr->tx_addr = vr->rx_addr + vring_size(num_desc, VRING_ALIGNMENT);
but the RX virtqueue does not end on an aligned boundary (last field,
avail_event is uint16_t). The resulting misaligned virtqueue causes
alignment faults on architectures that do not support unaligned
accesses (and is suboptimal otherwise)
The fix is to realign tx_addr to requested VRING_ALIGNMENT.
Signed-off-by: Aleksandar Radovanovic <aleksandar.radovanovic@amd.com>
Add flags option to init call and a flag to use cache.
Add Kconfig choice to pick how to approach cache. Cache can be
enforced in all spsc_pbuf instances, disable in all, or runtime selected
based on configuration flag. Option is added to allow memory footprint
savings.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Move icmsg_buf to lib/os and rename to spsc_pbuf (Single Producer
Single Consumer Packet Buffer). It is a generic module and initially
was created as internal module for ipc service.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
This reverts commit 7f51907fda.
The problem with setting the priority at the highest priority possible
is that when the IPC is under high traffic, the WQ could starve the
scheduler.
Move back to a more sane preemptive priority as default value.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The ipc_service_get_tx_buffer() has a timeout parameter that can be used
to wait a certain amount of time for a TX buffer to be available.
Unfortunately, for the static vrings backend, an asymmetry
between remote and host exists that makes the usage of this parameter
confusing when the user requests a buffer when no buffers are available
at that time.
When the remote endpoints requests a TX buffer specifying a certain
size and there are no TX buffers available, the function ignores the
parameter and ipc_service_get_tx_buffer() immediately returns -ENOMEM.
The same case on the host endpoint works correctly only when the
specified timeout is <= 15 seconds. All timeouts > 15 seconds simply
returns -EIO after 15 seconds.
This patch is reworking the timeout management trying to behave
correctly in all the cases.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Recently OpenAMP introduced the possibility to set the sizes for TX and
RX buffers per created instance. Expose this also to Zephyr users by
using a DT property "zephyr,buffer-size".
For the sake of simplicity use the same DT property to set the buffer
size for both TX and RX buffers.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Sometimes it is important to know when the backend fails to send out
data because no memory / buffers are available. Return -ENOMEM in that
case.
Signed-off-by: Carlo Caione <ccaione@baylibre.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>
In 92d8329d5b a new DT property was introduced to set the WQ priority
of the instance. The fallback value when the property was not present
was arbitrarily set to <0 PRIO_PREEMPT>.
The problem is that this value is actually changing the behaviour for
the code that is not explicitly setting the DT property, breaking in
some cases the existing code.
Move the default value to <0 PRIO_COOP> to give the old code a
consistent behaviour before and after the 92d8329d5b commit.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
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>
The purpose of this change is to allow to enable more than one
backend at once by removing choice from ipc-service backend Kconfig
and depending backend Kconfig option on existing of correct compatible.
Overwriting IPC_SERVICE_BACKEND option in some places is removes
as no longer needed.
Signed-off-by: Emil Obalski <emil.obalski@nordicsemi.no>
Added a code for initializing shared memory to zero. This operation
normalizes the memory state so that the IPC service is no longer
prone to reading status bits from the previous reset session.
Signed-off-by: Kamil Piszczek <Kamil.Piszczek@nordicsemi.no>
Instead of having one single WQ per backend, move to one WQ per
instance instead and add a new "zephyr,priority" property in the DT to
set the WQ priority of the instance. Fix the sample as well.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
This commit adds ipc backend, that relies on simple
inter core messaging buffer also added by this commit.
This backend is configurable with DT overlay. Each
ipc instance could be defined with ipc-icmsg commpatible.
Signed-off-by: Emil Obalski <emil.obalski@nordicsemi.no>
The priority of workqueue responsible for rpmsg processing was too
low. Any cooperative task could cause rpmsg processing to be
slightly delayed.
Signed-off-by: Artur Hadasz <artur.hadasz@nordicsemi.no>
No need to start the wq every time the mbox is initialized, it must be
done once for all the instances (it is shared by all the instances).
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Introduce a new RPMsg with static VRINGs backend. This new backend makes
easy to generate and use IPC instances backed by OpenAMP using the DT.
Each instance is defined in the DT as (for example):
ipc: ipc {
compatible = "zephyr,ipc-openamp-static-vrings";
shm = <&sram_ipc0>;
mboxes = <&mbox 0>, <&mbox 1>;
mbox-names = "tx", "rx";
role = "primary";
status = "okay";
};
It is then possible to register an send data through endpoints using the
IPC service APIs.
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 libraries will be used by several backends. Move the libraries
out in a new 'lib' directory.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
As part of the work to support multiple IPC instances / backends using
IPC service, the static vrings mi code must be reworked to resemble a
classic device driver.
Fix also the sample using it.
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>
Only one single IPC service backend is currently present: multi_instance
backend. This backend is heavily relying on the RPMsg multi_instance
code to instanciate and manage instances and endpoints. Samples exist
for both in the samples/subsys/ipc/ directory.
With this patch we are "unpacking" the RPMsg multi_service code to make
it more modular and reusable by different backends.
In particular we are re-organizing the code into two helper libraries:
an RPMsg library and a VRING / virtqueues static allocation library. At
the same time we rewrite the multi_instance backend to make fully use of
those new libraries and remove the old multi_instance sample.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
This patch is the first step to make the rpmsg_multi_instance usable in
a multi-core scenario.
The current driver is using a local driver variable (instance) to track
the number of allocated instances. This counter is practically used to
allocate to the instance the correct portion of the shared memory.
This is fundamentally wrong because this is assuming that it does exist
only one single shared memory region to split amongs all the allocated
instances. When the platform has more than one core this is obviously
not the case since each couple of cores are communicating using a
different memory region.
To solve this issue we introduce a new struct rpmsg_mi_ctx_shm_cfg that
is doing two things: (1) it's carrying the information about the shared
memory and (2) it's carrying an internal variable used to track the
instances allocated in that region. The same struct should be used every
time a new instance is allocated in the same shared memory region.
We also fix a problem with the current code where there is a race
between threads when accessing the instance variable, so this patch is
adding a serializing mutex.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
For the instance configuration the rpmsg_multi_instance code is
currently using a set of configuration info coming from two different
sources: the rpsmg_mi_ctx_cfg struct and Kconfig.
This is not only confusing but it's preventing to configure the
instances using information not coming from Kconfig (for example if we
want to configure the instance using DT).
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
In the current code the naming of the
CONFIG_RPMSG_MULTI_INSTANCE_?_IPM_{TX,RX}_NAME symbol is 1-based. While
this is not currently an issue, it could easily become such if the
symbol is programmatically used as part of a preprocessor enumeration
(for example when using DT_INST_FOREACH_STATUS_OKAY(...) & co).
To avoid trouble, just make the index starting from 0 instead than 1.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Implementation of the backend for IPC Service.
Multi-instance RPMsg was used as a backend.
Signed-off-by: Marcin Jeliński <marcin.jelinski@nordicsemi.no>
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>
