lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 2 Jan 2017 15:48:03 +0530
From:   Vinod Koul <vinod.koul@...el.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Jose Abreu <Jose.Abreu@...opsys.com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        vireshk@...nel.org
Subject: Re: dmaengine: dw-dmac: Custom cyclic API (Why?)

On Mon, Jan 02, 2017 at 10:38:00AM +0200, Andy Shevchenko wrote:
> On Fri, 2016-12-30 at 12:05 +0000, Jose Abreu wrote:
> > ++dw-dmac Maintainers
> > 
> > 
> > On 30-12-2016 11:32, Jose Abreu wrote:
> > > Hi All,
> > > 
> > > 
> > > I am going to work with dw-dmac AHB controller and I wanted to
> > > use SND_DMAENGINE_PCM. In order to use this, a standard DMA
> > > driver with cyclic support is needed. I found out that dw-dmac is
> > > capable of cyclic transfers but instead of using the DMA engine
> > > standard cyclic API it uses a custom API. Is there any specific
> > > reason for this? What is the effort to change the custom API to a
> > > standard DMA engine cyclic API?
> > > 
> 
> Because it was a predecessor of generic implementation.

And we don't have an implementation that uses this.

> I used to have some semi-finished patch to switch to generic API, though
> at that point I had no means to test it.
> 
> Since I eventually got iDMA 32-bit, which is used as LPE Audio DMA
> engine, support in my branch I might test it in the future, though I
> think someone else would be much faster than me.

no we can't, since the DSP is involved and takes control, so unless we do
lots of nasty hacks, it won't be testable. I don't see the ROI for such an
effort.

not sure about non intel ones, viresh?

btw, feel free to test and send patches if you have such a h/w

-- 
~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ