From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752851Ab0CYXMs (ORCPT ); Thu, 25 Mar 2010 19:12:48 -0400 Received: from mail-pw0-f46.google.com ([209.85.160.46]:47604 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752722Ab0CYXMr convert rfc822-to-8bit (ORCPT ); Thu, 25 Mar 2010 19:12:47 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=M2QBu3uihC3jmVmThMTZorrhj7otGBbGzaaDp/JwwaQi4jnLaN8qWzizwImDZHQxmC zrm5IrpA+/SYRQUHI8uJviF97bHmvH1DLRxvVVBuv0XucQhWi5M2z92IDtwVSo01WZTj pjR+vvTSJ4CS9BmcZXIBeTMDUxzy1YMkmFPdo= MIME-Version: 1.0 In-Reply-To: <1b68c6791003251527s1ef985d2m4a309a3c09e31e0a@mail.gmail.com> References: <4BAAD5BB.7050101@samsung.com> <1b68c6791003242234h106d9530p12b5a046a906227e@mail.gmail.com> <63386a3d1003250130w6f34854ag2ca163799e9b7bed@mail.gmail.com> <1b68c6791003250517y4e2789baoe147e5982c363682@mail.gmail.com> <4BAB7D9F.4070807@intel.com> <1b68c6791003251527s1ef985d2m4a309a3c09e31e0a@mail.gmail.com> Date: Thu, 25 Mar 2010 16:12:46 -0700 X-Google-Sender-Auth: a9e6aeca9a801d3f Message-ID: Subject: Re: [PATCH v2] PL330: Add PL330 DMA controller driver From: Dan Williams To: jassi brar Cc: Linus Walleij , Joonyoung Shim , "kyungmin.park@samsung.com" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Russell King - ARM Linux , Ben Dooks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 25, 2010 at 3:27 PM, jassi brar wrote: > On Fri, Mar 26, 2010 at 12:13 AM, Dan Williams wrote: >> jassi brar wrote: >>>> >>>> Perhaps Joonyoung can simply port over the stuff >>>> you need to this driver if you show your code. >>> >>> Having worked on Samsung SoCs(with PL330 DMAC) based products, I would be >>> _very_ surprised if any user found this implementation useful. >>> Let alone testing, this implementation can't even explain usability >>> for fast peripherals >>> with shallow FIFOs. I didn't give feedback for this patch because I am >>> not sure if this >>> is the right way to go at all. >> >> This is the wrong attitude.  If it were not for a simple oversight >> Joonyoung's driver would already be upstream for the past two kernel >> releases.  So you need to work together to improve that driver to >> incorporate what you need. > Nothing wrong in attitude here. > Giving feedback on the code only comes after one is convinced with the > overall approach taken. The last time I raised the PL330 driver issue, > most people were not enthusiastic with this drivers/dma/ approach. > I wasn't active mainline discussions when the driver was originally > submitted a few months ago. > And now my replies are not very 'polite' because theres a lot going on > in the background that people in public threads don't know about. Thanks for clarifying. > > >> It sounds like you just need to add an extension for the arch specific dma >> api. > I actually plan more than that. > Apart from inefficient design, JoonYoung's driver has made some fatal > assumptions > about PL330, which will result in DMA aborts if used with SoCs that implement > configuration of PL330 that is very different from Samsung SoCs' > Of course, I address all such issues that I can think of, in my implementation. Ok, I'll rely on acked-by's from the interested parties once your driver is out as I do not have a vested interest in this hardware, just the dmaengine framework issues. -- Dan