[RFC PATCH] dmaengine: xilinx_dma: device-wide directions cause ASoC cyclic DMA regression
Folker Schwesinger
dev at folker-schwesinger.de
Sun Feb 15 13:47:55 PST 2026
Hi,
On Wed Feb 11, 2026 at 3:00 PM CET, Rahul Navale wrote:
> From: Rahul Navale <rahul.navale at 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
More information about the linux-arm-kernel
mailing list