All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Cc: ext Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@deeprootsystems.com>,
	"ext Nilofer, Samreen" <samreen@ti.com>,
	Grazvydas Ignotas <notasas@gmail.com>,
	"Hiremath, Vaibhav" <hvaibhav@ti.com>,
	"Quadros Roger (Nokia-MS/Helsinki)" <roger.quadros@nokia.com>,
	"Guruswamy, Senthilvadivu" <svadivu@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
Date: Thu, 18 Nov 2010 06:18:50 +0000	[thread overview]
Message-ID: <20101118061850.GB17539@linux-sh.org> (raw)
In-Reply-To: <1289996891.26444.16.camel@tubuntu>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Paul Mundt <lethal@linux-sh.org>
To: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Cc: ext Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@deeprootsystems.com>,
	"ext Nilofer, Samreen" <samreen@ti.com>,
	Grazvydas Ignotas <notasas@gmail.com>,
	"Hiremath, Vaibhav" <hvaibhav@ti.com>,
	"Quadros Roger (Nokia-MS/Helsinki)" <roger.quadros@nokia.com>,
	"Guruswamy, Senthilvadivu" <svadivu@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
Date: Thu, 18 Nov 2010 15:18:50 +0900	[thread overview]
Message-ID: <20101118061850.GB17539@linux-sh.org> (raw)
In-Reply-To: <1289996891.26444.16.camel@tubuntu>

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.

  reply	other threads:[~2010-11-18  6:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-26  3:17 [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Samreen
2010-10-26  3:29 ` Samreen
2010-11-16  6:09 ` Nilofer, Samreen
2010-11-16  6:21   ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display Nilofer, Samreen
2010-11-16 13:50   ` Tomi Valkeinen
2010-11-16 13:50     ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Tomi Valkeinen
2010-11-16 19:38     ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display Tony Lindgren
2010-11-16 19:38       ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Tony Lindgren
2010-11-16 19:55       ` Kevin Hilman
2010-11-16 19:55         ` Kevin Hilman
2010-11-16 20:10         ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display Tony Lindgren
2010-11-16 20:10           ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Tony Lindgren
2010-11-17 12:28           ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display Tomi Valkeinen
2010-11-17 12:28             ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Tomi Valkeinen
2010-11-18  6:18             ` Paul Mundt [this message]
2010-11-18  6:18               ` Paul Mundt
2010-11-18 16:44               ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display Tony Lindgren
2010-11-18 16:44                 ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Tony Lindgren
2010-11-18 18:38                 ` Paul Mundt
2010-11-18 18:38                   ` Paul Mundt
2010-11-18 19:10                   ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display Tony Lindgren
2010-11-18 19:10                     ` [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3 Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101118061850.GB17539@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=hvaibhav@ti.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=notasas@gmail.com \
    --cc=roger.quadros@nokia.com \
    --cc=samreen@ti.com \
    --cc=svadivu@ti.com \
    --cc=tomi.valkeinen@nokia.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.