Message ID | 20240620122726.41232-1-paul@crapouillou.net (mailing list archive) |
---|---|
Headers |
Received: from sv.mirrors.kernel.org ([139.178.88.99]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-13797-patchwork=linuxtv.org@vger.kernel.org>) id 1sKGtg-000669-2T for patchwork@linuxtv.org; Thu, 20 Jun 2024 12:28:13 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id C2E47281B66 for <patchwork@linuxtv.org>; Thu, 20 Jun 2024 12:28:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7E98F1AC789; Thu, 20 Jun 2024 12:27:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=crapouillou.net header.i=@crapouillou.net header.b="lqyoE7Lh" X-Original-To: linux-media@vger.kernel.org Received: from aposti.net (aposti.net [89.234.176.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 85F001AC43A; Thu, 20 Jun 2024 12:27:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=89.234.176.197 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718886471; cv=none; b=p6nMIZTdhPMu4KSgKd8wvaX+oJgNrMQ1pFvyPZsXjetlCOrOmKYhzBMm8Eogeyr4JXyc62PkmvjMpkWwfhVg3ejMTC+OKvy+6j2SSdz2tm+08sAKIv6GB8EDX+kUqYVI2geYL6Im+apqGLd43RRKImwl3Zl0NxSQvXfGb0EBvKc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718886471; c=relaxed/simple; bh=IVri826X6pjvmhvTPcELbF/pb2ND/lJ9NsEDK/hpclw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=o+wVlu5dE6CeY3YxgXaXXFrEHW9vov5Knb5FrLFsP9j+tDrSKelDc4Y/aGoPhFwxh/FS04YbiG6vt+DhZGGnxx0dd3Vb3dciYkDul2whgg6MJmpINE+iTBiy+yLHUmIw1DN5EaDMCEsB8q/nqAtYt+5y0tqTU01Knl4trKU13c8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=crapouillou.net; spf=pass smtp.mailfrom=crapouillou.net; dkim=pass (1024-bit key) header.d=crapouillou.net header.i=@crapouillou.net header.b=lqyoE7Lh; arc=none smtp.client-ip=89.234.176.197 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=crapouillou.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=crapouillou.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1718886461; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Phdke2IFP5DcYdJ0p7PW2PSRcousUzjTQIkIha9HQSc=; b=lqyoE7LhGfv+iomk4eTa9NEiOz1RYXGYKWnWtmg0TLRMwz3ZwT5U4Q1tiD3BbLWC7jd1gd wvR7Cn975V5ErvS3+B/VzBl9ndkSmmj8f4FUb3xv3z9aE/TKsnvtI/iW13i70tQlXiJFk3 stFWt0d2tKtU1RCBJSvdUg2aBvZBX2s= From: Paul Cercueil <paul@crapouillou.net> To: Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Vinod Koul <vkoul@kernel.org>, Sumit Semwal <sumit.semwal@linaro.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com> Cc: Jonathan Corbet <corbet@lwn.net>, Nuno Sa <nuno.sa@analog.com>, linux-iio@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, Paul Cercueil <paul@crapouillou.net> Subject: [PATCH v12 0/7] iio: new DMABUF based API v12 Date: Thu, 20 Jun 2024 14:27:19 +0200 Message-ID: <20240620122726.41232-1-paul@crapouillou.net> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-LSpam-Score: -4.9 (----) X-LSpam-Report: No, score=-4.9 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_MED=-2.3,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no |
Series |
iio: new DMABUF based API v12
|
|
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
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,