Hi All,

This is a custom tool that can be used to bring up DMA slave devices.
It consists of a user-level utility and a companion device driver that
communicate via IOCTL.

The tool is likely need some polishing, but I would like first get some
feedback to ensure there is interest.

I also tested it only on x86 and have little idea on how channel names
on other architectures look like. That could especially impact the way
dma_request_channel() treats user-provided target DMA channel names, as
exposed via /sys/class/dma.

Thanks!

Alexander Gordeev (2):
  dmaengine/dma-slave: DMA slave device xfer passthrough driver
  tools/dma-slave: DMA slave device transfer utility

 drivers/dma/Kconfig            |   7 +
 drivers/dma/Makefile           |   1 +
 drivers/dma/dma-slave.c        | 246 +++++++++++++++++++++++++
 include/uapi/linux/dma-slave.h |  30 +++
 tools/Makefile                 |  11 +-
 tools/dma/Makefile             |  20 ++
 tools/dma/dma-slave.c          | 321 +++++++++++++++++++++++++++++++++
 7 files changed, 631 insertions(+), 5 deletions(-)
 create mode 100644 drivers/dma/dma-slave.c
 create mode 100644 include/uapi/linux/dma-slave.h
 create mode 100644 tools/dma/Makefile
 create mode 100644 tools/dma/dma-slave.c

-- 
2.51.0

On Sat, Feb 21, 2026 at 02:22:46PM +0100, Alexander Gordeev wrote:
> Hi All,
>
> This is a custom tool that can be used to bring up DMA slave devices.
> It consists of a user-level utility and a companion device driver that
> communicate via IOCTL.
>
> The tool is likely need some polishing, but I would like first get some
> feedback to ensure there is interest.
>
> I also tested it only on x86 and have little idea on how channel names
> on other architectures look like. That could especially impact the way
> dma_request_channel() treats user-provided target DMA channel names, as
> exposed via /sys/class/dma.

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.

Frank

>
> Thanks!
>
> Alexander Gordeev (2):
>   dmaengine/dma-slave: DMA slave device xfer passthrough driver
>   tools/dma-slave: DMA slave device transfer utility
>
>  drivers/dma/Kconfig            |   7 +
>  drivers/dma/Makefile           |   1 +
>  drivers/dma/dma-slave.c        | 246 +++++++++++++++++++++++++
>  include/uapi/linux/dma-slave.h |  30 +++
>  tools/Makefile                 |  11 +-
>  tools/dma/Makefile             |  20 ++
>  tools/dma/dma-slave.c          | 321 +++++++++++++++++++++++++++++++++
>  7 files changed, 631 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/dma/dma-slave.c
>  create mode 100644 include/uapi/linux/dma-slave.h
>  create mode 100644 tools/dma/Makefile
>  create mode 100644 tools/dma/dma-slave.c
>
> --
> 2.51.0
>

On 24-02-26, 17:34, Frank Li wrote:
> On Sat, Feb 21, 2026 at 02:22:46PM +0100, Alexander Gordeev wrote:
> > Hi All,
> >
> > This is a custom tool that can be used to bring up DMA slave devices.
> > It consists of a user-level utility and a companion device driver that
> > communicate via IOCTL.
> >
> > The tool is likely need some polishing, but I would like first get some
> > feedback to ensure there is interest.
> >
> > I also tested it only on x86 and have little idea on how channel names
> > on other architectures look like. That could especially impact the way
> > dma_request_channel() treats user-provided target DMA channel names, as
> > exposed via /sys/class/dma.
> 
> 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 ..?

-- 
~Vinod

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?

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

> ~Vinod

Thanks!

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

On Thu, Feb 26, 2026 at 12:37:47PM +0530, Vinod Koul wrote:
> > 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.

Well, the idea is to trigger xfers using custom out-of-band tooling.

> > 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

Yes, one could say so. It transfers off-CPU memory in one of FPGA
implementations, which does not need any xfer setup.

When attached to a camera however the xfer is triggered using a private
tool that uses i2c - exactly as you guys noticed.

The dmaengine driver for Avalon-MM Interface is not upstreamed yet.

> ~Vinod

Thanks!