From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mundt Date: Thu, 18 Nov 2010 06:18:50 +0000 Subject: Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Message-Id: <20101118061850.GB17539@linux-sh.org> List-Id: References: <1288063074-8879-1-git-send-email-samreen@ti.com> <1289915437.2668.107.camel@tubuntu> <20101116193843.GZ9264@atomide.com> <8762vxcaco.fsf@deeprootsystems.com> <20101116201054.GC9264@atomide.com> <1289996891.26444.16.camel@tubuntu> In-Reply-To: <1289996891.26444.16.camel@tubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tomi Valkeinen Cc: ext Tony Lindgren , Kevin Hilman , "ext Nilofer, Samreen" , Grazvydas Ignotas , "Hiremath, Vaibhav" , "Quadros Roger (Nokia-MS/Helsinki)" , "Guruswamy, Senthilvadivu" , "linux-omap@vger.kernel.org" , "linux-fbdev@vger.kernel.org" On Wed, Nov 17, 2010 at 02:28:11PM +0200, Tomi Valkeinen wrote: > On Tue, 2010-11-16 at 21:10 +0100, ext Tony Lindgren wrote: > > Sure a module would be even better. My point is that the selection of > > all the features should be enabled by default and the board options come > > from platform_data. > > Ok, let's build DSS & all panel drivers as modules by default. > > Somehow I've gotten the impression from linux ml that enabling features > by default is bad. But perhaps it's more about intervening features than > normal drivers. > The general rule is to avoid default enabling unless you really need it, but it still remains optional (which is why it's not being selected, instead). Some, like gpiolib, have come up with WANT/NEED options for the platform code to select in order to work out the desired behaviour, and you may benefit from a similar approach for your subsystem if it's really that integral for some parts. The flip side of course is that if you expect your users to primarily be using the defconfigs provided, you can simply leave it default disabled in the Kconfig and set the options you want in the defconfigs. Unless you can say with certainty that all OMAP3 boards are going to want DSS enabled or modular by default, it's almost always better to just leave it up to the defconfigs. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mundt Subject: Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Date: Thu, 18 Nov 2010 15:18:50 +0900 Message-ID: <20101118061850.GB17539@linux-sh.org> References: <1288063074-8879-1-git-send-email-samreen@ti.com> <1289915437.2668.107.camel@tubuntu> <20101116193843.GZ9264@atomide.com> <8762vxcaco.fsf@deeprootsystems.com> <20101116201054.GC9264@atomide.com> <1289996891.26444.16.camel@tubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from 124x34x33x190.ap124.ftth.ucom.ne.jp ([124.34.33.190]:43916 "EHLO master.linux-sh.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754734Ab0KRGT1 (ORCPT ); Thu, 18 Nov 2010 01:19:27 -0500 Content-Disposition: inline In-Reply-To: <1289996891.26444.16.camel@tubuntu> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tomi Valkeinen Cc: ext Tony Lindgren , Kevin Hilman , "ext Nilofer, Samreen" , Grazvydas Ignotas , "Hiremath, Vaibhav" , "Quadros Roger (Nokia-MS/Helsinki)" , "Guruswamy, Senthilvadivu" , "linux-omap@vger.kernel.org" , "linux-fbdev@vger.kernel.org" On Wed, Nov 17, 2010 at 02:28:11PM +0200, Tomi Valkeinen wrote: > On Tue, 2010-11-16 at 21:10 +0100, ext Tony Lindgren wrote: > > Sure a module would be even better. My point is that the selection of > > all the features should be enabled by default and the board options come > > from platform_data. > > Ok, let's build DSS & all panel drivers as modules by default. > > Somehow I've gotten the impression from linux ml that enabling features > by default is bad. But perhaps it's more about intervening features than > normal drivers. > The general rule is to avoid default enabling unless you really need it, but it still remains optional (which is why it's not being selected, instead). Some, like gpiolib, have come up with WANT/NEED options for the platform code to select in order to work out the desired behaviour, and you may benefit from a similar approach for your subsystem if it's really that integral for some parts. The flip side of course is that if you expect your users to primarily be using the defconfigs provided, you can simply leave it default disabled in the Kconfig and set the options you want in the defconfigs. Unless you can say with certainty that all OMAP3 boards are going to want DSS enabled or modular by default, it's almost always better to just leave it up to the defconfigs.