Re: [RFC PATCH] dmaengine: xilinx_dma: Fix per-channel direction reporting via device_caps
From: Folker Schwesinger
Date: Sat Mar 14 2026 - 04:50:13 EST
On Mon Mar 9, 2026 at 8:28 AM CET, Rahul Navale wrote:
> I have applied provided patch (with kept RFC patch and debug stuff) and with
> 7e01511443c3 applied. logs:
>
> root@pdm3:~# dmesg | grep ptr_res
> [ 198.997591] ptr_res: ptr = 0x00000000
> ...
> [ 199.242820] ptr_res: ptr = 0x00000000
>
> Also I have applied provided patch (with kept RFC patch and debug stuff) and with
> 7e01511443c3 reverted. logs:
>
> root@pdm3:~# dmesg | grep ptr_res
> [ 60.480754] ptr_res_no: ptr = 0x00000000
> ...
> [ 60.600877] ptr_res_no: ptr = 0x00001770
> ...
> [ 60.725869] ptr_res_no: ptr = 0x00002ee0
> ...
> [ 60.850877] ptr_res_no: ptr = 0x00000000
> ...
> [ 60.975869] ptr_res_no: ptr = 0x00001770
> ...
This confirms that the residue_granularity field in dma_slave_caps,
which gets properly set since 7e01511443c3 affects progress tracking in
the PCM DMAEngine layer. Since Xilinx DMA advertises residue reporting
with segment granularity [1], PCM DMAEngine switches from software based
[2][3] progress tracking to hardware based progress tracking [4].
>From my understanding however, residue reporting of the Xilinx DMA is
incompatible with what the PCM DMAEngine expects. So the progression
pointer is stuck at 0.
As I'm neither an expert in the PCM subsystem nor very familiar with
residue reporting of the AXIDMA (and its limitations), I can't propose a
solution that fixes the issue for you. I did a quick check of the code to
see, if there is any way to force the DMAEngine PCM layer into software
tracking from your custom driver. But I think there's no API to
force-set the SND_DMAENGINE_PCM_FLAG_NO_RESIDUE bit in
dma_engine_pcm->flags from your custom driver.
Maybe there's a way to establish compatibility between PCM and AIXDMA in
this regard. But to figure that out, I think more eyes on the issue from
the audio experts and Xilinx/AMD engineers familiar with AXIDMA residue
reporting would be needed.
Just to double check, and to make sure the regression you're seeing is
not a combination of any additional, yet unknown side-effects, could you
perform one more test?
In dmaengine_pcm_pointer() (the function we just patched), could you
replace the call to snd_dmaengine_pcm_pointer() with
snd_dmaengine_pcm_pointer_no_residue() while keeping 7e01511443c3 active
and test if this fixes your issue or not?
[1]: https://elixir.bootlin.com/linux/v6.19.3/source/drivers/dma/xilinx/xilinx_dma.c#L3284
[2]: https://elixir.bootlin.com/linux/v7.0-rc3/source/sound/core/pcm_dmaengine.c#L136
[3]: https://elixir.bootlin.com/linux/v7.0-rc3/source/sound/core/pcm_dmaengine.c#L235
[4]: https://elixir.bootlin.com/linux/v7.0-rc3/source/sound/core/pcm_dmaengine.c#L251