From mboxrd@z Thu Jan 1 00:00:00 1970 From: jy0922.shim@samsung.com (Joonyoung Shim) Date: Fri, 26 Mar 2010 09:54:31 +0900 Subject: [PATCH v2] PL330: Add PL330 DMA controller driver 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> Message-ID: <4BAC05C7.2030208@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 3/26/2010 7:27 AM, 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. > > >> 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. > I can wait your implementation and wonder what is the issue also. I welcome you try other design and want better driver is committed at mainline kernel too. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752933Ab0CZAye (ORCPT ); Thu, 25 Mar 2010 20:54:34 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:55971 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752620Ab0CZAyd (ORCPT ); Thu, 25 Mar 2010 20:54:33 -0400 Date: Fri, 26 Mar 2010 09:54:31 +0900 From: Joonyoung Shim Subject: Re: [PATCH v2] PL330: Add PL330 DMA controller driver In-reply-to: <1b68c6791003251527s1ef985d2m4a309a3c09e31e0a@mail.gmail.com> To: jassi brar Cc: Dan Williams , Linus Walleij , "kyungmin.park@samsung.com" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Russell King - ARM Linux , Ben Dooks Message-id: <4BAC05C7.2030208@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) 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> X-OriginalArrivalTime: 26 Mar 2010 00:54:31.0206 (UTC) FILETIME=[E4EB6C60:01CACC7E] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/26/2010 7:27 AM, 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. > > >> 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. > I can wait your implementation and wonder what is the issue also. I welcome you try other design and want better driver is committed at mainline kernel too.