i2c: Asynchronous Transfers

[teburd]

Provides i2c_transfer_cb as an optional API along with a wrapper that provides i2c_transfer_signal (async with a k_poll_signal notifier).

Notably i2c_transfer_cb should not block so it can be initiated from an ISR if so desired as done in the frdm_k64f example. If it would block, returning -EWOULDBLOCK is expected.

[teburd]

In place of a common set of callback helpers, provide a direct k_poll_signal wrapper alongside the callback version of i2c_transfer, so adds i2c_transfer_cb (callback) and i2c_transfer_signal (k_poll_signal, wraps the callback API).

This matches my discussions @henrikbrixandersen on discord

[teburd]

I did spend some time trying to make the k_poll_signal i2c_transfer_signal a user space friendly syscall with some success. The downsides came to needing to alloc/free things when user space was being used to keep the life of a copy of the i2c_msg array around long enough.

It's certainly something that can be addressed in a future PR.

[nordic-krch]

i still think that it would be better to put all this into a struct. Struct can be later on extended without breaking api (e.g adding list node field if we go into direction of queued transfers).

Current version is suitable only for bus with one device since with more we might hit collision and handling collision is painful. At the end, it should be really fire and forget. Using struct gives path towards that without need of breaking the API in the future.

[teburd]

This can be done by providing an asynchronous lock/unlock pair of functions

i2c_lock_async(dev, cb0, data);
i2c_transfer_cb(dev, i2c_msgs, cb1, data);
i2c_transfer_cb(dev, more_i2c_msgs, cb2, data);
i2c_unlock_async(dev, cb3, data);

Obviously not in a row like that but in a callback chain. Callback chaining like this is what RTIO makes look more like a queue of requests and pollable responses.

That's how I was planning on dealing with this issue rather than trying to embed a request queue directly in the device driver. In effect there's an application allocated request queue over all devices rather than each device having its own. This way you can do request chaining or parallelism with most of the I/O task concurrency that something like a promise pipeline might give you.

It also shares all the code and logic then in something common to all device driver classes.

The blocking api can look like a semaphore given at the end of a fixed callback chain like above.

I could be wrong though, and I thought you tried to embed the queue in the device before but ran into issues.