mbox series

[v12,0/7] iio: new DMABUF based API v12

Message ID 20240620122726.41232-1-paul@crapouillou.net
Headers show
Series iio: new DMABUF based API v12 | expand

Message

Paul Cercueil June 20, 2024, 12:27 p.m. UTC
Hi Jonathan,

Here's the v12 of my patchset that introduces DMABUF support to IIO.

Apart from a small documentation fix, it reverts to using
mutex_lock/mutex_unlock in one particular place, which used cleanup
GOTOs (which don't play well with scope-managed cleanups).

Changelog:
- [3/7]:
    - Revert to mutex_lock/mutex_unlock in iio_buffer_attach_dmabuf(),
      as it uses cleanup GOTOs
- [6/7]:
    - "obtained using..." -> "which can be obtained using..."

This is based on next-20240619.

Cheers,
-Paul

Paul Cercueil (7):
  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: dmaengine: Document new dma_vec API

 Documentation/driver-api/dmaengine/client.rst |   9 +
 .../driver-api/dmaengine/provider.rst         |  10 +
 Documentation/iio/iio_dmabuf_api.rst          |  54 +++
 Documentation/iio/index.rst                   |   1 +
 drivers/dma/dma-axi-dmac.c                    |  40 ++
 drivers/iio/Kconfig                           |   1 +
 drivers/iio/buffer/industrialio-buffer-dma.c  | 178 ++++++-
 .../buffer/industrialio-buffer-dmaengine.c    |  62 ++-
 drivers/iio/industrialio-buffer.c             | 459 ++++++++++++++++++
 include/linux/dmaengine.h                     |  33 ++
 include/linux/iio/buffer-dma.h                |  31 ++
 include/linux/iio/buffer_impl.h               |  33 ++
 include/uapi/linux/iio/buffer.h               |  22 +
 13 files changed, 913 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/iio/iio_dmabuf_api.rst

Comments

Vinod Koul June 21, 2024, 10:06 a.m. UTC | #1
On Thu, 20 Jun 2024 14:27:19 +0200, Paul Cercueil wrote:
> Here's the v12 of my patchset that introduces DMABUF support to IIO.
> 
> Apart from a small documentation fix, it reverts to using
> mutex_lock/mutex_unlock in one particular place, which used cleanup
> GOTOs (which don't play well with scope-managed cleanups).
> 
> Changelog:
> - [3/7]:
>     - Revert to mutex_lock/mutex_unlock in iio_buffer_attach_dmabuf(),
>       as it uses cleanup GOTOs
> - [6/7]:
>     - "obtained using..." -> "which can be obtained using..."
> 
> [...]

Applied, thanks!

[1/7] dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
      commit: 5878853fc9389e7d0988d4b465a415cf96fd14fa
[2/7] dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec
      commit: 74609e5686701ed8e8adc3082d15f009e327286d
[7/7] Documentation: dmaengine: Document new dma_vec API
      commit: 380afccc2a55e8015adae4266e8beff96ab620be

Best regards,
Vinod Koul June 21, 2024, 10:10 a.m. UTC | #2
On 21-06-24, 15:38, Vinod Koul wrote:
> On 20-06-24, 20:11, Jonathan Cameron wrote:
> > On Thu, 20 Jun 2024 21:50:41 +0530
> > Vinod Koul <vkoul@kernel.org> wrote:
> > 
> > > On 20-06-24, 14:27, Paul Cercueil wrote:
> > > > Hi Jonathan,  
> > > 
> > > Hey Jonathan,
> > > 
> > > Assuming we are fine with this series, how would you like to proceed.
> > > Would you be fine with me picking the dmaengine bits and providing a
> > > signed tag for you to pull?
> > > 
> > 
> > Hi Vinod,
> > 
> > Yes. That will work nicely.
> > From my side it all looks good.
> 
> Great, here it is:
> 
> The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0:
> 
>   Linux 6.10-rc1 (2024-05-26 15:20:12 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git topic/dma_vec_api

Sorry, sent branch instead of signed tag: here is the signed tag

    git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git dmaengine_topic_dma_vec

> for you to fetch changes up to 380afccc2a55e8015adae4266e8beff96ab620be:
> 
>   Documentation: dmaengine: Document new dma_vec API (2024-06-21 15:31:57 +0530)
> 
> ----------------------------------------------------------------
> Paul Cercueil (3):
>       dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
>       dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec
>       Documentation: dmaengine: Document new dma_vec API
> 
>  Documentation/driver-api/dmaengine/client.rst   |  9 ++++++
>  Documentation/driver-api/dmaengine/provider.rst | 10 +++++++
>  drivers/dma/dma-axi-dmac.c                      | 40 +++++++++++++++++++++++++
>  include/linux/dmaengine.h                       | 33 ++++++++++++++++++++
>  4 files changed, 92 insertions(+)
> 
> 
> Thanks
> -- 
> ~Vinod
Jonathan Cameron June 30, 2024, 10:32 a.m. UTC | #3
On Fri, 21 Jun 2024 15:36:24 +0530
Vinod Koul <vkoul@kernel.org> wrote:

> On Thu, 20 Jun 2024 14:27:19 +0200, Paul Cercueil wrote:
> > Here's the v12 of my patchset that introduces DMABUF support to IIO.
> > 
> > Apart from a small documentation fix, it reverts to using
> > mutex_lock/mutex_unlock in one particular place, which used cleanup
> > GOTOs (which don't play well with scope-managed cleanups).
> > 
> > Changelog:
> > - [3/7]:
> >     - Revert to mutex_lock/mutex_unlock in iio_buffer_attach_dmabuf(),
> >       as it uses cleanup GOTOs
> > - [6/7]:
> >     - "obtained using..." -> "which can be obtained using..."
> > 
> > [...]  
> 
> Applied, thanks!
> 
> [1/7] dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
>       commit: 5878853fc9389e7d0988d4b465a415cf96fd14fa
> [2/7] dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec
>       commit: 74609e5686701ed8e8adc3082d15f009e327286d
> [7/7] Documentation: dmaengine: Document new dma_vec API
>       commit: 380afccc2a55e8015adae4266e8beff96ab620be

Merged Vinod's topic branch and applied, 3,4,5,6 to the togreg
branch of iio.git.  Thanks all for the hard work on this one.
Great to finally get there!

Jonathan

p.s. Last few weeks were about some complexities in the IIO tree
unrelated to this set.

> 
> Best regards,