Is your feature request related to a problem? Please describe.
As an outcome of #74435, the existing sensor drivers implementing the submit API are relying on the RTIO workqueue to effectively decouple the submission from their synchronous execution. Ideally, this shouldn't be required at all: rather this shall be consisted of a set of RTIO requests submitted and handled in an asynchronous fashion.
Dependencies
The reason this hasn't taken place yet is due to, primarily, lacking RTIO-based support for the bus-drivers (see: #67328, #67327 and #73869). After the fallback/default implementations for both SPI and I2C are incorporated in the tree, this shall be unblocked.
Describe the solution you'd like
Sensor Drivers have the Submit API using RTIO-based bus transactions and are non-blocking.
Additional context
List of sensors implementing Submit API with RTIO/non-blocking approach:
ubieda
commented
4 weeks ago
Is your feature request related to a problem? Please describe.
As an outcome of #74435, the existing sensor drivers implementing the
submitAPI are relying on the RTIO workqueue to effectively decouple the submission from their synchronous execution. Ideally, this shouldn't be required at all: rather this shall be consisted of a set of RTIO requests submitted and handled in an asynchronous fashion.Dependencies
The reason this hasn't taken place yet is due to, primarily, lacking RTIO-based support for the bus-drivers (see: #67328, #67327 and #73869). After the fallback/default implementations for both SPI and I2C are incorporated in the tree, this shall be unblocked.
Describe the solution you'd like
Sensor Drivers have the Submit API using RTIO-based bus transactions and are non-blocking.
Additional context
List of sensors implementing Submit API with RTIO/non-blocking approach: