Allow the rtio executor to handle the RTIO_OP_AWAIT for cases where no
rtio_iodev needs to be blocked while waiting for the signal.
When the RTIO_OP_AWAIT was introduced, the highlighted usecase was
performing transactions within an exact time window. This can be
achieved by blocking the rtio_iodev, effectively locking the bus, while
awaiting.
However, a relaxed implementation which doesn't block any rtio_iodev is
really useful for device drivers that use some kind of ready-event
during transactions. For example in order to read configuration out of
a sensor, the following flow may be required:
1. Write some cmd like "read accelerometer scale"
2. Await data-ready GPIO rising edge (might take "a long time")
3. Read the requested data payload from the sensor
Using a relaxed variant of the RTIO_OP_AWAIT this can be elegantly put
together in a single chained rtio sequence. And by not blocking the
rtio_iodev, other devices can be operated during the await period.
Of course, not blocking the rtio_iodev also means that the bus may be
busy when the RTIO_OP_AWAIT completes and thus, step 3 may be blocked
for a some time and the guarantee of an exact time window cannot be
achieved with the relaxed variant.
To make the API clearer, separate helpers are added for the strict
(blocking iodev) and relaxed (blocking only the sqe chain) variant
respectively.
Signed-off-by: Emil Dahl Juhl <emil@s16s.ai>
5b7c462c12