linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Christian König" <christian.koenig@amd.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Alexandru Ardelean" <ardeleanalex@gmail.com>,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-iio@vger.kernel.org
Subject: Re: [PATCH v2 00/12] iio: buffer-dma: write() and new DMABUF based API
Date: Tue, 15 Feb 2022 17:43:35 +0000	[thread overview]
Message-ID: <N8XC7R.5FP2M8552CGT3@crapouillou.net> (raw)
In-Reply-To: <20220213184616.669b490b@jic23-huawei>

Hi Jonathan,

Le dim., févr. 13 2022 at 18:46:16 +0000, Jonathan Cameron 
<jic23@kernel.org> a écrit :
> On Mon,  7 Feb 2022 12:59:21 +0000
> Paul Cercueil <paul@crapouillou.net> wrote:
> 
>>  Hi Jonathan,
>> 
>>  This is the V2 of my patchset that introduces a new userspace 
>> interface
>>  based on DMABUF objects to complement the fileio API, and adds 
>> write()
>>  support to the existing fileio API.
> 
> Hi Paul,
> 
> It's been a little while. Perhaps you could summarize the various view
> points around the appropriateness of using DMABUF for this?
> I appreciate it is a tricky topic to distil into a brief summary but
> I know I would find it useful even if no one else does!

So we want to have a high-speed interface where buffers of samples are 
passed around between IIO devices and other devices (e.g. USB or 
network), or made available to userspace without copying the data.

DMABUF is, at least in theory, exactly what we need. Quoting the 
documentation 
(https://www.kernel.org/doc/html/v5.15/driver-api/dma-buf.html):
"The dma-buf subsystem provides the framework for sharing buffers for 
hardware (DMA) access across multiple device drivers and subsystems, 
and for synchronizing asynchronous hardware access. This is used, for 
example, by drm “prime” multi-GPU support, but is of course not 
limited to GPU use cases."

The problem is that right now DMABUF is only really used by DRM, and to 
quote Daniel, "dma-buf looks like something super generic and useful, 
until you realize that there's a metric ton of gpu/accelerator bagage 
piled in".

Still, it seems to be the only viable option. We could add a custom 
buffer-passing interface, but that would mean implementing the same 
buffer-passing interface on the network and USB stacks, and before we 
know it we re-invented DMABUFs.

Cheers,
-Paul


>> 
>>  Changes since v1:
>> 
>>  - the patches that were merged in v1 have been (obviously) dropped 
>> from
>>    this patchset;
>>  - the patch that was setting the write-combine cache setting has 
>> been
>>    dropped as well, as it was simply not useful.
>>  - [01/12]:
>>      * Only remove the outgoing queue, and keep the incoming queue, 
>> as we
>>        want the buffer to start streaming data as soon as it is 
>> enabled.
>>      * Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally 
>> the
>>        same as IIO_BLOCK_STATE_DONE.
>>  - [02/12]:
>>      * Fix block->state not being reset in
>>        iio_dma_buffer_request_update() for output buffers.
>>      * Only update block->bytes_used once and add a comment about 
>> why we
>>        update it.
>>      * Add a comment about why we're setting a different state for 
>> output
>>        buffers in iio_dma_buffer_request_update()
>>      * Remove useless cast to bool (!!) in iio_dma_buffer_io()
>>  - [05/12]:
>>      Only allow the new IOCTLs on the buffer FD created with
>>      IIO_BUFFER_GET_FD_IOCTL().
>>  - [12/12]:
>>      * Explicitly state that the new interface is optional and is
>>        not implemented by all drivers.
>>      * The IOCTLs can now only be called on the buffer FD returned by
>>        IIO_BUFFER_GET_FD_IOCTL.
>>      * Move the page up a bit in the index since it is core stuff 
>> and not
>>        driver-specific.
>> 
>>  The patches not listed here have not been modified since v1.
>> 
>>  Cheers,
>>  -Paul
>> 
>>  Alexandru Ardelean (1):
>>    iio: buffer-dma: split iio_dma_buffer_fileio_free() function
>> 
>>  Paul Cercueil (11):
>>    iio: buffer-dma: Get rid of outgoing queue
>>    iio: buffer-dma: Enable buffer write support
>>    iio: buffer-dmaengine: Support specifying buffer direction
>>    iio: buffer-dmaengine: Enable write support
>>    iio: core: Add new DMABUF interface infrastructure
>>    iio: buffer-dma: Use DMABUFs instead of custom solution
>>    iio: buffer-dma: Implement new DMABUF based userspace API
>>    iio: buffer-dmaengine: Support new DMABUF based userspace API
>>    iio: core: Add support for cyclic buffers
>>    iio: buffer-dmaengine: Add support for cyclic buffers
>>    Documentation: iio: Document high-speed DMABUF based API
>> 
>>   Documentation/driver-api/dma-buf.rst          |   2 +
>>   Documentation/iio/dmabuf_api.rst              |  94 +++
>>   Documentation/iio/index.rst                   |   2 +
>>   drivers/iio/adc/adi-axi-adc.c                 |   3 +-
>>   drivers/iio/buffer/industrialio-buffer-dma.c  | 610 
>> ++++++++++++++----
>>   .../buffer/industrialio-buffer-dmaengine.c    |  42 +-
>>   drivers/iio/industrialio-buffer.c             |  60 ++
>>   include/linux/iio/buffer-dma.h                |  38 +-
>>   include/linux/iio/buffer-dmaengine.h          |   5 +-
>>   include/linux/iio/buffer_impl.h               |   8 +
>>   include/uapi/linux/iio/buffer.h               |  30 +
>>   11 files changed, 749 insertions(+), 145 deletions(-)
>>   create mode 100644 Documentation/iio/dmabuf_api.rst
>> 
> 



  reply	other threads:[~2022-02-15 17:43 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07 12:59 [PATCH v2 00/12] iio: buffer-dma: write() and new DMABUF based API Paul Cercueil
2022-02-07 12:59 ` [PATCH v2 01/12] iio: buffer-dma: Get rid of outgoing queue Paul Cercueil
2022-02-13 18:57   ` Jonathan Cameron
2022-02-13 19:25     ` Paul Cercueil
2022-03-28 17:17   ` Jonathan Cameron
2022-02-07 12:59 ` [PATCH v2 02/12] iio: buffer-dma: Enable buffer write support Paul Cercueil
2022-03-28 17:24   ` Jonathan Cameron
2022-03-28 18:39     ` Paul Cercueil
2022-03-29  7:11       ` Nuno Sá
2022-03-28 20:38   ` Andy Shevchenko
2022-02-07 12:59 ` [PATCH v2 03/12] iio: buffer-dmaengine: Support specifying buffer direction Paul Cercueil
2022-02-07 12:59 ` [PATCH v2 04/12] iio: buffer-dmaengine: Enable write support Paul Cercueil
2022-03-28 17:28   ` Jonathan Cameron
2022-02-07 12:59 ` [PATCH v2 05/12] iio: core: Add new DMABUF interface infrastructure Paul Cercueil
2022-03-28 17:37   ` Jonathan Cameron
2022-03-28 18:44     ` Paul Cercueil
2022-03-29 13:36       ` Jonathan Cameron
2022-03-28 20:46   ` Andy Shevchenko
2022-02-07 12:59 ` [PATCH v2 06/12] iio: buffer-dma: split iio_dma_buffer_fileio_free() function Paul Cercueil
2022-02-07 12:59 ` [PATCH v2 07/12] iio: buffer-dma: Use DMABUFs instead of custom solution Paul Cercueil
2022-03-28 17:54   ` Jonathan Cameron
2022-03-28 17:54     ` Christian König
2022-03-28 19:16     ` Paul Cercueil
2022-03-28 20:58       ` Andy Shevchenko
2022-02-07 12:59 ` [PATCH v2 08/12] iio: buffer-dma: Implement new DMABUF based userspace API Paul Cercueil
2022-02-07 12:59 ` [PATCH v2 09/12] iio: buffer-dmaengine: Support " Paul Cercueil
2022-02-07 12:59 ` [PATCH v2 10/12] iio: core: Add support for cyclic buffers Paul Cercueil
2022-02-07 13:01 ` [PATCH v2 11/12] iio: buffer-dmaengine: " Paul Cercueil
2022-02-07 13:01   ` [PATCH v2 12/12] Documentation: iio: Document high-speed DMABUF based API Paul Cercueil
2022-03-29  8:54     ` Daniel Vetter
2022-03-29  9:47       ` Paul Cercueil
2022-03-29 14:07         ` Daniel Vetter
2022-03-29 17:34           ` Paul Cercueil
2022-03-30  9:22             ` Daniel Vetter
2022-02-13 18:46 ` [PATCH v2 00/12] iio: buffer-dma: write() and new " Jonathan Cameron
2022-02-15 17:43   ` Paul Cercueil [this message]
2022-03-29  8:33     ` Daniel Vetter
2022-03-29  9:11       ` Paul Cercueil
2022-03-29 14:10         ` Daniel Vetter
2022-03-29 17:16           ` Paul Cercueil
2022-03-30  9:19             ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=N8XC7R.5FP2M8552CGT3@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=Michael.Hennerich@analog.com \
    --cc=ardeleanalex@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).