On Fri, 23 Feb 2024 13:13:58 +0100 Nuno Sa nuno.sa@analog.com wrote:

Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be honest, we're hoping to get this merged this for the 6.9 merge window. Main reason is because the USB part is already in (so it would be nice to get the whole thing in). Moreover, the changes asked in v6 were simple (even though I'm not quite sure in one of them) and Paul has no access to it's laptop so he can't send v7 himself. So he kind of said/asked for me to do it.

So, we are cutting this very fine. If Linus hints strongly at an rc8 maybe we can sneak this in. However, I need an Ack from Vinod for the dma engine changes first.

Also I'd love a final 'looks ok' comment from DMABUF folk (Ack even better!)

Seems that the other side got resolved in the USB gadget, but last we heard form Daniel and Christian looks to have been back on v5. I'd like them to confirm they are fine with the changes made as a result.

I've been happy with the IIO parts for a few versions now but my ability to review the DMABUF and DMA engine bits is limited.

A realistic path to get this in is rc8 is happening, is all Acks in place by Wednesday, I get apply it and hits Linux-next Thursday, Pull request to Greg on Saturday and Greg is feeling particularly generous to take one on the day he normally closes his trees.

Whilst I'll cross my fingers, looks like 6.10 material to me :(

I'd missed the progress on the USB side so wasn't paying enough attention. Sorry!

Jonathan

v6:

• https://lore.kernel.org/linux-iio/20240129170201.133785-1-paul@crapouillou.n...

v7:

• Patch 1

• Renamed *device_prep_slave_dma_vec() -> device_prep_peripheral_dma_vec();
• Added a new flag parameter to the function as agreed between Paul and Vinod. I renamed the first parameter to prep_flags as it's supposed to be used (I think) with enum dma_ctrl_flags. I'm not really sure how that API can grow but I was thinking in just having a bool cyclic parameter (as the first intention of the flags is to support cyclic transfers) but ended up "respecting" the previously agreed approach.

• Patch 2
  • Adapted patch for the changes made in patch 1.
• Patch 5
  • Adapted patch for the changes made in patch 1.

Patchset based on next-20240223.

---

Paul Cercueil (6): dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Enable support for DMABUFs iio: buffer-dmaengine: Support new DMABUF based userspace API Documentation: iio: Document high-speed DMABUF based API

Documentation/iio/dmabuf_api.rst | 54 +++ Documentation/iio/index.rst | 2 + drivers/dma/dma-axi-dmac.c | 40 ++ drivers/iio/buffer/industrialio-buffer-dma.c | 181 +++++++- drivers/iio/buffer/industrialio-buffer-dmaengine.c | 59 ++- drivers/iio/industrialio-buffer.c | 462 +++++++++++++++++++++ include/linux/dmaengine.h | 27 ++ include/linux/iio/buffer-dma.h | 31 ++ include/linux/iio/buffer_impl.h | 33 ++ include/uapi/linux/iio/buffer.h | 22 + 10 files changed, 894 insertions(+), 17 deletions(-)

---

base-commit: 33e1d31873f87d119e5120b88cd350efa68ef276 change-id: 20240223-iio-dmabuf-5ee0530195ca --

Thanks!

• Nuno Sá