RTIO: Add Workqueue support for delayed work items

[ubieda]

Is your enhancement proposal related to a problem? Please describe.
Based on a discussion in #74389, it was brought up that some RTIO users may need to perform transactions spaced by time-intervals. This is similar to how the Zephyr Workqueue works. Right now it is not possible as the RTIO Workqueue service does not have any means to achieve this.

Describe the solution you'd like
Add the ability to the RTIO Workqueue service to achieve this functionality.

This could be, for instance, achieved by adding an API rtio_work_req_schedule() similar to rtio_work_req_submit but with a k_timeout_t parameter describing when this item is due for execution.

Describe alternatives you've considered
Have users implement this functionality out of the RTIO workqueue service (e.g: have an additional delayed work item which in turn submits the RTIO workq item). This may be a short-term solution but does not seem scalable as more users re-invent the same functionality.

Additional considerations
This is a well-known feature already supported by the Zephyr workqueue, and that users are familiar with, which is why IMO it makes sense to include it under this service.

[ubieda]

@FlorianWeber1018 LMK if you have any additional inputs on this!

[josuah]

This is an interesting addition for combining RTIO and this particular Video driver:

• drivers: video: API enhancement #72959 (comment) (RTIO proposal)

• zephyr/drivers/video/video_sw_generator.c

  Lines 91 to 98 in 14b3293

  	static int video_sw_generator_stream_start(const struct device *dev)
  	{
  	struct video_sw_generator_data *data = dev->data;
  	k_work_schedule(&data->buf_work, K_MSEC(1000 / VIDEO_PATTERN_FPS));
  	return 0;
  	}

[ubieda]

This is an interesting addition for combining RTIO and this particular Video driver:

• drivers: video: API enhancement #72959 (comment) (RTIO proposal)

• zephyr/drivers/video/video_sw_generator.c

  Lines 91 to 98 in 14b3293

  	static int video_sw_generator_stream_start(const struct device *dev)
  	{
  	struct video_sw_generator_data *data = dev->data;
  	k_work_schedule(&data->buf_work, K_MSEC(1000 / VIDEO_PATTERN_FPS));
  	return 0;
  	}

Thanks for sharing this! I'll find some time soon on this addition

[ubieda]

Since the RTIO Workqueue is built on top of P4WQ, I'm thinking of implementing this feature for P4WQ and simply have RTIOWQ use it. Any thoughts/objections on this approach @teburd @andyross?

[FlorianWeber1018]

gently ping @teburd @andyross.
#79637 and #74389 are waiting for this feature.

[bearsh]

this would be a great addition since quite some hardware sensors do need a significant delay between triggering a new measurement and fetching the data.