Description
- Video RTIO demo #92566 (PoC)
- Video: Rework buffer management #92370 (main effort)
Introduction
Switch ad-hoc video buffers and submission/completion queues (fifo_in
/fifo_out
fields) + polling API to RTIO.
Problem description
The video enqueue()/dequeue()/set_signal() operations use a custom struct for video buffers and FIFO storage. Furthermore, the polling API is rarely implemented and not used in the capture example.
Proposed change
Replace the submission/completion mechanism of Video by RTIO, benefiting from reduced context switching, reduced maintenance, and provides a polling API implicitly without user requiring to implement it.
Detailed RFC
Proposed change (Detailed)
At a high-level, the modifications would be:
-
video_enqueue()
->rtio_sqe_acquire()
+rtio_sqe_prep_read()
+rtio_submit()
-
(struct sensor_data).fifo_out
->(struct sensor_data).io_q
(merged "I/O operation queue") -
k_fifo_put(&data->fifo_out, vbuf);
->rtio_iodev_sqe_ok(iodev_sqe, result);
-
video_set_signal()
-> not needed anymore -
k_poll_signal_raise(data->signal, VIDEO_BUF_DONE);
-> not needed anymore (part ofrtio_iodev_sqe_ok(iodev_sqe, result);
) -
k_poll_signal_raise(data->signal, VIDEO_BUF_ERROR);
->rtio_iodev_sqe_err(iodev_sqe, result);
-
vbuf->extra_fields
-> Beginning of the RTIO buffer payload
Dependencies
All features needed are already in Zephyr, and the switch to RTIO is a matter of progressively converting the drivers.
A "RTIO shim" strategy is frequenty used as a glue layer to cover drivers not converted yet.
Concerns and Unresolved Questions
If the migration happens, sould struct video_buffer
and several other APIs be kept for compatibility or a more convenient/flexible API be exposed instead?
Alternatives
Make use of struct net_buf
instead of RTIO.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status