From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Hogan Subject: Re: [PATCH 1/1] [PATCH v4 1/1] mmc: Support of DUAL BUFFER DESC[ring] mode for dw_mmc Date: Sat, 19 Nov 2011 01:34:35 +0000 Message-ID: <20111119013435.GA19582@balrog> References: <1317123568-5203-1-git-send-email-shashidharh@vayavyalabs.com> <4E8BBD76.9020001@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:60051 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751541Ab1KSBeo (ORCPT ); Fri, 18 Nov 2011 20:34:44 -0500 Received: by wwe5 with SMTP id 5so6249780wwe.1 for ; Fri, 18 Nov 2011 17:34:43 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Shashidhar Hiremath Cc: Will Newton , Chris Ball , Jaehoon Chung , Shawn Guo , Wolfram Sang , Philip Rakity , Zhangfei Gao , Will Newton , James Hogan , Kyungmin Park , Matt Fleming , linux-mmc@vger.kernel.org, Sandeep Pendharkar , Rayagond Kokatanur Hi Shashidhar, On Mon, Nov 14, 2011 at 09:32:25PM +0530, Shashidhar Hiremath wrote: > Hi Will, >=20 > Just following up since i did not see any response from you on my > earlier mail.. In previous mail, im not sure whether i gave you enoug= h > context/background.. So here it goes (apologies in advance if this > turns out to be a lengthy mail...): >=20 > 1>At Vayavya Labs, our work is to make sure that drivers for SNPS > designware IP is available in kernel.org. One of the > mandates/requirements from SNPS is that the driver submitted to > kernel.org should support all the features/configurations of the IP. > The bigger picture being that once this is done, SNPS customers dont > have to write code for any specific feature/configuration since it is > already available in the driver and they can start using it > immediately... > 2>As such, it is required that code for dual descriptors be also > present in the driver submitted to kernel.org.. In future there, ther= e > could be some person wanting to use this feature of the IP.. > 3>Also note that in kconfig, there does not have to be a choice > between this mode and chained mode since the default will always be > chained mode. STM Ethernet MAC driver already has such a kind of > support.. If this is not acceptable, do you feel the code should be > wrapped in some totally different preprocessor directive with comment= s > in the driver explaining the same? > 4>With regards to your points on performance, I am open to look at it > and see where we can make improvements in the driver (if any... if it= s > a hardware thing, there is not much we can do) Can I suggest you try running mmc_test with and without the dual descriptor mode. It has a bunch of performance tests in it. Cheers James >=20 > Do let me know your views. >=20 > best regards > --Shashidhar Hiremath >=20 > On Fri, Nov 4, 2011 at 12:36 PM, Shashidhar Hiremath > wrote: > > Hi Will, > > =A0 I agree with you that it should not be merged =A0unless it impr= oves > > the performance. But I still feel that there might be some reason f= or > > which the IP Vendor has provided an additional feature. So will thi= s > > not be a good feature to have as it will help in IP Validation for > > different modes. > > =A0As far as the Kconfig option is concerned, the user need not alw= ays > > modify it since the default case will still be Chained Mode. Also S= uch > > Kconfig options for selecting mode is already =A0used for stmmac > > Ethernet Drivers. > > > > On Thu, Nov 3, 2011 at 8:48 PM, Will Newton = wrote: > >> On Thu, Nov 3, 2011 at 12:35 PM, Chris Ball wrote= : > >>> Hi, > >>> > >>> On Thu, Nov 03 2011, Shashidhar Hiremath wrote: > >>>> Hi Chris, > >>>> =A0 Can this patch be accepted by criteria that its an additiona= l > >>>> feature supported by the hardware and hence good to have the sup= port > >>>> in the driver.Also note the patch has been tested. > >>> > >>> I think Will and James should make the call on that. > >>> > >>> My own opinion is that it's not usually a good idea to merge code= that > >>> increases complexity for no performance gain; if the feature is a= ctually > >>> important, someone should find a way to finish it and measure a > >>> performance gain (the gain can be in any of bandwidth, memory, or > >>> lower CPU utilization) with it, to prove that the change is worth= while. > >> > >> I'm inclined to agree. I don't want to feel like I am blocking > >> inclusion of anyone's hard work, but unless there is a clear advan= tage > >> for one option over the other I can't see a good reason for mergin= g > >> it. At present it adds a question to the Kconfig that is pretty mu= ch > >> impossible for the user to answer (do I turn this feature on or of= f? > >> what is the advantage of choosing each option?). > >> > > > > > > > > -- > > regards, > > Shashidhar Hiremath > > >=20 >=20 >=20 > --=20 > regards, > Shashidhar Hiremath > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" = in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html