For all remaining samples which now set their integration platform
as native_posix(_64) switch them to native_sim(_64)
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Avoid to build with debug log level enabled and instead register the
test log modules with debug level.
mr_canhubk3 board will fail to initialize the on-board watchdog within
the expected window triggering a reset, due to the amount of log
messages being printed. Other boards may face similar issues.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Rather than the rings, which weren't shared between userspace and kernel
space in Zephyr like they are in Linux with io_uring, use atomic mpsc
queues for submission and completion queues.
Most importantly this removes a potential head of line blocker in the
submission queue as the sqe would be held until a task is completed.
As additional bonuses this avoids some additional locks and restrictions
about what can be submitted and where. It also removes the need for
two executors as all chains/transactions are done concurrently.
Lastly this opens up the possibility for a common pool of sqe's to
allocate from potentially saving lots of memory.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
It was previously assumed that the 'sys_mem_blocks' struct would maintain
information about contiguous blocks allocated so the release API only
took the starting address. This led to an issue where allocating 2+
blocks would end up with a memory leak because any block not being the
first would never be released.
Add the buffer length as an argument so the correct number of blocks can
be released. Also, ammend the tests to match and verify.
Signed-off-by: Yuval Peress <peress@google.com>
As both C and C++ standards require applications running under an OS to
return 'int', adapt that for Zephyr to align with those standard. This also
eliminates errors when building with clang when not using -ffreestanding,
and reduces the need for compiler flags to silence warnings for both clang
and gcc.
Most of these changes were automated using coccinelle with the following
script:
@@
@@
- void
+ int
main(...) {
...
- return;
+ return 0;
...
}
Approximately 40 files had to be edited by hand as coccinelle was unable to
fix them.
Signed-off-by: Keith Packard <keithp@keithp.com>
By using an mpsc queue for each iodev, the iodev itself is shareable across
contexts. Since its lock free, submits may occur even from an ISR context.
Rather than a fixed size queue, and with it the possibility of running
out of pre-allocated spots, each iodev now holds a wait-free mpsc
queue head.
This changes the parameter of iodev submit to be a struct containing 4
pointers for the rtio context, the submission queue entry, and the mpsc
node for the iodevs submission queue.
This solves the problem involving busy iodevs working with real
devices. For example a busy SPI bus driver could enqueue, without locking,
a request to start once the current request is done.
The queue entries are expected to be owned and allocated by the
executor rather than the iodev. This helps simplify potential
tuning knobs to one place, the RTIO context and its executor an
application directly uses.
As the test case shows iodevs can operate effectively lock free
with the mpsc queue and a single atomic denoting the current task.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The iodev submission queue existed but wasn't easily constructed as
there was no macro to define it.
Adds a simple macro wrapper around RTIO_SPSC_DEFINE for creating
the RTIO IO Device Submission Queue enabling each IO device to
have its own pending queue of requests.
The sample has been updated to use the iodev submission queue rather
than a k_msgq.
Signed-off-by: Tom Burdick <thomas.burdick@intel.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>
Many device pointers are initialized at compile and never changed. This
means that the device pointer can be constified (immutable).
Automated using:
```
perl -i -pe 's/const struct device \*(?!const)(.*)= DEVICE/const struct
device *const $1= DEVICE/g' **/*.c
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Partially revert commit 0028e9733295316d152eba07bf56677d83f4b1b5.
Timeout for tests/posix/common must be still increased for slow
platforms (previously was 120 sec).
Signed-off-by: Manuel Arguelles <manuel.arguelles@nxp.com>
Any project with Kconfig option CONFIG_LEGACY_INCLUDE_PATH set to n
couldn't be built because some files were missing zephyr/ prefix in
includes
Re-run the migrate_includes.py script to fix all legacy include paths
Signed-off-by: Tomislav Milkovic <milkovic@byte-lab.com>
Timeout must be increased for fvp_baser_aemv8r_aarch32 board. Enabling
MPU on this board makes simulation slower.
Signed-off-by: Manuel Arguelles <manuel.arguelles@nxp.com>
Adds a new sample application that demonstrates using the RTIO subsystem
to read periodic sensor data directly into buffers allocated by the
application, asynchronously process batches of data with an algorithm,
and recycle buffers back for reading additional sensor data.
The sensor iodev in this application is an timer-driven device that
executes one read request per timer period. It doesn't actually send any
transactions to a real I2C/SPI bus or read any real data into the
application-provided buffers. This timer-driven behavior mimics how a
real sensor periodically triggers a GPIO interrupt when new data is
ready.
The sensor iodev currently uses an internal message queue to store
pending requests from the time they are submitted until the next timer
expiration. At least one pending request needs to be stored by the iodev
to ensure that it has a buffer available to read data into. However,
any more than that should probably be handled by the application, since
it's the application that determines how often it can submit new
requests and therefore how deep the queue needs to be.
The sensor iodev is implemented to support multiple instances with
devicetree, but additional work remains to enable and use more than one
in the application.
Tested on native_posix and frdm_k64f.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
