Based on a discussion around P4WQ limitations for our application, it
was determined that the RTIO workqueue required the ability to use
additional threads from the pool in spite of work items blocked.
Since this is not covered, nor desired for the P4WQ, then remove this
dependency and re-implement it in a way that covers also this use-case.
Signed-off-by: Luis Ubieda <luisf@croxel.com>
As to facilitate work items preemption, common for sensor read ops.
e.g:
- Sensor read (submitted through workqueue).
- SPI read (submitted through workqueue using default handler).
This requires at least 2 thread pools to allow SPI read to complete,
to then come back and complete sensor reading.
Signed-off-by: Luis Ubieda <luisf@croxel.com>
Otherwise the RTIO Workqueue is not functional for devices during init.
An example of this issue is devices using SPI transfers with default
spi_rtio.
Signed-off-by: Luis Ubieda <luisf@croxel.com>
Adds ability to process synchronous requests in an asynchronous
fashion, relying on dedicated P4WQ's and pre-allocated work items.
Signed-off-by: Luis Ubieda <luisf@croxel.com>
