drivers: i3c: add i3c-rtio #80177
drivers: i3c: add i3c-rtio #80177
Conversation
XenuIsWatching
requested review from
teburd,
MaureenHelm,
yperess,
gmarull and
dcpleung
XenuIsWatching
requested review from
MulinChao,
ChiHuaL,
mmahadevan108 and
dleach02
as code owners
zephyrbot
added
area: RTIO
platform: NXP Drivers
zephyrbot
requested review from
danieldegrasse,
dbaluta,
decsny,
manuargue,
MarkWangChinese and
sjg20
XenuIsWatching
force-pushed
the
i3c-rtio-default
branch
from
3a436e6 to
733db91
Compare
|
|
||
| /** OP_I3C_CCC */ | ||
| /* struct i3c_ccc_payload *ccc_payload; */ | ||
| void *ccc_payload; |
There was a problem hiding this comment.
Is the payload mutable? Should potentially be const?
There was a problem hiding this comment.
yes... there is a num_xfer with in there to return the 'true' number of bytes actually sent/received as the target can control when the End of Data occurs.... but I should probably remove this as I was trying to integrate the do_ccc in to the rtio... but gave up for now
There was a problem hiding this comment.
This sounds like some more fun things to look at in the future for sure.
There was a problem hiding this comment.
yeah... thinking more about it I think i'll just keep it in for now.
| /* Try for next submission in the transaction */ | ||
| ctx->txn_curr = rtio_txn_next(ctx->txn_curr); | ||
| if (ctx->txn_curr) { | ||
| return true; |
There was a problem hiding this comment.
So in this case the sqe does not get completed neither with 'ok' nor with 'err'. Is this correct?
There was a problem hiding this comment.
I would assume so?? i2c_rtio.c is doing the exact same thing
There was a problem hiding this comment.
Yes yes, but still I don't get it. But the code seems well written, so there should be a reason I'm not 100% getting
There was a problem hiding this comment.
I'm not really sure either... I'm being rather a coding monkey 🐵 here and copied most of the i2c_rtio.c, but only understanding just enough to make it work with i3c. Perhaps @teburd would know as the original author?
There was a problem hiding this comment.
Transactions should result in one completion, either the transaction succeeds or fails. Akin to calling i2c_transfer you only know the result of the full operation not the individual sends/recvs
XenuIsWatching
force-pushed
the
i3c-rtio-default
branch
from
733db91 to
72ce864
Compare
This adds rtio along with a default handler for i3c Signed-off-by: Ryan McClelland <[email protected]>
add api calls for the default handlers for i2c and i3c rtio Signed-off-by: Ryan McClelland <[email protected]>
add api calls for the default handlers for i2c and i3c rtio Signed-off-by: Ryan McClelland <[email protected]>
add api calls for the default handlers for i3c rtio Signed-off-by: Ryan McClelland <[email protected]>
add api calls for the default handlers for i3c rtio Signed-off-by: Ryan McClelland <[email protected]>
XenuIsWatching
force-pushed
the
i3c-rtio-default
branch
from
72ce864 to
297e91c
Compare
The `_resv0` field is no longer needed after increasing the size of `iodev_flags` from `uint16_t` to `uint32_t` by this PR zephyrproject-rtos#80177. Signed-off-by: Pisit Sawangvonganan <[email protected]>
This adds support for i3c RTIO along with adding the default calls for i3c (and i2c) for all the i3c drivers
This is heavily based of the i2c default handler. #79890