linux-kernel - Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

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:	Sat, 2 Feb 2013 14:48:53 -0500
From:	Matt Porter <mporter@...com>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Sergei Shtylyov <sshtylyov@...sta.com>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	"Cousson, Benoit" <b-cousson@...com>,
	Arnd Bergmann <arnd@...db.de>,
	Linux Documentation List <linux-doc@...r.kernel.org>,
	Vinod Koul <vinod.koul@...el.com>,
	Linux MMC List <linux-mmc@...r.kernel.org>,
	Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Landley <rob@...dley.net>, Dan Williams <djbw@...com>,
	Linux SPI Devel List 
	<spi-devel-general@...ts.sourceforge.net>,
	Chris Ball <cjb@...top.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to
 arm/common

On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote:
> * Matt Porter <mporter@...com> [130202 10:10]:
> > If it doesn't work, work with Vinod to fix the api. It's expected,
> > I'm working on dmaengine API changes right now to deal with a
> > limitation of EDMA that needs to be abstracted.
> 
> Regarding the DMA API limitations, I'm only aware of lack of capability
> to configure autoincrement at the device end. And that keeps us from
> converting all GPMC related devices using omap SDMA to use the DMA API.
> 
> Are there other limitations currently known with the DMA API?

Yes, I called one out when this was first posted as an RFC and was
working it in parallel with this support. This one blocks AM33XX support
in mmc and is the reason I split all of the mmc support out of the base
edma dmaengine for am33xx series. Independent of the blockage, whatever
we finally settle on to address this API need will also cleanup the use
of magic values in the davinci mmc driver (that's part of the second
thread below).

RFC posting:
https://patchwork.kernel.org/patch/1583531/
Posting with initial attempt at a caps api:
http://www.spinics.net/lists/linux-mmc/msg18351.html

Also, I haven't fully vetted the situation with cyclic transfers and
EDMA, however, I'm pretty sure that we'll need some API changes there.
The reason is that some Davinci platforms have no FIFO on their McASP
implementation (that was a new feature added on DA8xx and also AM33xx).
As such they have audio support implemented using ping-pong buffering
via an SRAM buffer. There's been a number of patches ahead of all this
that myself and others have worked upstream to get the SRAM stuff to be
Davinci-independent (genalloc). But, at the end of all of this, there's
no notion in a cyclic transfer of doing synchronized ping-pong buffering
using two chain channels. This is how it is implemented (and documented
in EDMA docs going back to the DSPs this IP first showed up on) using
the private API. I'll be looking at this soon, but, I'm more interested
in 1) getting the base support in 2) then the mmc stuff blocking DT
populated platforms using omap_hsmmc (split out and posted) 3) v3 of the
caps api w/ vinod's concerns address (working it not)

Normally, I'm not going to bring up the cyclic transfer issue until I
have some code to show or reference for discussion...but it's worth
being aware. But, in any case, I'm confident that will gate having the
mcasp driver that am33xx also uses converted to dmaengine.  Except for
the gpmc limitation you menationed, that's the last in kernel user of
the privat edma api needed to be converted such that we can kill off
arch/arm/common/edma.c once it's taken in.

-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/