| Message ID | 20240620122726.41232-1-paul@crapouillou.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | iio: new DMABUF based API v12 | expand |
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?
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. Thanks, Jonathan
On Thu, 20 Jun 2024 20:11:50 +0100 Jonathan Cameron <jic23@kernel.org> 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. Just to make sure we are on the same page, based on a clean rc1 so I just get the parts of this series (hopefully there aren't an necessary precursors!) J > > Thanks, > > Jonathan > >
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,
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 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
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
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,
Hi Jonathan, Fantastic news, thanks! Cheers, -Paul Le 30 juin 2024 12:32:03 GMT+02:00, Jonathan Cameron <jic23@kernel.org> a écrit : >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, >
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