Moves the rtio_ prefixed lockfree queues to sys alongside existing
mpsc/spsc pbuf, ringbuf, and similar queue-like data structures.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Resolve wrong documentation c function links for
irq: z_shared_isr, rtio: rtio_cqe_get_mempool_buffer
and sensor: sensor_read
Signed-off-by: Simon Hein <Shein@baumer.com>
The examples in the RTIO docs were nice but continuously became out of
date without being updated. This is unfortunately the downside of
doc-only samples like this.
Some real, buildable, samples right be better but will take a little
time to write up. In the meantime drop the examples in the docs to avoid
confusion.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The simple executor was removed with the usage of the spsc queue but
some stray references remained. Remove those.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The RTIO API docs weren't being shown. I made a poor assumption thinking
I could simply include the top level doxygen group in index.rst which isn't
the case. Fix the groups, and remove a note about a poll function
that doesn't exist yet.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Updates docs to account for the large number of changes that have
occured since the initial documentation was written.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
A DMA friendly Stream API for zephyr. Based on ideas from io_uring
and iio, a queue based API for I/O operations.
Provides a pair of fixed length ringbuffer backed queues for submitting
I/O requests and recieving I/O completions. The requests may be chained
together to ensure the next operation does not start until the current
one is complete.
Requests target an abstract rtio_iodev which is expected to wrap all
the hardware particulars of how to perform the operation. For example
with a SPI bus device, a description of what a read, and write mean
can be decided by the iodev wrapping a particular device
hanging off of a SPI controller.
The queue pair are submitted to an executor which may be a simple
inplace looping executor done in the callers execution context
(thread/stack) but other executors are expected. A threadpool executor
might for example allow for concurrent request chains to execute in
parallel. A DMA executor, in conjunction with DMA aware iodevs
would allow for hardware offloading of operations going so far as to
schedule with priority using hardware arbitration.
Both the iodev and executor are definable by a particular
SoC, meaning they can work in conjuction to perform IO operations
using a particular DMA controller or methodology if desired.
The application decides entirely how large the queues are, where
the buffers to read/write come from (some executors
may have particular demands!), and which executor to submit
requests to.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
