Re: [RFC PATCH] dmaengine: xilinx_dma: device-wide directions cause ASoC cyclic DMA regression

[Folker Schwesinger]

Hi,

On Wed Feb 11, 2026 at 3:00 PM CET, Rahul Navale wrote:
> From: Rahul Navale <rahul.navale@xxxxxxx>
>
> On ZynqMP platforms using AXI DMA for ASoC PCM playback, upstream commit
> 7e01511443c3 ("dmaengine: xilinx_dma: Set dma_device directions") causes
> cyclic playback to fail after the first buffer period.
>
> Background:
> The upstream patch adds the following line in xilinx_dma_chan_probe():
>
>     xdev->common.directions |= chan->direction;
>
> Its purpose is to coalesce the directions of all enabled TX/RX channels into
> the device-wide dma_device.directions mask so that dma_get_slave_caps()
> works correctly. This is required by users such as IIO DMAEngine buffers
> that rely on device-wide capability reporting.
>
> Problem on ZynqMP ASoC audio (PCM):
> On ZynqMP, Xilinx DMA provides fixed-direction channels:
>
>     MM2S channels -> DMA_MEM_TO_DEV
>     S2MM channels -> DMA_DEV_TO_MEM
>
> ASoC dmaengine PCM relies on these fixed directions to select proper DMA
> channels for cyclic playback and capture. Aggregating directions device-wide
> can cause inconsistent capability reporting depending on channel probe order
> or device tree layout.
>

as far as I understand it, dma_device.directions lists all slave
directions the device supports across all channels. On the other hand,
dma_slave_caps.directions is a bitmask of slave directions the channel
supports.

While 7e01511443c3 ("dmaengine: xilinx_dma: Set dma_device directions")
fixed the dma_device.directions bit in Xilinx AXI DMA, it exposes
another short-coming of AXI DMA: as with the ASoC PCM, there may be DMA
engine devices with non-uniformly distributed slave capabilities per
device channels.
To adress this, there's the optional dma_device.device_caps() callback.
So I think the right way forward is to implement device_caps() for the
Xilinx AXI DMA and override dma_slave_caps.directions with the
channel-specific directions.
This should fix the issue for the ASoC PCM while preserving
functionality for the IIO DMAEngine buffer use-case.

I'm working on a patch that implements the proposed solution. I'll
post it in the next days after testing it with the IIO use case.
Unfortunately, I don't have access to a ZynqMP device, so to verify that
it actually fixes the regression in practice, I'll have to kindly ask
you, Rahul, for your feedback.

Best regards,
Folker