From: Rahul Navale <rahul.navale@ifm.com>

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.

This leads to the following behavior:
- The first DMA buffer plays correctly.
- Subsequent DMA periods repeat the first period indefinitely, breaking
  cyclic playback.

A temporary local patch that removes:

    xdev->common.directions |= chan->direction;

restores audio playback on ZynqMP platforms.

This RFC patch is a workaround to demonstrate a ZynqMP ASoC cyclic PCM
regression that appears in v6.12.36+ (backport of 7e01511443c3).

The workaround restores PCM playback but may regress users relying on
dma_get_slave_caps() (e.g. IIO DMAEngine buffers). The goal is to start
discussion on the correct upstream fix that supports both ASoC PCM and IIO.

Fixes: 7e01511443c3 ("dmaengine: xilinx_dma: Set dma_device directions")
Signed-off-by: Rahul Navale <rahul.navale@ifm.com>
---
 drivers/dma/xilinx/xilinx_dma.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index aff046b03ef7..8da86e322c7a 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -2938,8 +2938,6 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
 		return -EINVAL;
 	}
 
-	xdev->common.directions |= chan->direction;
-
 	/* Request the interrupt */
 	chan->irq = of_irq_get(node, chan->tdest);
 	if (chan->irq < 0)
-- 
2.34.1

Hi,

On Wed Feb 11, 2026 at 3:00 PM CET, Rahul Navale wrote:
> From: Rahul Navale <rahul.navale@ifm.com>
>
> 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