OMAP3: DSS: Kconfig changes to enable display options on OMAP3

The defconfig options for display are taken in the respective Kconfig to enable display by default on OMAP3 platforms

Signed-off-by Samreen <[email protected]>

---
Version4:
Remove the enabling of the display panels by default.

Version3:
Eliminate the separate default number of FBs for
different architecture. Keeping default FBs as 3 as before.

Version2:
Enables by default NEC panel used in zoom2/3/3630sdp,
instead of Sharp LQ043T1DG01 panel enabled in previous version of this patch.

 drivers/video/omap2/dss/Kconfig    |    6 ++++--
 drivers/video/omap2/omapfb/Kconfig |    1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

(quoted diff) +0 -0

b/drivers/video/omap2/dss/Kconfig index 43b6440..f3244a2 100644

drivers/video/omap2/dss/Kconfig +2 -1

@@ -1,6 +1,7 @@
 menuconfig OMAP2_DSS
         tristate "OMAP2/3 Display Subsystem support (EXPERIMENTAL)"
         depends on ARCH_OMAP2 || ARCH_OMAP3
+	default y
         help
           OMAP2/3 Display Subsystem support.
 

@@ -9,7 +10,7 @@ if OMAP2_DSS
 config OMAP2_VRAM_SIZE
 	int "VRAM size (MB)"
 	range 0 32
-	default 0
+	default 4
 	help
 	  The amount of SDRAM to reserve at boot time for video RAM use.
 	  This VRAM will be used by omapfb and other drivers

that need @@ -102,7 +103,8 @@ config OMAP2_DSS_FAKE_VSYNC config OMAP2_DSS_MIN_FCK_PER_PCK

drivers/video/omap2/dss/Kconfig +2 -1

 	int "Minimum FCK/PCK ratio (for scaling)"
 	range 0 32
-	default 0
+	default 4  if ARCH_OMAP2 || ARCH_OMAP3
+	default 0  if ARCH_OMAP4
 	help
 	  This can be used to adjust the minimum FCK/PCK ratio.

drivers/video/omap2/omapfb/Kconfig +1 -0

index 65149b2..923bf48 100644
@@ -1,6 +1,7 @@
 menuconfig FB_OMAP2
         tristate "OMAP2/3 frame buffer support (EXPERIMENTAL)"
         depends on FB && OMAP2_DSS
+	default y
 
 	select OMAP2_VRAM
 	select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3

Hi,
Any more comments on this patch?

Warm Regards,
Samreen

Quoted 33 lines · Samreen

The defconfig options for display are taken in the respective Kconfig to enable display by default on OMAP3 platforms

Signed-off-by Samreen <[email protected]>

---
Version4:
Remove the enabling of the display panels by default.

Version3:
Eliminate the separate default number of FBs for
different architecture. Keeping default FBs as 3 as before.

Version2:
Enables by default NEC panel used in zoom2/3/3630sdp,
instead of Sharp LQ043T1DG01 panel enabled in previous version of this patch.

 drivers/video/omap2/dss/Kconfig    |    6 ++++--
 drivers/video/omap2/omapfb/Kconfig |    1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

(quoted diff) +0 -0

b/drivers/video/omap2/dss/Kconfig index 43b6440..f3244a2 100644

drivers/video/omap2/dss/Kconfig +1 -0

@@ -1,6 +1,7 @@
 menuconfig OMAP2_DSS
         tristate "OMAP2/3 Display Subsystem support (EXPERIMENTAL)"
         depends on ARCH_OMAP2 || ARCH_OMAP3
+	default y
         help
           OMAP2/3 Display Subsystem support.
 

Quoted 11 lines

drivers/video/omap2/dss/Kconfig +1 -1

@@ -9,7 +10,7 @@ if OMAP2_DSS
 config OMAP2_VRAM_SIZE
 	int "VRAM size (MB)"
 	range 0 32
-	default 0
+	default 4
 	help
 	  The amount of SDRAM to reserve at boot time for video RAM use.
 	  This VRAM will be used by omapfb and other drivers

that need @@ -102,7 +103,8 @@ config OMAP2_DSS_FAKE_VSYNC config OMAP2_DSS_MIN_FCK_PER_PCK

drivers/video/omap2/dss/Kconfig config OMAP2_DSS_FAKE_VSYNC · line 107

Quoted 5 lines

drivers/video/omap2/dss/Kconfig +2 -1

 	int "Minimum FCK/PCK ratio (for scaling)"
 	range 0 32
-	default 0
+	default 4  if ARCH_OMAP2 || ARCH_OMAP3
+	default 0  if ARCH_OMAP4

Quoted 16 lines

drivers/video/omap2/dss/Kconfig +0 -0

 	help
 	  This can be used to adjust the minimum FCK/PCK ratio.

drivers/video/omap2/omapfb/Kconfig +1 -0

index 65149b2..923bf48 100644
@@ -1,6 +1,7 @@
 menuconfig FB_OMAP2
         tristate "OMAP2/3 frame buffer support (EXPERIMENTAL)"
         depends on FB && OMAP2_DSS
+	default y
 
 	select OMAP2_VRAM
 	select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3

Quoted 2 lines · Samreen

Hi,
Any more comments on this patch?

I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not looked kindly at. Shouldn't they be enabled in the arch/arm/configs config file, if they are wanted?

Tony, do you have opinnion on this? Should DSS features be enabled by default in the Kconfig files, or only in the board config file?

Quoted 9 lines · Tomi Valkeinen

Quoted 2 lines · Samreen

Hi,
Any more comments on this patch?

I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not looked kindly at. Shouldn't they be enabled in the arch/arm/configs config file, if they are wanted?

Quoted 2 lines

Tony, do you have opinnion on this? Should DSS features be enabled by default in the Kconfig files, or only in the board config file?

The best thing would be to have DSS y if ARCH_OMAP2PLUS or similar, then have all the features built in and pass the configuration options in platform_data. That still allows disabling certain features with Kconfig if needed for memory consumption etc. But the omap2plus_defconfig should "just work" on all the boards.

Quoted 10 lines · Tony Lindgren

Quoted 9 lines · Tomi Valkeinen

Quoted 2 lines · Samreen

Hi,
Any more comments on this patch?

I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not looked kindly at. Shouldn't they be enabled in the arch/arm/configs config file, if they are wanted?

Quoted 8 lines

Quoted 2 lines

Tony, do you have opinnion on this? Should DSS features be enabled by default in the Kconfig files, or only in the board config file?

The best thing would be to have DSS y if ARCH_OMAP2PLUS or similar, then have all the features built in and pass the configuration options in platform_data. That still allows disabling certain features with Kconfig if needed for memory consumption etc. But the omap2plus_defconfig should "just work" on all the boards.

Personally, I'd much rather see DSS core and optional features default to being built as a module.

Other than a splash screen, there's no reason DSS is needed for a minimal boot.

Quoted 24 lines · Kevin Hilman

Quoted 10 lines · Tony Lindgren

Quoted 9 lines · Tomi Valkeinen

Quoted 2 lines · Samreen

Hi,
Any more comments on this patch?

I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not looked kindly at. Shouldn't they be enabled in the arch/arm/configs config file, if they are wanted?

Quoted 8 lines

Quoted 2 lines

Tony, do you have opinnion on this? Should DSS features be enabled by default in the Kconfig files, or only in the board config file?

The best thing would be to have DSS y if ARCH_OMAP2PLUS or similar, then have all the features built in and pass the configuration options in platform_data. That still allows disabling certain features with Kconfig if needed for memory consumption etc. But the omap2plus_defconfig should "just work" on all the boards.

Personally, I'd much rather see DSS core and optional features default to being built as a module.

Quoted 2 lines

Other than a splash screen, there's no reason DSS is needed for a minimal boot.

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.

Quoted 3 lines · ext Tony Lindgren

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.

Quoted 11 lines · Tomi Valkeinen

Quoted 3 lines · ext Tony Lindgren

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.

Quoted 3 lines · Paul Mundt

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.

I wish we could just do "default m if ARCH_OMAP2PLUS_TYPICAL".. But meanwhile setting it as a module in omap2plus_defconfig does the trick though like you say.

Quoted 5 lines · Tony Lindgren

Quoted 3 lines · Paul Mundt

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.

Quoted 4 lines

I wish we could just do "default m if ARCH_OMAP2PLUS_TYPICAL".. But meanwhile setting it as a module in omap2plus_defconfig does the trick though like you say.

Something like this should be quite doable if the Kconfig fragments work is ever completed. If this is something that interests you you may wish to give it a bit of a nudge :-)