From: "Nuno Sá" <nuno.sa@analog.com>
To: Frank Li <Frank.li@oss.nxp.com>
Cc: linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-iio@vger.kernel.org,
linux-sound@vger.kernel.org, linux-spi@vger.kernel.org,
"Vinod Koul" <vkoul@kernel.org>, "Frank Li" <Frank.Li@kernel.org>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Eugeniy Paltsev" <Eugeniy.Paltsev@synopsys.com>,
"Amélie Delaunay" <amelie.delaunay@foss.st.com>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Jaroslav Kysela" <perex@perex.cz>,
"Takashi Iwai" <tiwai@suse.com>,
"Mark Brown" <broonie@kernel.org>
Subject: Re: [PATCH v5 1/9] dmaengine: Support bus widths of 32 bytes and above
Date: Mon, 12 Oct 2026 11:33:45 +0100 [thread overview]
Message-ID: <asy3V8Y94kx0WDOK@nsa> (raw)
In-Reply-To: <aslBdT8XqNW3L_WO@SMW015318>
On Fri, Oct 09, 2026 at 02:33:09PM -0500, Frank Li wrote:
> On Fri, Oct 09, 2026 at 04:52:53PM +0100, Nuno Sá wrote:
> > The src_addr_widths and dst_addr_widths capability masks encode each
> > supported width as a bit whose position equals the corresponding
> > enum dma_slave_buswidth value (e.g. DMA_SLAVE_BUSWIDTH_4_BYTES sets bit
> > 4). As these masks are plain u32, widths of 32 bytes and above
> > (DMA_SLAVE_BUSWIDTH_32/64/128_BYTES map to bits 32, 64 and 128) cannot
> > be represented at all.
> >
> > Introduce bitmap-based bus width capabilities that span the full enum
> > range, through a new dma_buswidth_mask_t type modeled after
> > dma_cap_mask_t. To allow DMA controller drivers to be converted
> > incrementally, the legacy dma_device u32 fields are kept alongside the
> > new masks and the core folds a legacy-only driver's u32 into the mask
> > when the device is registered, so consumers only ever have to look at
> > the mask.
> >
> > The fold is bidirectional while both representations coexist. A driver
> > that only fills in the legacy u32 gets its mask derived from it, so the
> > consumers already converted see it. A driver that only fills in the mask
> > gets its legacy u32 derived from the mask, so the consumers not
> > converted yet, which read the legacy dma_slave_caps fields, keep working.
> >
> > On top of that, dma_get_slave_caps() derives the legacy dma_slave_caps
> > masks from the new ones when a device_caps() callback adjusted them, so
> > that a converted controller narrowing its per-channel capabilities is
> > still seen by the consumers not converted yet, while a driver adjusting
> > the legacy masks directly keeps working.
> >
> > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> >
> > ---
> >
> > Andy, did not take your tag given that you're the one asking for the
> > split and since we ended up not doing it, not sure if the tag is
> > to be kept :)
> > ---
> > drivers/dma/dmaengine.c | 51 +++++++++++-
> > include/linux/dmaengine.h | 208 +++++++++++++++++++++++++++++++++++++++++++---
> > 2 files changed, 246 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> > index c5fef57b5adf..4ba9d6c7448a 100644
> > --- a/drivers/dma/dmaengine.c
> > +++ b/drivers/dma/dmaengine.c
> > @@ -33,6 +33,7 @@
> >
> > #include <linux/acpi.h>
> > #include <linux/acpi_dma.h>
> > +#include <linux/bitmap.h>
> > #include <linux/device.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/dmaengine.h>
> > @@ -592,8 +593,11 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
> > if (!device->directions)
> > return -ENXIO;
> >
> > + dma_bus_width_copy(caps->src_bus_widths, device->src_bus_widths);
> > + dma_bus_width_copy(caps->dst_bus_widths, device->dst_bus_widths);
> > caps->src_addr_widths = device->src_addr_widths;
> > caps->dst_addr_widths = device->dst_addr_widths;
> > +
>
> Remove this empty change.
ack
>
> > caps->directions = device->directions;
> > caps->min_burst = device->min_burst;
> > caps->max_burst = device->max_burst;
> > @@ -611,9 +615,31 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
> > * callback to override the generic capabilities with
> > * channel-specific ones.
> > */
> > - if (device->device_caps)
> > + if (device->device_caps) {
> > device->device_caps(chan, caps);
> ...
> > + * Return: 0 on success, -EINVAL if @widths contains an invalid bus width. Note
> > + * that the bus widths validated before the failing one are still set.
> > + */
> > +#define dma_bus_width_set_many(mask, widths, n_widths) \
> > + __dma_bus_width_set_many(&(mask), (widths), (n_widths))
>
> This is not good to get first argument pointer here, which will cause
> confused. check others.
>
> #define dma_bus_width_set_many(mask, widths, n_widths) \
> __dma_bus_width_set_many((mask), (widths), (n_widths))
>
Sure, but FWIW, I just followed the same style of the dma_caps macros.
- Nuno Sá
> Frank
next prev parent reply other threads:[~2026-10-12 10:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 15:52 [PATCH v5 0/9] dmaengine: Support bus widths of 32 bytes and above Nuno Sá
2026-10-09 15:52 ` [PATCH v5 1/9] " Nuno Sá
2026-10-09 19:33 ` Frank Li
2026-10-12 10:33 ` Nuno Sá [this message]
2026-10-10 2:45 ` Frank Li
2026-10-12 10:47 ` Nuno Sá
2026-10-12 14:46 ` Frank Li
2026-10-09 15:52 ` [PATCH v5 2/9] dmaengine: dma-axi-dmac: Use bus width capability helpers Nuno Sá
2026-10-09 16:03 ` sashiko-bot
2026-10-09 15:52 ` [PATCH v5 3/9] dmaengine: dw-axi-dmac: " Nuno Sá
2026-10-09 15:52 ` [PATCH v5 4/9] dmaengine: qcom: gpi: " Nuno Sá
2026-10-09 15:52 ` [PATCH v5 5/9] dmaengine: stm32-dma3: " Nuno Sá
2026-10-09 15:52 ` [PATCH v5 6/9] iio: buffer-dmaengine: Use dma_slave_caps bus width accessors Nuno Sá
2026-10-09 15:52 ` [PATCH v5 7/9] ALSA: pcm_dmaengine: Use dma_slave_caps bus width helpers Nuno Sá
2026-10-09 15:53 ` [PATCH v5 8/9] spi: dw: " Nuno Sá
2026-10-09 15:53 ` [PATCH v5 9/9] dmaengine: Drop legacy bus width fields from dma_slave_caps Nuno Sá
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=asy3V8Y94kx0WDOK@nsa \
--to=nuno.sa@analog.com \
--cc=Eugeniy.Paltsev@synopsys.com \
--cc=Frank.Li@kernel.org \
--cc=Frank.li@oss.nxp.com \
--cc=alexandre.torgue@foss.st.com \
--cc=amelie.delaunay@foss.st.com \
--cc=andy@kernel.org \
--cc=broonie@kernel.org \
--cc=dlechner@baylibre.com \
--cc=dmaengine@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=vkoul@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.