Hi Will, 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 enough context/background.. So here it goes (apologies in advance if this turns out to be a lengthy mail...): 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, there 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 comments 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 its a hardware thing, there is not much we can do) Do let me know your views. best regards --Shashidhar Hiremath On Fri, Nov 4, 2011 at 12:36 PM, Shashidhar Hiremath <shashidharh@xxxxxxxxxxxxxxx> wrote: > Hi Will, > I agree with you that it should not be merged unless it improves > the performance. But I still feel that there might be some reason for > which the IP Vendor has provided an additional feature. So will this > not be a good feature to have as it will help in IP Validation for > different modes. > As far as the Kconfig option is concerned, the user need not always > modify it since the default case will still be Chained Mode. Also Such > Kconfig options for selecting mode is already used for stmmac > Ethernet Drivers. > > On Thu, Nov 3, 2011 at 8:48 PM, Will Newton <will.newton@xxxxxxxxx> wrote: >> On Thu, Nov 3, 2011 at 12:35 PM, Chris Ball <cjb@xxxxxxxxxx> wrote: >>> Hi, >>> >>> On Thu, Nov 03 2011, Shashidhar Hiremath wrote: >>>> Hi Chris, >>>> Can this patch be accepted by criteria that its an additional >>>> feature supported by the hardware and hence good to have the support >>>> 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 actually >>> 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 worthwhile. >> >> 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 advantage >> for one option over the other I can't see a good reason for merging >> it. At present it adds a question to the Kconfig that is pretty much >> impossible for the user to answer (do I turn this feature on or off? >> what is the advantage of choosing each option?). >> > > > > -- > regards, > Shashidhar Hiremath > -- regards, Shashidhar Hiremath -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
