From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753320Ab0EIWvL (ORCPT ); Sun, 9 May 2010 18:51:11 -0400 Received: from mail-vw0-f46.google.com ([209.85.212.46]:47102 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751275Ab0EIWvI convert rfc822-to-8bit (ORCPT ); Sun, 9 May 2010 18:51:08 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oAI+QlY42T2r6TVoldQhit1KfsllSWLVsn1YU6He7zrAXAPJ501a/k78U1FsWJGO+l /F8E5N6MOQpyMeS1E5APmhcZnJHbmOx9y2odtNoPKI2mbkErxlCbwI7RdoywSTdcVD54 fpEir268jOXT9NYCPIgKNzzsHmlLfJG+Asomg= MIME-Version: 1.0 In-Reply-To: References: <1272848060-28049-1-git-send-email-linus.walleij@stericsson.com> Date: Mon, 10 May 2010 07:51:07 +0900 Message-ID: Subject: Re: [PATCH 0/7] DMAENGINE: fixes and PrimeCells From: jassi brar To: Dan Williams Cc: Linus Walleij , Russell King - ARM Linux , Ben Dooks , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 10, 2010 at 2:26 AM, Dan Williams wrote: > On Sun, May 9, 2010 at 3:06 AM, jassi brar wrote: >> This discussion is purely about what the current DMA API misses and what >> a generic DMA API should do. So, that the current DMA API fills up those >> gap, if possible. I would love to get started implementing the generic >> DMA API for reference but my priorities are decided by my employer. > > Well, the only significant miss that has been identified so far is > dynamic channel allocation for the device-to-mem case.  Everything > else can be done with small tweaks to the existing interface.  But > some of this discussion reminds me of Section 2.4 of > Documentaion/SubmittingPatches: > > 4) Don't over-design. > > Don't try to anticipate nebulous future cases which may or may not > be useful:  "Make it as simple as you can, and no simpler." There is a fine line between anticipating future requirements and over-designing. We already have Samsung's and STM's SoC sharing a DMAC IP. Esp with PrimeCells, we are soon likely to see SoCs sharing a peripheral IP with possibly different DMACs. Some elements may be ideal-design at the cost of over-design, but not all. Let us not simply brush aside all concerns as over-designing. From mboxrd@z Thu Jan 1 00:00:00 1970 From: jassisinghbrar@gmail.com (jassi brar) Date: Mon, 10 May 2010 07:51:07 +0900 Subject: [PATCH 0/7] DMAENGINE: fixes and PrimeCells In-Reply-To: References: <1272848060-28049-1-git-send-email-linus.walleij@stericsson.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, May 10, 2010 at 2:26 AM, Dan Williams wrote: > On Sun, May 9, 2010 at 3:06 AM, jassi brar wrote: >> This discussion is purely about what the current DMA API misses and what >> a generic DMA API should do. So, that the current DMA API fills up those >> gap, if possible. I would love to get started implementing the generic >> DMA API for reference but my priorities are decided by my employer. > > Well, the only significant miss that has been identified so far is > dynamic channel allocation for the device-to-mem case. ?Everything > else can be done with small tweaks to the existing interface. ?But > some of this discussion reminds me of Section 2.4 of > Documentaion/SubmittingPatches: > > 4) Don't over-design. > > Don't try to anticipate nebulous future cases which may or may not > be useful: ?"Make it as simple as you can, and no simpler." There is a fine line between anticipating future requirements and over-designing. We already have Samsung's and STM's SoC sharing a DMAC IP. Esp with PrimeCells, we are soon likely to see SoCs sharing a peripheral IP with possibly different DMACs. Some elements may be ideal-design at the cost of over-design, but not all. Let us not simply brush aside all concerns as over-designing.