Lines Matching +full:time +full:- +full:of +full:- +full:flight

3 Real Time I/O (RTIO)
18 RTIO takes a lot of inspiration from Linux's io_uring in its operations and API
26 in Zephyr requires direct knowledge of the hardware and how it works. There is
27 no understanding in the DMA API of other Zephyr devices and how they relate.
32 To enable asynchronous operations, especially with DMA, a description of what
34 DMA features such as channels with priority, and sequences of transfers requires
35 more than a simple list of descriptions.
45 lock-free ring buffers acting as queues shared between the kernel and a userland
49 io_uring_submit call. This call may block the caller when a number of
53 sequence of operations in an asynchronous way directly relates
60 The submission queue (sq), is the description of the operations
64 register address to then read from. So the sequence of operations might be...
73 If anything in this chain of operations fails give up. Some of those operations
75 implicitly means setup the clock and chip select. The transactional nature of
76 the request also needs to be embodied in some manner. Of the operations above
78 requires an understanding of how to setup the device's particular DMA to do so.
80 The above sequence of operations is embodied in RTIO as chain of
96 a cqe being pushed into the cq. The ordering of cqe may not be the same order of
97 sqe. A chain of sqe will however ensure ordering and failure cascading.
106 certain request flags provide the expected behavior. It takes a list of
108 behavior of how submissions are worked through. Flags to form in order chains of
109 submissions, transactional sets of submissions, or create multi-shot
116 job of objects implementing the iodev (IO device) API. This API accepts requests
117 in the form of the iodev submit API call. It is the io devices job to work
118 through its internal queue of submissions and convert them into completions. In
120 object, that accepts a never ending queue of I/O like requests. How the iodev
121 does this work is up to the author of the iodev, perhaps the entire queue of
122 operations can be converted to a set of DMA transfer descriptors, meaning the
123 hardware does almost all of the real work.
138 the frequency of the data is unpredictable. In these cases it may be wasteful
139 to bind memory to in flight read requests. Instead with memory pools the memory
143 an RTIO context with a dedicated pool of "memory blocks" which can be consumed by
145 The memory pool has 128 blocks, each block has the size of 16 bytes, and the data
148 .. code-block:: C
164 only a small change which works with both pre-allocated data buffers as well as
165 the mempool. When the read is ready, instead of getting the buffers directly
169 .. code-block:: C
176     LOG_ERR("Failed to get buffer of at least %u bytes", MIN_BUF_LEN);
183 .. code-block:: C
207 From the driver/hardware perspective the API enables batching of I/O requests, potentially in an op…
219 driver implements the ``iodev_submit`` function of the bus API, then RTIO is supported. If the