[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <510C4B60.20802@mvista.com>
Date: Sat, 02 Feb 2013 03:10:24 +0400
From: Sergei Shtylyov <sshtylyov@...sta.com>
To: balbi@...com
CC: Matt Porter <mporter@...com>,
Linux DaVinci Kernel List
<davinci-linux-open-source@...ux.davincidsp.com>,
Chris Ball <cjb@...top.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>,
Tony Lindgren <tony@...mide.com>,
Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Linux MMC List <linux-mmc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Rob Herring <rob.herring@...xeda.com>,
Grant Likely <grant.likely@...retlab.ca>,
Vinod Koul <vinod.koul@...el.com>,
Rob Landley <rob@...dley.net>, Dan Williams <djbw@...com>,
Linux SPI Devel List
<spi-devel-general@...ts.sourceforge.net>,
Linux OMAP List <linux-omap@...r.kernel.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
Hello.
On 02-02-2013 0:56, Felipe Balbi wrote:
>>> good point, do you wanna send some patches ?
>> I have already sent them countless times and even stuck CPPI 4.1 support (in
>> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
>> patch. :-(
> sticking into arch/arm/common/ wasn't a nice move.
Like with EDMA we have nothing else to do with CPPI 4.1 being shared by
DaVinci-like and OMAP-like SOCs. Thank TI for creatring this mess. And
actually even that is not a good place since I think I know of a MIPS SoC
having CPPI 4.1 as well, just out of tree.
> But then again, so
> wasn't asking for the patch to be removed :-s
Unfortunately, Russell has done it -- all that was discuseed without me in
the loop even. :-/
>>> I guess to make the MUSB side simpler we would need musb-dma-engine glue
>>> to map dmaengine to the private MUSB API. Then we would have some
>>> starting point to also move inventra (and anybody else) to dmaengine
>>> API.
>> Why? Inventra is a dedicated device's private DMA controller, why make
>> universal DMA driver for it?
> because it doesn't make sense to support multiple DMA APIs. We can check
> from MUSB's registers if it was configured with Inventra DMA support and
> based on that we can register MUSB's own DMA Engine to dmaengine API.
I still disagree. IMO drivers/dma/ is for standalone DMA engines. Else we
could stick every bus mastering device's DMA engines there. CPPI 4.1 is in
design standlone DMA engine, despite all in-tree implementations having it as
subblock of MUSB and serving only MUSB.
WBR, Sergei
--
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/
Powered by blists - more mailing lists