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:	Fri, 11 Mar 2016 10:45:52 +0100
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Vinod Koul <vinod.koul@...el.com>
Cc:	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Dan Williams <dan.j.williams@...el.com>,
	dmaengine@...r.kernel.org, Chen-Yu Tsai <wens@...e.org>,
	linux-sunxi@...glegroups.com,
	Emilio López <emilio@...pez.com.ar>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dma: sun4i: expose block size and wait cycle
 configuration to DMA users

On Fri, 11 Mar 2016 11:56:07 +0530
Vinod Koul <vinod.koul@...el.com> wrote:

> On Wed, Mar 09, 2016 at 12:06:27PM +0100, Boris Brezillon wrote:
> > On Tue, 8 Mar 2016 08:25:47 +0530
> > Vinod Koul <vinod.koul@...el.com> wrote:
> > > 
> > > Why does dmaengine need to wait? Can you explain that
> > 
> > I don't have an answer for that one, but when I set WAIT_CYCLES to 1
> > for the NAND use case it does not work. So I guess it is somehow
> > related to how the DRQ line is controlled on the device side...
> 
> Is the WAIT cycle different for different usages or same for all
> usages/channels?
> 

In Allwinner BSP they adapt it on a per slave device basis, but since
DMA channels are dynamically allocated, you can't know in advance which
physical channel will be attached to a specific device.

Another option I considered was adding a new cell to the sun4i DT
binding to encode these WAIT_CYCLES and BLOCK_SIZE information. But I'm
not sure adding that to the DT is a good idea (not to mention that it
would break DT ABI again, and given the last discussions on this topic,
I'm not sure it's a good idea :-/).


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ