Re: [PATCH RFC 0/3] dmaengine: Support address bus widths of 32 bytes and above

["Nuno Sá" <noname.nuno@gmail.com>]

On Wed, Jun 17, 2026 at 12:57:54PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 04:40:51PM +0100, Nuno Sá via B4 Relay wrote:
> > The DMA engine slave capabilities advertise the supported source and
> > destination bus widths in src_addr_widths / dst_addr_widths. These are
> > plain u32 bitmasks where a set bit's position equals the corresponding
> > enum dma_slave_buswidth value, e.g. DMA_SLAVE_BUSWIDTH_4_BYTES sets
> > bit 4.
> > 
> > The consequence is that widths of 32 bytes and above cannot be
> > represented at all: DMA_SLAVE_BUSWIDTH_32/64/128_BYTES would need bits
> > 32, 64 and 128, which simply do not fit in a u32. Hardware with wider
> > data paths is becoming common, so we need a representation that can
> > express these widths while still using enum dma_slave_buswidth.
> > 
> > This series switches the masks to bitmaps that span the full enum
> > range. Because there are many producers (DMA controllers) and a number
> > of consumers spread across the tree, converting everything in one go is
> > not realistic. To allow an incremental migration, the legacy u32 fields
> > are kept alongside the new bitmaps:
> > 
> > - producers set the bitmap via the new dma_set_{src,dst}_addr_mask()
> > helpers, which also mirror the low 32 bits back into the legacy u32;
> > - legacy producers that still assign the u32 directly keep working, and
> > dma_get_slave_caps() folds such a u32 into the bitmap it returns, so
> > new consumers always see a complete bitmap;
> > - consumers can read either the legacy u32 or the new bitmap during the
> > transition.
> > 
> > The axi-dmac controller and the IIO dmaengine buffer are converted as
> > examples of a producer and a consumer. And this actually fixes a very
> > open coded path to undefined behavior in the axi-dmac driver and
> > possibly others.
> > 
> > The end goal is to convert every producer and consumer, then drop the
> > legacy u32 src/dst_addr_widths fields and rename the *_mask members.
> > I cannot commit to a timeline for that conversion (it touches a lot of
> > drivers across several subsystems), but I do intend to see it through.
> > 
> > Sending as RFC mainly to agree on the approach!
> 
> I have another idea. Why not having 8-bit mask for power-of-two and 8-bit mask
> for non-standard ones?
> 
> So, u8 power_of_2_mask represents the respective sizes directly as ORed values
> and u8 non_standard_mask (only to cover 3, 5, 6, and 7) does the original
> approach for it, id est ORed BIT():s of the sizes? And yes, I understand that
> it's not so KISS as above from data type point of view, but I think wei should
> never need to have a heavy bitmap() API calls just for them.

Well, that looks like much more disruptive than what we have now. Might
also make the transition not so simple. I'm also not too worried about
the heavy bitmap() as I don't think we need to handle this at any
fastpath. I think this is handled either in probe or at some preparatory
step, so not sure the churn of not doing it simpler is justifiable.

So personally, I'm not that keen in changing the approach unless Vinod
or Frank really ask for it.

- Nuno Sá

> 
> The whole exercise seems due to DMA_SLAVE_BUSWIDTH_3_BYTES. and we have less
> than dozen drivers that use it.
> 
> > I'm also not sure if the dma_slave_caps_get_{src,dst}_width_min() accessors
> > are worth having? Their purpose is purely to keep consumers from touching
> > the representation directly, so that the eventual u32 removal + mask
> > rename is a no-op for consumers. The alternative is to let consumers use
> > the bitmap directly (find_first_bit()/test_bit()/etc.) and just delete the
> > u32 members at the end. I mean, now we do have a bitmask so the _mask
> > suffix can of makes sense.
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>