OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/subsys/rtio/Kconfig

40 lines
1.4 KiB
Plaintext
Raw Normal View History

rtio: Real-Time Input/Output Stream 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>
2019-06-26 23:17:18 +08:00
# Copyright (c) 2022 Intel Corporation
# SPDX-License-Identifier: Apache-2.0
menuconfig RTIO
bool "RTIO"
if RTIO
config RTIO_SUBMIT_SEM
bool "Use a semaphore when waiting for completions in rtio_submit"
help
When calling rtio_submit a semaphore is available to sleep the calling
thread for each completion queue event until the wait count is met. This
adds a small RAM overhead for a single semaphore. By default wait_for will
use polling on the completion queue with a k_yield() in between iterations.
config RTIO_CONSUME_SEM
bool "Use a semaphore when waiting for completions in rtio_cqe_consume_block"
help
When calling rtio_cqe_consume_block a semaphore is available to sleep the
calling thread for each completion queue event until the wait count is met.
This adds a small RAM overhead for a single semaphore. By default the call
will use polling on the completion queue with a k_yield() in between
iterations.
rtio: Add a managed memory pool for reads - Introduce a new Kconfig to enable mempool in RTIO - Introduce a new RTIO_DEFINE_WITH_MEMPOOL to allocate an RTIO context with an associated memory pool. - Add a new sqe read function rtio_sqe_read_with_pool() for memory pool enabled RTIO contexts - Allow IODevs to allocate only the memory they need via rtio_sqe_rx_buf() - Allow the consumer to get the allocated buffer via rtio_cqe_get_mempool_buffer() - Consumers need to release the buffer via rtio_release_buffer() when processing is complete. Signed-off-by: Yuval Peress <peress@google.com>
2023-04-07 12:49:25 +08:00
config RTIO_SYS_MEM_BLOCKS
bool "Include system memory blocks as an optional backing read memory pool"
select SYS_MEM_BLOCKS
help
Enable the RTIO_DEFINE_WITH_MEMPOOL macro which allows queueing reads
without a pre-allocated memory buffer. Instead the buffer will be taken
from the allocated memory pool associated with the RTIO context.
rtio: Real-Time Input/Output Stream 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>
2019-06-26 23:17:18 +08:00
module = RTIO
module-str = RTIO
module-help = Sets log level for RTIO support
source "subsys/logging/Kconfig.template.log_config"
endif