[RFC] mipi-i3c-hci: Support for DMA Ring Pipelining / High-throughput Streaming
Frank Li
Frank.li at nxp.com
Sat May 23 07:47:59 PDT 2026
On Fri, May 22, 2026 at 03:37:35PM -0700, Sam Agazaryan wrote:
> Hello all,
>
> I am working on a project using the mipi-i3c-hci driver that involves
> large packet bursts (exceeding the physical hardware DMA ring size,
> such as large MCTP-over-I3C payloads).
How large to exceed DMA ring size, can you increase ring size?
And if large transfer, it will defer IBI handle for while. IBI check only
happen at every START phase.
>
> I noticed that the current driver implementation treats these as
> discrete batches.
>
> I am considering implementing a ring pipelining or DMA streaming
> mechanism to allow for asynchronous refills while the ring is running.
> This would leverage the
> standard ENQ_PTR doorbell mechanism (per MIPI HCI v1.2, Section 6.8.2)
> to continuously feed the hardware. I figured in that case it may be
> worth while to see how the upstream community feels about this
> feature.
>
> Before I dive into the implementation for upstream, I wanted to check:
> 1. Is there any existing work or a roadmap for DMA
> streaming/pipelining in the HCI driver?
> 2. Is a generic dma streaming mechanism for large transfers something
> you would be interested in seeing as a contribution to the mainline
> driver?
Usb\network\storage is async. The I3C's framework is sync.
>
> Currently, my proof-of-concept handles the pipelining at the core
> transfer level, but I
Can you send your patch as RFC to check what you already did?
> suspect for a generic upstream implementation, this sliding window
> logic should be moved into dma.c to properly support controllers with
> multiple Ring Bundles.
>
> I would appreciate any thoughts on this approach or the preferred
> architectural placement.
>
> Best regards,
> Sam
>
> --
> linux-i3c mailing list
> linux-i3c at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-i3c
More information about the linux-i3c
mailing list