Re: [RFC PATCH 0/2] dma: DMA slave device bringup tool

[Vinod Koul <vkoul@kernel.org>]

On 25-02-26, 22:10, Alexander Gordeev wrote:
> On Wed, Feb 25, 2026 at 03:07:06PM +0530, Vinod Koul wrote:
> 
> Hi Vinod, Frank,
> 
> > > I am not sure if it can work for general dma engine because it slave setting
> > > is tight coupling with FIFO settings and timing, some periphal require
> > > start dma firstly, then enable DMA. some perphial require enable DMA first
> > > then queue dma transfer.
> > > 
> > > burst len is also related with FIFO 's watermark settings.
> > 
> > Correct!
> > 
> > I like the idea but it is not practical. Every dmaengine is tied to the
> > peripheral for setting up the transfer. It is not a memcpy! How did you
> > test it, which controller was used ..?
> 
> I likely missing something, but how this differs from dmatest, which also
> lacks any controller-specific setup?

slave dma needs a peripheral to test. For example a spi/i2c etc
dmaengine in slave mode will not work untill unless there is some
signalling for dmaengine from peripheral to push/pull data.

> I tested it on Avalon-MM Interface on Arria 10 FPGA and found it super-
> useful - thus an attempt to share.

Which driver is that? Seems more like a memcpy masked as slave to me

-- 
~Vinod