Re: [RFC PATCH] dmaengine: xilinx_dma: Fix per-channel direction reporting via device_caps

[Marek Vasut <marex@nabladev.com>]

On 3/14/26 9:35 AM, Folker Schwesinger wrote:
> 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

I came to the same conclusion, that the residue handling is broken in 
the Xilinx DMA driver for cyclic transfers, and the fix is below, with 
two extra fixes on top:

https://lore.kernel.org/dmaengine/20260316221943.160375-1-marex@nabladev.com/
https://lore.kernel.org/dmaengine/20260316221728.160139-1-marex@nabladev.com/
https://lore.kernel.org/dmaengine/20260316222530.163815-1-marex@nabladev.com/