From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common Date: Mon, 04 Feb 2013 15:27:09 +0100 Message-ID: <7655522.SvRnLo3eyU@wuerfel> References: <1359742975-10421-1-git-send-email-mporter@ti.com> <20130201213003.GW2637@n2100.arm.linux.org.uk> <510C58DF.3010103@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <510C58DF.3010103-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Sergei Shtylyov Cc: Matt Porter , Linux DaVinci Kernel List , Linux OMAP List , Russell King - ARM Linux , Linux Documentation List , Devicetree Discuss , Mark Brown , Linux MMC List , Linux Kernel Mailing List , Felipe Balbi , Vinod Koul , Rob Herring , Dan Williams , Linux SPI Devel List , Chris Ball , Linux ARM Kernel List List-Id: linux-mmc@vger.kernel.org On Saturday 02 February 2013 04:07:59 Sergei Shtylyov wrote: > On 02-02-2013 1:30, Russell King - ARM Linux wrote: > >> 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. > > > Hang on. This is one of the DMA implementations which is closely > > coupled with the USB and only the USB? If it is... > > > I thought this had been discussed _extensively_ before. I thought the > > resolution on it was: > > 1. It would not use the DMA engine API. > > 2. It would not live in arch/arm. > > 3. It would be placed nearby the USB driver it's associated with. > > > (1) because we don't use APIs just for the hell of it - think. Do we > > use the DMA engine API for PCI bus mastering ethernet controllers? No. > > Do we use it for PCI bus mastering SCSI controllers? No. Because the > > DMA is integral to the rest of the device. > > > The DMA engine API only makes sense if the DMA engine is a shared > > system resource. > > Thanks for such extensive wording in the support of my point. Actually there is another problem with the musb driver, which is that you can only have one DMA controller configured at build time, and that currently prevents us from building a kernel that supports both the Inventra and TUSB variants together. With multiplatform coming up for both ux500 and omap2, we will also have to make a decision about ux500 vs omap being supported in DMA mode. I can see two ways out of this: either we extend the musb driver to have run-time registration of the DMA controller, which duplicates infrastructure that already exists in the dmaengine API, or we make the dmaengine back-end for musb the default and require all platforms to use that if they want to coexist with other platforms and also use DMA support in musb. Note that the ux500_dma code in musb already uses dmaengine. It could probably be extended to support any platform that has a dmaengine driver for the DMA controller used in MUSB. Arnd