From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754074Ab2CHNS6 (ORCPT ); Thu, 8 Mar 2012 08:18:58 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]:50257 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752974Ab2CHNSz (ORCPT ); Thu, 8 Mar 2012 08:18:55 -0500 Date: Thu, 8 Mar 2012 14:18:48 +0100 (CET) From: Guennadi Liakhovetski X-X-Sender: lyakh@axis700.grange To: Vinod Koul cc: Russell King - ARM Linux , linux-kernel@vger.kernel.org, "'Jassi Brar'" , Linus Walleij , Magnus Damm , Paul Mundt Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel() In-Reply-To: <1331211513.4657.67.camel@vkoul-udesk3> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Provags-ID: V02:K0:l8wkgC1H1L0/gZTrUIVbOrWhSz4NjXanWDzNb7Cpdrj jzD6EzwoniIFf/9fVAHjNNEUXWa0o0zIwTsvbwDZdRm9fQiQt0 9ZG2BEsZ6+TVytxykFfpAZKdS3dd9clUmwimXp7zfCCXzWLNQ6 TdZlh8/zF4z/t5SQQ5882Kj01uRsyNtKOBJH7RKCPRPCMCF0JA YL46eSFpKTYJS+mhUFNY3SmvyEH4FuRwGUV9e4XSJZyo2opYI7 c7JNZrDKIY9MybcfhuGtN/uxfgFauYzQfZcl7zRaRAcvuNFeqC zlebgd1wM/OKEFkZ2arcDXdu8ujO9ThIqSdkD6bo6AprMwXUzK 7ZFqh76YoGUk7IpZBjjz+wNtAbLH59T6B5Wz2hA7574C2qniiW Ei9aIVN1GHhfw== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 8 Mar 2012, Vinod Koul wrote: > On Thu, 2012-03-08 at 17:04 +0530, Vinod Koul wrote: > > On Thu, 2012-03-08 at 12:22 +0100, Guennadi Liakhovetski wrote: > > > On Thu, 8 Mar 2012, Vinod Koul wrote: > > > > > > > On Thu, 2012-03-08 at 11:16 +0100, Guennadi Liakhovetski wrote: > > > > > I still have the impression, that my specific use-case (sh-mobile), where > > > > > channels can be freely configured for use by _ANY_ client on one of > > > > > _SEVERAL_ DMAC instances, is not fully understood or taken into account. > > > > > For this driver any kind of fixed mapping means, that we'd have to use > > > > > both virtual channels and controllers, adding _a lot_ of complexity to the > > > > > DMAC driver and making the dmaengine core just an "obfuscation layer." > > > > > Yes, I remember Russell proposing core helpers for this. They would help, > > > > > but (1) when would they be available, (2) how well would they be suitable > > > > > for us, (3) they'd take the coding / maintainance burden away, but > > > > > wouldn't reduce complexity and run-time overhead. > > > > Lets try to address you case as well. > > > > On a typical platform > > > > > > Let's take the mackerel board with the sh7372 SoC. it's not the state of > > > the art, but that's what I'm currently working with and it should give us > > > a good enough idea > > > > > > > 1) how many dma controllers you have? > > > > > > currently supported 5 of 3 types (3 of type A, 1 of each of the types B > > > and C), all handled by the same driver > > > > > > > 2) how many clients you have > > > > > > huh... many. Maybe like 20 or more, and more, that are not yet supported, > > > using type A, and 1 for each of types B and C > > > > > > > 3) which client can use what controller channel? How is mapping decided, > > > > do you have a mux, is it hard wired by soc designers,....? > > > > > > In general - with all the current sh-mobile hardware, that I'm aware of - > > > there can be several controller instances on an SoC of each controller > > > type. Inside each type all instances and all channels are freely > > > configurable. So, of 20 Type A clients they can use any channels on any > > > one of the 3 type A controllers. Types B and C are "degenerate" cases, > > > there clients are practically hard-wired to a specific DMA controller. > > > > > > So, we don't have to decide on mappings for type A. We just pick up any > > > free channels on any controller and configure them accordingly. Whether > > > there's a mux somewhere - you can say so, but it's all inside the SoC, and > > > it's configured automatically ones you configure a physical channel to > > > serve a specific client. > > > > > > > Can you pls give a description so that we ensure all models fit in the > > > > final solution? > > > > > > That's what I've been trying to do since several days now... I've been > > > saying "multiple controllers with multiple channels all freely > > > configurable for any device from a list" again and again... Seems I'm > > > speaking some strange language, that noone understands. > > Okay. One more question before I can tell you how it can work for you > > without you sweating it out :-) > > > > So you have: > > case A: Here you have N dmacs and M controllers, any controller can use > > any channel, No constraints on channel assignments, right? > > case B: Some hardwired controllers P which can only be used by a set > > clients Q? > > > > Anything else I missed in your description? > Assuming I didn't miss... > > The case B can be handled without sweat by platforms channel mapping > information. > > Case A where we don't find that devices exist in map, thus being treated > as generic DMA channels and can be handled easily in sequence. So when > someone in Q request a channel it would get first channel in Ps > > This way we handle both of them in a transparent manner to both clients > and controllers. > > Perhaps we can also add capability to know that if channel is to be > searched in map or not - would be anyway required for non slave cases. Right, but I don't understand then what this gives us. You propose some channel maps, that will not be used for your "case A." Which means, for "case A" nothing changes. So, the reason for this whole thread hasn't been addressed: how to pass channel configuration to the DMA controller driver. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/