From: "Nuno Sá" <noname.nuno@gmail.com>
To: David Lechner <dlechner@baylibre.com>,
nuno.sa@analog.com, linux-iio@vger.kernel.org
Cc: Jonathan Cameron <jic23@kernel.org>,
Andy Shevchenko <andy@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 0/3] iio: buffer: Fix DMABUF mapping in some systems
Date: Mon, 06 Oct 2025 17:25:45 +0100 [thread overview]
Message-ID: <2fe00df37ad75591e437813f1c618c3decbdf2cb.camel@gmail.com> (raw)
In-Reply-To: <7eeb3072-b54e-46c7-9fb2-c4d2422188d8@baylibre.com>
On Mon, 2025-10-06 at 11:18 -0500, David Lechner wrote:
> On 10/6/25 11:06 AM, Nuno Sá via B4 Relay wrote:
> > This series fixes an issue with DMABUF support in the IIO subsystem where
> > the wrong DMA device could be used for buffer mapping operations. This
> > becomes critical on systems like Xilinx/AMD ZynqMP Ultrascale where memory
> > can be mapped above the 32-bit address range.
> >
> > Problem:
> > --------
> > The current IIO DMABUF implementation assumes it can use the parent device
> > of the IIO device for DMA operations. However, this device may not have
> > the appropriate DMA mask configuration for accessing high memory addresses.
> > On systems where memory is mapped above 32-bits, this leads to the use of
> > bounce buffers through swiotlb, significantly impacting performance.
> >
> > Solution:
> > ---------
> > This series introduces a new .get_dma_dev() callback in the buffer access
> > functions that allows buffer implementations to specify the correct DMA
> > device that should be used for DMABUF operations. The DMA buffer
> > infrastructure implements this callback to return the device that actually
> > owns the DMA channel, ensuring proper memory mapping without bounce buffers.
> >
> > Changes:
> > --------
> > 1. Add .get_dma_dev() callback to iio_buffer_access_funcs and update core
> > DMABUF code to use it when available
> > 2. Implement the callback in the DMA buffer infrastructure
> > 3. Wire up the callback in the dmaengine buffer implementation
> >
> > This ensures that DMABUF operations use the device with the correct DMA
> > configuration, eliminating unnecessary bounce buffer usage and improving
> > performance on high-memory systems.
> >
> > (AI generated cover. I would not be this formal but I guess is not
> > that bad :))
> >
> > ---
> > Changes in v2:
> > - Dropped Fixes tags on the first two patches and Cc stable them instead
> > (as prerequisites for the third patch).
> > - Link to v1:
> > https://lore.kernel.org/r/20251002-fix-iio-dmabuf-get-dma-device-v1-0-c1c9945029d0@analog.com
>
> Did you not care for my other suggestions in v1?
Completely missed them, sorry! I kind of stop reading in the stable stuff. I'm
ok with the helper function. For the clarification I feel it's redundant. The
field is called .get_dma_dev() and the description "called to get the DMA
channel associated with this buffer" already implies is for DMA buffer. Same as
ops like .enqueue_dmabuf().
- Nuno Sá
next prev parent reply other threads:[~2025-10-06 16:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 16:06 [PATCH v2 0/3] iio: buffer: Fix DMABUF mapping in some systems Nuno Sá via B4 Relay
2025-10-06 16:06 ` [PATCH v2 1/3] iio: buffer: support getting dma channel from the buffer Nuno Sá via B4 Relay
2025-10-06 16:06 ` [PATCH v2 2/3] iio: buffer-dma: support getting the DMA channel Nuno Sá via B4 Relay
2025-10-06 16:06 ` [PATCH v2 3/3] iio: buffer-dmaengine: enable .get_dma_dev() Nuno Sá via B4 Relay
2025-10-06 16:18 ` [PATCH v2 0/3] iio: buffer: Fix DMABUF mapping in some systems David Lechner
2025-10-06 16:25 ` Nuno Sá [this message]
2025-10-06 16:44 ` David Lechner
2025-10-07 8:25 ` Nuno Sá
2025-10-12 15:34 ` Jonathan Cameron
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=2fe00df37ad75591e437813f1c618c3decbdf2cb.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=stable@vger.kernel.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