Message-ID: <20191122050643.GM82508@vkoul-mobl>
Date:   Fri, 22 Nov 2019 10:36:43 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Alexander Gordeev <a.gordeev.box@...il.com>
Cc:     linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org,
        kbuild test robot <lkp@...el.com>
Subject: Re: [PATCH RFC v5 2/2] dmaengine: avalon-test: Intel Avalon-MM DMA
 Interface for PCIe test

On 14-11-19, 16:53, Alexander Gordeev wrote:
> On Thu, Nov 14, 2019 at 10:33:31AM +0530, Vinod Koul wrote:
> > On 06-11-19, 20:22, Alexander Gordeev wrote:
> > > This is a sample implementation of a driver using "avalon-dma" to
> > > perform data transfers between target device memory and system memory:
> > > 
> > >     +----------+    +----------+            +----------+
> > >     |   RAM    |<-->|  Avalon  |<---PCIe--->|   Host   |
> > >     +----------+    +----------+            +----------+
> > >
> > > The target device is expected to use only Avalon-MM DMA Interface for
> > > PCIe to initiate DMA transactions - without custom hardware specifics
> > > to make such transfers possible.
> > > 
> > > Unlike "dmatest" driver, the contents of DMAed data is not manipulated by
> > > "avalon-test" in any way. It is basically pass-through and the the data
> > > are fully dependent on the target device implementation. Thus, it is up
> > > to the users to analyze received or provide meaningful transmitted data.
> > 
> > Is this the only reason why you have not used dmatest. If so, why not
> > add the feature to dmatest to optionally not check the DMAed data
> > contents?
> 
> The main reason is that "dmatest" does not support DMA_SLAVE type of
> transactions.

That is correct, but it can be added!

> I considered adding DMA_SLAVE to "dmatest". But it would break the 
> current neat design and does not appear solving the issue of data
> verification. Simply besause in general DMA_SLAVE case there is no

Am not sure why it break the current design. We have to skip the
verification part. It would not only help you but also other to have
this support in dmatest

> data integrity criteria easily available to the driver. I.e if the
> data is a sensor image then verifying it in the driver would be
> pointless.

The biggest issue with slave and dmatest is how to setup slave

> So in case of "avalon-test" I offloaded the task of data verification
> to the user. The driver itself just streams user data to/from device.
> 
> In fact, this approach is not "avalon-dma" specific and could be used
> with any "dmaengine" compatible driver. Moreover, it would be quite
> useful for bringing up devices in embedded systems. I.e one could
> master a raw display frame in user space and DMA it via the driver -
> without graphic stack involved.

Right and having it in dmatest makes more sense for everyone :)

> The only missing functionality I could think of is using DMABUFs, but that
> is very easy to add.
> 
> Actually, "avalon-test" is rather a presentation of how I tested
> "avalon-dma". I understand "dmatest" is more easy to trust and I could
> probably make it working with DMA_SLAVE type. But that would entail
> hardware design requirements:
> 
>   - DMA slave should both respond to read and write transactions;
>   - data read should always be the same as data written;
> 
> I have such version of hardware design, but I doubt majorify of devices
> out there can honor the above requirements. 
> 
> Summarizing - I would suggest not to change "dmatest" and bring in a
> generalized version of "avalon-test" if you find it useful for a wider
> audience.

I would still think adding to dmatest makes more sense!

-- 
~Vinod

Powered by blists - more mailing lists