Re: [RFC] mipi-i3c-hci: Support for DMA Ring Pipelining / High-throughput Streaming

On Wed, Jun 3, 2026 at 11:23 AM Frank Li <[email protected]> wrote:

Hey Frank,

Apologies for the late reply.

>
> Assume left 128 entry, each entry only 1 byte,  about 128 * (10 + 8)'s
> SCL,
>
> If SCL is 12M, only have 192us to fill new descriptor. time of wake up a
> thread may be bigger than this time.
>

Either way don't we still need to wait to wake up after completing a
transfer with the current driver? With the current driver we would
just return back up the kernel stack to userspace eventually instead
of potentially queuing more transactions, E.G. 128 entries each only 1
byte queued in the DMA ring and we go to sleep waiting for completion
(TOC=1 for the final transaction). Normal queue ups < queue size
should technically not be impacted. One change in behavior, I guess,
would be that if multiple calls occur to the driver at once they will
wait for space on the ring to do their transfers if the ring cannot
accommodate the requests at that moment.

In an extreme case, like sending the driver say 1024 1-byte
transactions to process, it is definitely possible that the whole ring
empties out before we can refill it. However, IIUC, this should be
okay according to the MIPI I3C HCI standard since the hardware will
just wait for us to move the enqueue pointer forward again, signaling
that more transactions are available. Because we always terminate each
chunk (Some proportion of the ring depth, say 127 in the case of a
255-entry ring) with a TOC=1 descriptor, the hardware treats it as a
complete sequence. Therefore, if the ring empties out before we can
refill it, the hardware simply idles gracefully until we move the
enqueue pointer again.

Thanks,
Sam

-- 
linux-i3c mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-i3c