From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755900Ab2CSLcn (ORCPT ); Mon, 19 Mar 2012 07:32:43 -0400 Received: from mga11.intel.com ([192.55.52.93]:43708 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753143Ab2CSLcm (ORCPT ); Mon, 19 Mar 2012 07:32:42 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="130485199" Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel() From: Vinod Koul To: Guennadi Liakhovetski Cc: Russell King - ARM Linux , linux-kernel@vger.kernel.org, "'Jassi Brar'" , Linus Walleij , Magnus Damm , Paul Mundt In-Reply-To: References: <1331101687.24656.319.camel@vkoul-udesk3> <20120307093026.GM17370@n2100.arm.linux.org.uk> <20120307103112.GP17370@n2100.arm.linux.org.uk> <20120307124620.GT17370@n2100.arm.linux.org.uk> <20120307142634.GA18787@n2100.arm.linux.org.uk> <20120307162755.GB18787@n2100.arm.linux.org.uk> <1331188201.4657.51.camel@vkoul-udesk3> <1331204128.4657.54.camel@vkoul-udesk3> <1331206459.4657.59.camel@vkoul-udesk3> <1331211513.4657.67.camel@vkoul-udesk3> <1331284918.4657.69.camel@vkoul-udesk3> <1331285959.4657.76.camel@vkoul-udesk3> <1331520476.4657.79.camel@vkoul-udesk3> Content-Type: text/plain; charset="UTF-8" Date: Mon, 19 Mar 2012 17:07:01 +0530 Message-ID: <1332157021.7180.5.camel@vkoul-udesk3> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2012-03-16 at 10:36 +0100, Guennadi Liakhovetski wrote: > On Mon, 12 Mar 2012, Vinod Koul wrote: > > > On Fri, 2012-03-09 at 13:20 +0100, Guennadi Liakhovetski wrote: > > > It can be made to work as long as there's only one DMAC group with > > > configurable channels and all other DMACs are dedicated to specific > > > peripherals, yes. I don't know whether there are already now or are > > > approaching any platforms with multiple reconfigurable groups. > > And that is what I am talking about. > > > > Having specific channel mapping given by platform for all channels which > > are to be used dedicated. And a pool of channels which can be used by > > anyone (if they can be) on a platform. > > > > Does this proposal sound good for others as well. I think we can target > > this for next merge cycle, we are too late for the current one. > > Ok, let me try to summarise, what this would mean for sh-mobile: > > 1. this proposal introduces a new special case: with or without a mapping, > that will have to be handled in affected client and DMA controller > drivers. E.g., on sh-mobile some devices might on some systems use > channels from "general purpose" DMA controllers (no mapping), on other > systems it will be a dedicated controller (fixed mapping). that should work. The mapping is platform specific, so I expect the board handling code for that one to tell dmaengine the mapping. On device A: controller P can be generic but on some other device it can be dedicated. > > 2. this will break, if we get more than 1 "general purpose" type with > different supported client sets. So, we develop a new API with a > pre-programmed limitation. No, see above > > 3. this will mean a substantial driver and platform code modification. > Nothing super-complex, but still some. Again No to driver, Yes to platform mapping part, which is again device specfic > > 4. we'll need a 3-stage channel allocation / configuration: request, > filter, config. Whereas with my configuration-parameter proposal it's just > one stage: allocate-and-configure. Its not about stages, it about doing the right thing. Which happens to make dmaengine aware of the mapping which exists for a certain device and give you the channels based on how hardware is mapped. If we get this right then we dont need to worry about filtering as well, that can go away. With Russell's approach it just request_config one single step to get channel and get it configured for slave. > > So, yes, this would be doable, but it doesn't look like a very good > solution to me. -- ~Vinod