From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754820Ab2CGJdx (ORCPT ); Wed, 7 Mar 2012 04:33:53 -0500 Received: from caramon.arm.linux.org.uk ([78.32.30.218]:56065 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750934Ab2CGJds (ORCPT ); Wed, 7 Mar 2012 04:33:48 -0500 Date: Wed, 7 Mar 2012 09:30:26 +0000 From: Russell King - ARM Linux To: Guennadi Liakhovetski Cc: Vinod Koul , linux-kernel@vger.kernel.org, "'Jassi Brar'" , Linus Walleij Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel() Message-ID: <20120307093026.GM17370@n2100.arm.linux.org.uk> References: <1331022623.24656.191.camel@vkoul-udesk3> <1331035739.24656.201.camel@vkoul-udesk3> <1331101687.24656.319.camel@vkoul-udesk3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 07, 2012 at 10:18:42AM +0100, Guennadi Liakhovetski wrote: > I still don't see an answer to the very same question, that we've been > discussing over multiple threads and mails now: how do we use that, if > it's not a 1-to-1 mapping? I.e., many channels on many controllers can be > run-time configured for use with different client devices. Also the above > idea from Linus W doesn't directly address this. > > Following his clock / regulator analogy. There the correspondence is > clearly fixed: fixed clocks and power supplies are used with every > specific device. Whereas in our DMAC case it's not. > > I'm trying to think of an analogy, where you have several pools of > resources, and each consumer can use any of the resources on some of those > pools, but nothing pops up. Interrupts, GPIOs, clocks, regulators - they > all are fixed to their consumers. > > Also notice, this can become even worse, if we ever get controllers with > channels with different capabilities on them. So, I really would let the > DMAC driver do the mapping and not try to put it in the core. Well, I am quite convinced (being on my third or fourth DMA engine driver) that DMA engine does stuff quite wrongly when it comes to slave stuff. Why? The code required to support slave device transfers is very much the same for each driver (that's partly because I'm writing my drivers in the same way.) Essentially, slave channels aren't physical channels themselves, but virtual channels which get assigned to physical channels at some point. I would really like to see some common infrastructure for handling these virtual channels so I don't have to write yet another version of that code, and that's something I'll be working on. My main critera for selecting a virtual channel is the DMA request signal into the DMA controller itself, and nothing more. Most other non-specific configuration information (data register, data register width, burst size etc) comes from the peripheral driver. Any other data relevant to the DMA engine needs to come from the platform in some way, that being DT or platform data or whatever. For example, with a DMA engine which has two bus interfaces, where it matters which bus interface is used, that needs to be specified by the platform and not by the DMA engine itself nor the peripheral driver. That would also include, if relevant, which physical channels a virtual channel (dma request) could be routed to. Note that we've been omitting that from the PL08x driver so far - memory- to-memory requests are supposed to only be handled by a couple of channels which are designed for that purpose (so they don't flood the bus) but we currently allocate them to any channel...