Re: [PATCH v5 1/9] dmaengine: Support bus widths of 32 bytes and above

["Nuno Sá" <nuno.sa@analog.com>]

On Fri, Oct 09, 2026 at 09:45:06PM -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(-)
> >
> ...
> >
> >  	/* note: this only matters in the
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index 71cde09ff240..eb68eea840b5 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -427,8 +427,179 @@ enum dma_slave_buswidth {
> >  	DMA_SLAVE_BUSWIDTH_32_BYTES = 32,
> >  	DMA_SLAVE_BUSWIDTH_64_BYTES = 64,
> >  	DMA_SLAVE_BUSWIDTH_128_BYTES = 128,
> > +	DMA_SLAVE_BUSWIDTH_MAX
> >  };
> >
> ...
> > +/**
> > + * dma_bus_width_min - get the smallest bus width of a bus width mask
> > + * @mask: bus width mask
> > + *
> > + * Return: the smallest bus width set in @mask, or
> > + * %DMA_SLAVE_BUSWIDTH_UNDEFINED if @mask is empty.
> > + */
> > +#define dma_bus_width_min(mask) __dma_bus_width_min(&(mask))
> > +
> 
> We are working on make dma_device private. New API avoid direct use
> dma_device field.
> 
> pass down dma_chan point, dma engine handle everything in core part.

Not sure I follow the above. All the API's work directly on
dma_buswidth_mask_t and never touch dma_device. Now, consumers should
use this API through struct dma_slave_caps while provider's
(drivers/dma) should be able to use the private struct?

Other thing that came to mind that I can do in v6 is that APIs that
change the mask like:

dma_bus_width_clear()
dma_bus_width_set_many()
dma_bus_width_set()

Should be safely made private? I mean my expectation is that only
controllers know (can) act of the bitmap so don't think there's any
usecase where it makes sense to have API's like the above on the
consumer side of things?

> 
> > +static inline void __dma_bus_width_copy(dma_buswidth_mask_t *dst,
> > +					const dma_buswidth_mask_t *src)
> > +{
> > +	bitmap_copy(dst->bits, src->bits, DMA_SLAVE_BUSWIDTH_MAX);
> > +}
> > +
> > +/**
> > + * dma_bus_width_copy - copy a bus width mask
> > + * @dst: bus width mask to copy to
> > + * @src: bus width mask to copy from
> > + */
> > +#define dma_bus_width_copy(dst, src) __dma_bus_width_copy(&(dst), &(src))
> > +
> > +static inline bool __dma_bus_width_and(dma_buswidth_mask_t *dst,
> > +				       const dma_buswidth_mask_t *src1,
> > +				       const dma_buswidth_mask_t *src2)
> > +{
> > +	return bitmap_and(dst->bits, src1->bits, src2->bits,
> > +			  DMA_SLAVE_BUSWIDTH_MAX);
> > +}
> > +
> > +/**
> > + * dma_bus_width_and - intersect two bus width masks
> > + * @dst: bus width mask to store the result in
> > + * @src1: first bus width mask
> > + * @src2: second bus width mask
> > + *
> > + * Return: true if @dst has at least one bus width set, false otherwise.
> > + */
> > +#define dma_bus_width_and(dst, src1, src2) \
> > +	__dma_bus_width_and(&(dst), &(src1), &(src2))
> > +
> 
> One thing I forget, new API should start from dmaengine_.
> 

Noted!

- Nuno Sá

> Frank