* [PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
@ 2013-03-28 12:48 ` Tomi Valkeinen
2013-03-28 15:18 ` Igor Grinberg
2013-03-28 12:48 ` [PATCH 02/28] ARM: OMAP: don't use reset_gpio from omap4_panda_dvi_device Tomi Valkeinen
` (28 subsequent siblings)
29 siblings, 1 reply; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:48 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
From: Archit Taneja <archit@ti.com>
The omap_dss_device's platform_enable/disable callbacks don't do anything for
any of the boards. The platform calls from the VENC driver will also be removed
in the future. Remove these calls from boards which have a VENC device.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-3430sdp.c | 12 ------------
arch/arm/mach-omap2/board-am3517evm.c | 11 -----------
arch/arm/mach-omap2/board-cm-t35.c | 11 -----------
arch/arm/mach-omap2/board-omap3evm.c | 11 -----------
arch/arm/mach-omap2/board-omap3stalker.c | 11 -----------
5 files changed, 56 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index ce812de..5fdb382 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -138,16 +138,6 @@ static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 0);
}
-static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
-
static struct omap_dss_device sdp3430_lcd_device = {
.name = "lcd",
.driver_name = "sharp_ls_panel",
@@ -175,8 +165,6 @@ static struct omap_dss_device sdp3430_tv_device = {
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = sdp3430_panel_enable_tv,
- .platform_disable = sdp3430_panel_disable_tv,
};
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index 9fb8590..25a0894 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -188,22 +188,11 @@ static struct omap_dss_device am3517_evm_lcd_device = {
.phy.dpi.data_lines = 16,
};
-static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void am3517_evm_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device am3517_evm_tv_device = {
.type = OMAP_DISPLAY_TYPE_VENC,
.name = "tv",
.driver_name = "venc",
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = am3517_evm_panel_enable_tv,
- .platform_disable = am3517_evm_panel_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index af2bb21..9c1895a 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -217,15 +217,6 @@ static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
}
-static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
.platform_enable = cm_t35_panel_enable_lcd,
@@ -258,8 +249,6 @@ static struct omap_dss_device cm_t35_tv_device = {
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = cm_t35_panel_enable_tv,
- .platform_disable = cm_t35_panel_disable_tv,
};
static struct omap_dss_device *cm_t35_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 48789e0..e86eb41 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -221,22 +221,11 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.platform_disable = omap3_evm_disable_lcd,
};
-static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void omap3_evm_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device omap3_evm_tv_device = {
.name = "tv",
.driver_name = "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable = omap3_evm_enable_tv,
- .platform_disable = omap3_evm_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 95c10b3..d427240 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -95,15 +95,6 @@ static void __init omap3_stalker_display_init(void)
return;
}
-static int omap3_stalker_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void omap3_stalker_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device omap3_stalker_tv_device = {
.name = "tv",
.driver_name = "venc",
@@ -113,8 +104,6 @@ static struct omap_dss_device omap3_stalker_tv_device = {
#elif defined(CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE)
.u.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
#endif
- .platform_enable = omap3_stalker_enable_tv,
- .platform_disable = omap3_stalker_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices
2013-03-28 12:48 ` [PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices Tomi Valkeinen
@ 2013-03-28 15:18 ` Igor Grinberg
0 siblings, 0 replies; 50+ messages in thread
From: Igor Grinberg @ 2013-03-28 15:18 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, Archit Taneja
On 03/28/13 14:48, Tomi Valkeinen wrote:
> From: Archit Taneja <archit@ti.com>
>
> The omap_dss_device's platform_enable/disable callbacks don't do anything for
> any of the boards. The platform calls from the VENC driver will also be removed
> in the future. Remove these calls from boards which have a VENC device.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This should have been done long long time ago...
Thanks!
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH 02/28] ARM: OMAP: don't use reset_gpio from omap4_panda_dvi_device
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
2013-03-28 12:48 ` [PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices Tomi Valkeinen
@ 2013-03-28 12:48 ` Tomi Valkeinen
2013-03-28 12:48 ` [PATCH 03/28] ARM: OMAP: Overo: Kconfig option for the display options Tomi Valkeinen
` (27 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:48 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
From: Archit Taneja <archit@ti.com>
gpio reset info is passed to the tfp410 panel driver via the panel's platform
data struct 'tfp410_platform_data'. The tfp driver doesn't use the reset_gpio
field in the omap4_panda_dvi_device struct. Remove this field.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 4be5cfc..4228e57 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -54,7 +54,6 @@ static struct omap_dss_device omap4_panda_dvi_device = {
.driver_name = "tfp410",
.data = &omap4_dvi_panel,
.phy.dpi.data_lines = 24,
- .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
.channel = OMAP_DSS_CHANNEL_LCD2,
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 03/28] ARM: OMAP: Overo: Kconfig option for the display options
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
2013-03-28 12:48 ` [PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices Tomi Valkeinen
2013-03-28 12:48 ` [PATCH 02/28] ARM: OMAP: don't use reset_gpio from omap4_panda_dvi_device Tomi Valkeinen
@ 2013-03-28 12:48 ` Tomi Valkeinen
2013-03-28 12:48 ` [PATCH 04/28] ARM: OMAP: 3430SDP: " Tomi Valkeinen
` (26 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:48 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.
This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.
This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Kconfig | 22 ++++++
arch/arm/mach-omap2/board-overo.c | 134 +++++++++++++++++++++++--------------
2 files changed, 107 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8111cd9..f30aadb 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -238,6 +238,28 @@ config MACH_OVERO
default y
select OMAP_PACKAGE_CBB
+choice
+ depends on MACH_OVERO
+ default MACH_OVERO_EXPANSION_PALO43
+ prompt "Overo Expansion Board"
+
+config MACH_OVERO_EXPANSION_PALO43
+ bool "Gumstix Overo Palo43 Expansion Board"
+ help
+ Palo43 Expansion board with Samsung 4.3" 480x272 LCD.
+
+config MACH_OVERO_EXPANSION_PALO35
+ bool "Gumstix Overo Palo35 Expansion Board"
+ help
+ Palo35 Expansion board with LG 3.5" 320x240 LCD.
+
+config MACH_OVERO_EXPANSION_SUMMIT
+ bool "Gumstix Overo Summit Expansion Board"
+ help
+ Summit expansion board with DVI output.
+
+endchoice
+
config MACH_OMAP3EVM
bool "OMAP 3530 EVM board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 86bab51..3253682 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -145,13 +145,72 @@ static void __init overo_init_smsc911x(void)
static inline void __init overo_init_smsc911x(void) { return; }
#endif
-/* DSS */
-static int lcd_enabled;
-static int dvi_enabled;
+#if defined(CONFIG_MACH_OVERO_EXPANSION_SUMMIT)
+
+static struct tfp410_platform_data dvi_panel = {
+ .i2c_bus_num = 3,
+ .power_down_gpio = -1,
+};
+
+static struct omap_dss_device overo_dvi_device = {
+ .name = "dvi",
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .driver_name = "tfp410",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *overo_dss_devices[] = {
+ &overo_dvi_device,
+};
+
+static struct omap_dss_board_info overo_dss_data = {
+ .num_devices = ARRAY_SIZE(overo_dss_devices),
+ .devices = overo_dss_devices,
+ .default_display_name = "dvi",
+};
+
+static void __init overo_display_init(void)
+{
+}
+
+#elif defined(CONFIG_MACH_OVERO_EXPANSION_PALO35)
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145
+static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(OVERO_GPIO_LCD_EN, 1);
+ gpio_set_value(OVERO_GPIO_LCD_BL, 1);
+ return 0;
+}
+
+static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(OVERO_GPIO_LCD_EN, 0);
+ gpio_set_value(OVERO_GPIO_LCD_BL, 0);
+}
+
+static struct omap_dss_device overo_lcd35_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "lcd35",
+ .driver_name = "lgphilips_lb035q02_panel",
+ .phy.dpi.data_lines = 24,
+ .platform_enable = overo_panel_enable_lcd,
+ .platform_disable = overo_panel_disable_lcd,
+};
+
+static struct omap_dss_device *overo_dss_devices[] = {
+ &overo_lcd35_device,
+};
+
+static struct omap_dss_board_info overo_dss_data = {
+ .num_devices = ARRAY_SIZE(overo_dss_devices),
+ .devices = overo_dss_devices,
+ .default_display_name = "lcd35",
+};
+
static struct gpio overo_dss_gpios[] __initdata = {
{ OVERO_GPIO_LCD_EN, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_EN" },
{ OVERO_GPIO_LCD_BL, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_BL" },
@@ -168,36 +227,15 @@ static void __init overo_display_init(void)
gpio_export(OVERO_GPIO_LCD_BL, 0);
}
-static struct tfp410_platform_data dvi_panel = {
- .i2c_bus_num = 3,
- .power_down_gpio = -1,
-};
+#elif defined(CONFIG_MACH_OVERO_EXPANSION_PALO43)
-static struct omap_dss_device overo_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device overo_tv_device = {
- .name = "tv",
- .driver_name = "venc",
- .type = OMAP_DISPLAY_TYPE_VENC,
- .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
-};
+#define OVERO_GPIO_LCD_EN 144
+#define OVERO_GPIO_LCD_BL 145
static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
gpio_set_value(OVERO_GPIO_LCD_EN, 1);
gpio_set_value(OVERO_GPIO_LCD_BL, 1);
- lcd_enabled = 1;
return 0;
}
@@ -205,7 +243,6 @@ static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
{
gpio_set_value(OVERO_GPIO_LCD_EN, 0);
gpio_set_value(OVERO_GPIO_LCD_BL, 0);
- lcd_enabled = 0;
}
static struct panel_generic_dpi_data lcd43_panel = {
@@ -222,34 +259,34 @@ static struct omap_dss_device overo_lcd43_device = {
.phy.dpi.data_lines = 24,
};
-#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
- defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
-static struct omap_dss_device overo_lcd35_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = "lcd35",
- .driver_name = "lgphilips_lb035q02_panel",
- .phy.dpi.data_lines = 24,
- .platform_enable = overo_panel_enable_lcd,
- .platform_disable = overo_panel_disable_lcd,
-};
-#endif
-
static struct omap_dss_device *overo_dss_devices[] = {
- &overo_dvi_device,
- &overo_tv_device,
-#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
- defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
- &overo_lcd35_device,
-#endif
&overo_lcd43_device,
};
static struct omap_dss_board_info overo_dss_data = {
.num_devices = ARRAY_SIZE(overo_dss_devices),
.devices = overo_dss_devices,
- .default_device = &overo_dvi_device,
+ .default_display_name = "lcd43",
+};
+
+static struct gpio overo_dss_gpios[] __initdata = {
+ { OVERO_GPIO_LCD_EN, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_EN" },
+ { OVERO_GPIO_LCD_BL, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_BL" },
};
+static void __init overo_display_init(void)
+{
+ if (gpio_request_array(overo_dss_gpios, ARRAY_SIZE(overo_dss_gpios))) {
+ printk(KERN_ERR "could not obtain DSS control GPIOs\n");
+ return;
+ }
+
+ gpio_export(OVERO_GPIO_LCD_EN, 0);
+ gpio_export(OVERO_GPIO_LCD_BL, 0);
+}
+
+#endif
+
static struct mtd_partition overo_nand_partitions[] = {
{
.name = "xloader",
@@ -438,8 +475,7 @@ static int __init overo_i2c_init(void)
}
static struct spi_board_info overo_spi_board_info[] __initdata = {
-#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
- defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
+#ifdef MACH_OVERO_EXPANSION_PALO35
{
.modalias = "lgphilips_lb035q02_panel-spi",
.bus_num = 1,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 04/28] ARM: OMAP: 3430SDP: Kconfig option for the display options
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (2 preceding siblings ...)
2013-03-28 12:48 ` [PATCH 03/28] ARM: OMAP: Overo: Kconfig option for the display options Tomi Valkeinen
@ 2013-03-28 12:48 ` Tomi Valkeinen
2013-03-28 12:48 ` [PATCH 05/28] ARM: OMAP: 4430SDP: " Tomi Valkeinen
` (25 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:48 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.
This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.
This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Kconfig | 13 ++++++++
arch/arm/mach-omap2/board-3430sdp.c | 63 +++++++++++++++++++++++------------
2 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f30aadb..17e02a3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -296,6 +296,19 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
+choice
+ depends on MACH_OMAP_3430SDP
+ default MACH_OMAP_3430SDP_EXPANSION_LCD
+ prompt "OMAP 3430 SDP video output"
+
+config MACH_OMAP_3430SDP_EXPANSION_LCD
+ bool "OMAP 3430 SDP with LCD"
+
+config MACH_OMAP_3430SDP_EXPANSION_DVI
+ bool "OMAP 3430 SDP with DVI"
+
+endchoice
+
config MACH_NOKIA_N800
bool
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 5fdb382..4acd4aa 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -105,6 +105,45 @@ static struct twl4030_keypad_data sdp3430_kp_data = {
.rep = 1,
};
+static struct omap_dss_device sdp3430_tv_device = {
+ .name = "tv",
+ .driver_name = "venc",
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_OMAP_3430SDP_EXPANSION_DVI)
+
+static void __init sdp3430_display_init(void)
+{
+}
+
+static struct tfp410_platform_data dvi_panel = {
+ .power_down_gpio = -1,
+ .i2c_bus_num = -1,
+};
+
+static struct omap_dss_device sdp3430_dvi_device = {
+ .name = "dvi",
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .driver_name = "tfp410",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *sdp3430_dss_devices[] = {
+ &sdp3430_dvi_device,
+ &sdp3430_tv_device,
+};
+
+static struct omap_dss_board_info sdp3430_dss_data = {
+ .num_devices = ARRAY_SIZE(sdp3430_dss_devices),
+ .devices = sdp3430_dss_devices,
+ .default_device = &sdp3430_dvi_device,
+};
+
+#elif defined(CONFIG_MACH_OMAP_3430SDP_EXPANSION_LCD)
+
#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
@@ -147,30 +186,8 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable = sdp3430_panel_disable_lcd,
};
-static struct tfp410_platform_data dvi_panel = {
- .power_down_gpio = -1,
- .i2c_bus_num = -1,
-};
-
-static struct omap_dss_device sdp3430_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device sdp3430_tv_device = {
- .name = "tv",
- .driver_name = "venc",
- .type = OMAP_DISPLAY_TYPE_VENC,
- .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
-};
-
-
static struct omap_dss_device *sdp3430_dss_devices[] = {
&sdp3430_lcd_device,
- &sdp3430_dvi_device,
&sdp3430_tv_device,
};
@@ -180,6 +197,8 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = &sdp3430_lcd_device,
};
+#endif
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc = 1,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 05/28] ARM: OMAP: 4430SDP: Kconfig option for the display options
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (3 preceding siblings ...)
2013-03-28 12:48 ` [PATCH 04/28] ARM: OMAP: 3430SDP: " Tomi Valkeinen
@ 2013-03-28 12:48 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 06/28] ARM: OMAP: DEVKIT8000: " Tomi Valkeinen
` (24 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:48 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.
This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.
This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Kconfig | 13 +++++++++++++
arch/arm/mach-omap2/dss-common.c | 39 +++++++++++++++++++++++++-------------
2 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 17e02a3..fcbcd6c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -413,6 +413,19 @@ config MACH_OMAP_4430SDP
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+choice
+ depends on MACH_OMAP_4430SDP
+ default MACH_OMAP_4430SDP_EXPANSION_LCD2
+ prompt "OMAP 4430 SDP video output"
+
+config MACH_OMAP_4430SDP_EXPANSION_LCD2
+ bool "OMAP 4430 SDP with second LCD panel"
+
+config MACH_OMAP_4430SDP_EXPANSION_PICO
+ bool "OMAP 4430 SDP with Pico DLP projector"
+
+endchoice
+
config MACH_OMAP4_PANDA
bool "OMAP4 Panda Board"
default y
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 4228e57..135fdd8 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -108,8 +108,21 @@ void __init omap4_panda_display_init_of(void)
/* OMAP4 Blaze display data */
+static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+ .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
+ .ls_oe_gpio = HDMI_GPIO_LS_OE,
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
+static struct omap_dss_device sdp4430_hdmi_device = {
+ .name = "hdmi",
+ .driver_name = "hdmi_panel",
+ .type = OMAP_DISPLAY_TYPE_HDMI,
+ .channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = &sdp4430_hdmi_data,
+};
+
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO 40
static struct nokia_dsi_panel_data dsi1_panel = {
.name = "taal",
@@ -134,6 +147,10 @@ static struct omap_dss_device sdp4430_lcd_device = {
.channel = OMAP_DSS_CHANNEL_LCD,
};
+#if defined(CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2)
+
+static void sdp4430_picodlp_init(void) { }
+
static struct nokia_dsi_panel_data dsi2_panel = {
.name = "taal",
.reset_gpio = 104,
@@ -158,19 +175,9 @@ static struct omap_dss_device sdp4430_lcd2_device = {
.channel = OMAP_DSS_CHANNEL_LCD2,
};
-static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
+#elif defined(CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO)
-static struct omap_dss_device sdp4430_hdmi_device = {
- .name = "hdmi",
- .driver_name = "hdmi_panel",
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = &sdp4430_hdmi_data,
-};
+#define DLP_POWER_ON_GPIO 40
static struct picodlp_panel_data sdp4430_picodlp_pdata = {
.picodlp_adapter_id = 2,
@@ -220,11 +227,17 @@ static struct omap_dss_device sdp4430_picodlp_device = {
.data = &sdp4430_picodlp_pdata,
};
+#endif
+
static struct omap_dss_device *sdp4430_dss_devices[] = {
&sdp4430_lcd_device,
+#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
&sdp4430_lcd2_device,
+#endif
&sdp4430_hdmi_device,
+#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO
&sdp4430_picodlp_device,
+#endif
};
static struct omap_dss_board_info sdp4430_dss_data = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 06/28] ARM: OMAP: DEVKIT8000: Kconfig option for the display options
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (4 preceding siblings ...)
2013-03-28 12:48 ` [PATCH 05/28] ARM: OMAP: 4430SDP: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 07/28] ARM: OMAP: OMAP3EVM: " Tomi Valkeinen
` (23 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen, Thomas Weber
Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.
This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.
This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Thomas Weber <weber@corscience.de>
---
arch/arm/mach-omap2/Kconfig | 13 +++++++
arch/arm/mach-omap2/board-devkit8000.c | 58 +++++++++++++++++++++-----------
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fcbcd6c..940903e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -206,6 +206,19 @@ config MACH_DEVKIT8000
default y
select OMAP_PACKAGE_CUS
+choice
+ depends on MACH_DEVKIT8000
+ default MACH_DEVKIT8000_EXPANSION_LCD
+ prompt "DEVKIT8000 video output"
+
+config MACH_DEVKIT8000_EXPANSION_LCD
+ bool "DEVKIT8000 with LCD"
+
+config MACH_DEVKIT8000_EXPANSION_DVI
+ bool "DEVKIT8000 with DVI"
+
+endchoice
+
config MACH_OMAP_LDP
bool "OMAP3 LDP board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 53056c3..e90808c 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -104,6 +104,24 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
+static struct regulator_consumer_supply devkit8000_vmmc1_supply[] = {
+ REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
+};
+
+/* ads7846 on SPI */
+static struct regulator_consumer_supply devkit8000_vio_supply[] = {
+ REGULATOR_SUPPLY("vcc", "spi2.0"),
+};
+
+static struct omap_dss_device devkit8000_tv_device = {
+ .name = "tv",
+ .driver_name = "venc",
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
+
static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
{
if (gpio_is_valid(dssdev->reset_gpio))
@@ -117,15 +135,6 @@ static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
gpio_set_value_cansleep(dssdev->reset_gpio, 0);
}
-static struct regulator_consumer_supply devkit8000_vmmc1_supply[] = {
- REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
-};
-
-/* ads7846 on SPI */
-static struct regulator_consumer_supply devkit8000_vio_supply[] = {
- REGULATOR_SUPPLY("vcc", "spi2.0"),
-};
-
static struct panel_generic_dpi_data lcd_panel = {
.name = "innolux_at070tn83",
.platform_enable = devkit8000_panel_enable_lcd,
@@ -140,6 +149,19 @@ static struct omap_dss_device devkit8000_lcd_device = {
.phy.dpi.data_lines = 24,
};
+static struct omap_dss_device *devkit8000_dss_devices[] = {
+ &devkit8000_lcd_device,
+ &devkit8000_tv_device,
+};
+
+static struct omap_dss_board_info devkit8000_dss_data = {
+ .num_devices = ARRAY_SIZE(devkit8000_dss_devices),
+ .devices = devkit8000_dss_devices,
+ .default_display_name = "lcd",
+};
+
+#elif defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
+
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio = -1,
.i2c_bus_num = 1,
@@ -153,16 +175,7 @@ static struct omap_dss_device devkit8000_dvi_device = {
.phy.dpi.data_lines = 24,
};
-static struct omap_dss_device devkit8000_tv_device = {
- .name = "tv",
- .driver_name = "venc",
- .type = OMAP_DISPLAY_TYPE_VENC,
- .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
-};
-
-
static struct omap_dss_device *devkit8000_dss_devices[] = {
- &devkit8000_lcd_device,
&devkit8000_dvi_device,
&devkit8000_tv_device,
};
@@ -170,8 +183,9 @@ static struct omap_dss_device *devkit8000_dss_devices[] = {
static struct omap_dss_board_info devkit8000_dss_data = {
.num_devices = ARRAY_SIZE(devkit8000_dss_devices),
.devices = devkit8000_dss_devices,
- .default_device = &devkit8000_lcd_device,
+ .default_display_name = "dvi",
};
+#endif
static uint32_t board_keymap[] = {
KEY(0, 0, KEY_1),
@@ -211,7 +225,9 @@ static struct gpio_led gpio_leds[];
static int devkit8000_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
int ret;
+#endif
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
@@ -220,6 +236,7 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
/* TWL4030_GPIO_MAX + 0 is "LCD_PWREN" (out, active high) */
devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
ret = gpio_request_one(devkit8000_lcd_device.reset_gpio,
@@ -228,9 +245,10 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
devkit8000_lcd_device.reset_gpio = -EINVAL;
printk(KERN_ERR "Failed to request GPIO for LCD_PWRN\n");
}
-
+#elif defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
/* gpio + 7 is "DVI_PD" (out, active low) */
dvi_panel.power_down_gpio = gpio + 7;
+#endif
return 0;
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 07/28] ARM: OMAP: OMAP3EVM: Kconfig option for the display options
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (5 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 06/28] ARM: OMAP: DEVKIT8000: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 08/28] ARM: OMAP: CM-T35: " Tomi Valkeinen
` (22 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.
This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.
This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Kconfig | 13 ++++++++++
arch/arm/mach-omap2/board-omap3evm.c | 46 +++++++++++++++++++++-------------
2 files changed, 41 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 940903e..4108d07 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -279,6 +279,19 @@ config MACH_OMAP3EVM
default y
select OMAP_PACKAGE_CBB
+choice
+ depends on MACH_OMAP3EVM
+ default MACH_OMAP3EVM_EXPANSION_LCD
+ prompt "OMAP 3530 EVM video output"
+
+config MACH_OMAP3EVM_EXPANSION_LCD
+ bool "OMAP 3530 EVM with LCD"
+
+config MACH_OMAP3EVM_EXPANSION_DVI
+ bool "OMAP 3530 EVM with DVI"
+
+endchoice
+
config MACH_OMAP3517EVM
bool "OMAP3517/ AM3517 EVM board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index e86eb41..2050679 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -149,6 +149,14 @@ static inline void __init omap3evm_init_smsc911x(void)
static inline void __init omap3evm_init_smsc911x(void) { return; }
#endif
+static struct omap_dss_device omap3_evm_tv_device = {
+ .name = "tv",
+ .driver_name = "venc",
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_OMAP3EVM_EXPANSION_LCD)
/*
* OMAP3EVM LCD Panel control signals
*/
@@ -159,7 +167,6 @@ static inline void __init omap3evm_init_smsc911x(void) { return; }
#define OMAP3EVM_LCD_PANEL_QVGA 154
#define OMAP3EVM_LCD_PANEL_RESB 155
#define OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO 210
-#define OMAP3EVM_DVI_PANEL_EN_GPIO 199
static struct gpio omap3_evm_dss_gpios[] __initdata = {
{ OMAP3EVM_LCD_PANEL_RESB, GPIOF_OUT_INIT_HIGH, "lcd_panel_resb" },
@@ -170,9 +177,6 @@ static struct gpio omap3_evm_dss_gpios[] __initdata = {
{ OMAP3EVM_LCD_PANEL_ENVDD, GPIOF_OUT_INIT_LOW, "lcd_panel_envdd" },
};
-static int lcd_enabled;
-static int dvi_enabled;
-
static void __init omap3_evm_display_init(void)
{
int r;
@@ -185,10 +189,6 @@ static void __init omap3_evm_display_init(void)
static int omap3_evm_enable_lcd(struct omap_dss_device *dssdev)
{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 0);
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
@@ -196,7 +196,6 @@ static int omap3_evm_enable_lcd(struct omap_dss_device *dssdev)
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
- lcd_enabled = 1;
return 0;
}
@@ -208,8 +207,6 @@ static void omap3_evm_disable_lcd(struct omap_dss_device *dssdev)
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
-
- lcd_enabled = 0;
}
static struct omap_dss_device omap3_evm_lcd_device = {
@@ -221,13 +218,25 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.platform_disable = omap3_evm_disable_lcd,
};
-static struct omap_dss_device omap3_evm_tv_device = {
- .name = "tv",
- .driver_name = "venc",
- .type = OMAP_DISPLAY_TYPE_VENC,
- .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct omap_dss_device *omap3_evm_dss_devices[] = {
+ &omap3_evm_lcd_device,
+ &omap3_evm_tv_device,
};
+static struct omap_dss_board_info omap3_evm_dss_data = {
+ .num_devices = ARRAY_SIZE(omap3_evm_dss_devices),
+ .devices = omap3_evm_dss_devices,
+ .default_display_name = "lcd",
+};
+
+#elif defined(CONFIG_MACH_OMAP3EVM_EXPANSION_DVI)
+
+#define OMAP3EVM_DVI_PANEL_EN_GPIO 199
+
+static void __init omap3_evm_display_init(void)
+{
+}
+
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio = OMAP3EVM_DVI_PANEL_EN_GPIO,
.i2c_bus_num = -1,
@@ -242,7 +251,6 @@ static struct omap_dss_device omap3_evm_dvi_device = {
};
static struct omap_dss_device *omap3_evm_dss_devices[] = {
- &omap3_evm_lcd_device,
&omap3_evm_tv_device,
&omap3_evm_dvi_device,
};
@@ -250,9 +258,11 @@ static struct omap_dss_device *omap3_evm_dss_devices[] = {
static struct omap_dss_board_info omap3_evm_dss_data = {
.num_devices = ARRAY_SIZE(omap3_evm_dss_devices),
.devices = omap3_evm_dss_devices,
- .default_device = &omap3_evm_lcd_device,
+ .default_display_name = "dvi",
};
+#endif
+
static struct regulator_consumer_supply omap3evm_vmmc1_supply[] = {
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (6 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 07/28] ARM: OMAP: OMAP3EVM: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 16:09 ` Igor Grinberg
2013-03-28 12:49 ` [PATCH 09/28] ARM: OMAP: AM3517EVM: " Tomi Valkeinen
` (21 subsequent siblings)
29 siblings, 1 reply; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap
Cc: Archit Taneja, Tomi Valkeinen, Mike Rapoport, Igor Grinberg
Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.
This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.
This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mike Rapoport <mike@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
---
arch/arm/mach-omap2/Kconfig | 13 ++++++
arch/arm/mach-omap2/board-cm-t35.c | 84 +++++++++++++++++++++---------------
2 files changed, 62 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4108d07..6e73cb4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -387,6 +387,19 @@ config MACH_CM_T35
select MACH_CM_T3730
select OMAP_PACKAGE_CUS
+choice
+ depends on MACH_CM_T35
+ default MACH_CM_T35_EXPANSION_LCD
+ prompt "CM-T35/CM-T3730 video output"
+
+config MACH_CM_T35_EXPANSION_LCD
+ bool "CM-T35/CM-T3730 with LCD"
+
+config MACH_CM_T35_EXPANSION_DVI
+ bool "CM-T35/CM-T3730 with DVI"
+
+endchoice
+
config MACH_CM_T3517
bool "CompuLab CM-T3517 module"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 9c1895a..1b34c96 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -187,32 +187,28 @@ static void __init cm_t35_init_nand(void)
static inline void cm_t35_init_nand(void) {}
#endif
+static struct omap_dss_device cm_t35_tv_device = {
+ .name = "tv",
+ .driver_name = "venc",
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_CM_T35_EXPANSION_LCD)
+
#define CM_T35_LCD_EN_GPIO 157
#define CM_T35_LCD_BL_GPIO 58
-#define CM_T35_DVI_EN_GPIO 54
-
-static int lcd_enabled;
-static int dvi_enabled;
static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
- lcd_enabled = 1;
-
return 0;
}
static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
{
- lcd_enabled = 0;
-
gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
}
@@ -231,36 +227,15 @@ static struct omap_dss_device cm_t35_lcd_device = {
.phy.dpi.data_lines = 18,
};
-static struct tfp410_platform_data dvi_panel = {
- .power_down_gpio = CM_T35_DVI_EN_GPIO,
- .i2c_bus_num = -1,
-};
-
-static struct omap_dss_device cm_t35_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device cm_t35_tv_device = {
- .name = "tv",
- .driver_name = "venc",
- .type = OMAP_DISPLAY_TYPE_VENC,
- .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
-};
-
static struct omap_dss_device *cm_t35_dss_devices[] = {
&cm_t35_lcd_device,
- &cm_t35_dvi_device,
&cm_t35_tv_device,
};
static struct omap_dss_board_info cm_t35_dss_data = {
.num_devices = ARRAY_SIZE(cm_t35_dss_devices),
.devices = cm_t35_dss_devices,
- .default_device = &cm_t35_dvi_device,
+ .default_display_name = "lcd",
};
static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
@@ -314,6 +289,45 @@ static void __init cm_t35_init_display(void)
}
}
+#elif defined(CONFIG_MACH_CM_T35_EXPANSION_DVI)
+
+#define CM_T35_DVI_EN_GPIO 54
+
+static struct tfp410_platform_data dvi_panel = {
+ .power_down_gpio = CM_T35_DVI_EN_GPIO,
+ .i2c_bus_num = -1,
+};
+
+static struct omap_dss_device cm_t35_dvi_device = {
+ .name = "dvi",
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .driver_name = "tfp410",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *cm_t35_dss_devices[] = {
+ &cm_t35_dvi_device,
+ &cm_t35_tv_device,
+};
+
+static struct omap_dss_board_info cm_t35_dss_data = {
+ .num_devices = ARRAY_SIZE(cm_t35_dss_devices),
+ .devices = cm_t35_dss_devices,
+ .default_display_name = "dvi",
+};
+
+static void __init cm_t35_init_display(void)
+{
+ int err;
+
+ err = omap_display_init(&cm_t35_dss_data);
+ if (err)
+ pr_err("CM-T35: failed to register DSS device\n");
+}
+
+#endif
+
static struct regulator_consumer_supply cm_t35_vmmc1_supply[] = {
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-28 12:49 ` [PATCH 08/28] ARM: OMAP: CM-T35: " Tomi Valkeinen
@ 2013-03-28 16:09 ` Igor Grinberg
2013-03-28 16:53 ` Tony Lindgren
2013-03-28 17:02 ` Tomi Valkeinen
0 siblings, 2 replies; 50+ messages in thread
From: Igor Grinberg @ 2013-03-28 16:09 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Mike Rapoport
On 03/28/13 14:49, Tomi Valkeinen wrote:
> Boards with multiple display options for the same video bus have all the
> possible linux display devices present at the same time. Only one of
> those devices should be used at a time, as the video bus cannot be
> shared.
Yes, only one can be used at a time, but you can switch at runtime...
>
> This model is hacky, and will be changed in the forthcoming DSS patches
> to a model where only one display device can be present on a single
> video bus.
What do you mean by "present"?
Is it active? or registered? or compiled in?
>
> This patch creates Kconfig options to select which of the display
> devices is present on the board. While this model is also somewhat
> hacky, and prevents us from using a single kernel image for all the
> display options, it allows us to make the DSS driver changes for DT
> adaptation. And with DT, the information about display devices can be
> passed from the bootloader, solving the mess.
Hmmm, the fact that we cannot use the same binary for multiple displays...
This does not sound right and good at all...
While we try to move to support multiple platforms in the same binary, we
cannot support multiple displays? I agree that the multiplatform stuff is
not really related, but you know what I mean...
I bet there must be a much better solution for DT support.
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-28 16:09 ` Igor Grinberg
@ 2013-03-28 16:53 ` Tony Lindgren
2013-03-28 17:12 ` Tomi Valkeinen
2013-03-28 17:02 ` Tomi Valkeinen
1 sibling, 1 reply; 50+ messages in thread
From: Tony Lindgren @ 2013-03-28 16:53 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Tomi Valkeinen, linux-omap, Archit Taneja, Mike Rapoport
* Igor Grinberg <grinberg@compulab.co.il> [130328 09:13]:
> On 03/28/13 14:49, Tomi Valkeinen wrote:
> > Boards with multiple display options for the same video bus have all the
> > possible linux display devices present at the same time. Only one of
> > those devices should be used at a time, as the video bus cannot be
> > shared.
>
> Yes, only one can be used at a time, but you can switch at runtime...
>
> >
> > This model is hacky, and will be changed in the forthcoming DSS patches
> > to a model where only one display device can be present on a single
> > video bus.
>
> What do you mean by "present"?
> Is it active? or registered? or compiled in?
>
> >
> > This patch creates Kconfig options to select which of the display
> > devices is present on the board. While this model is also somewhat
> > hacky, and prevents us from using a single kernel image for all the
> > display options, it allows us to make the DSS driver changes for DT
> > adaptation. And with DT, the information about display devices can be
> > passed from the bootloader, solving the mess.
>
> Hmmm, the fact that we cannot use the same binary for multiple displays...
> This does not sound right and good at all...
> While we try to move to support multiple platforms in the same binary, we
> cannot support multiple displays? I agree that the multiplatform stuff is
> not really related, but you know what I mean...
Yes that's not nice from usability point of view. Can we still switch
between LCD and DVI during the runtime? I thought the issue was registering
multiple LCD panels where only one can exist at a time?
> I bet there must be a much better solution for DT support.
Well the best legacy support option would be some fbdev/panel generic cmdline
option to specify which one to use. Maybe there is already something like
that available that the board-*.c files can parse and can be used also
later on with DT support to specify the preferred output?
What we don't want to do is add a board specific cmdline option as the
board-*.c files will be going away as soon as DT is usable for us and we
don't want to support a board specific cmdline after that. But if it's
a generic option then parsing it in the board-*.c file or the driver later
on can be supported.
Of course for some cases it might be possible to detect the configured
panel based on what's plugged in over i2c.
Regards,
Tony
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-28 16:53 ` Tony Lindgren
@ 2013-03-28 17:12 ` Tomi Valkeinen
2013-03-28 21:28 ` Tony Lindgren
0 siblings, 1 reply; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 17:12 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Igor Grinberg, linux-omap, Archit Taneja, Mike Rapoport
[-- Attachment #1: Type: text/plain, Size: 3534 bytes --]
On 2013-03-28 18:53, Tony Lindgren wrote:
> * Igor Grinberg <grinberg@compulab.co.il> [130328 09:13]:
>> On 03/28/13 14:49, Tomi Valkeinen wrote:
>>> Boards with multiple display options for the same video bus have all the
>>> possible linux display devices present at the same time. Only one of
>>> those devices should be used at a time, as the video bus cannot be
>>> shared.
>>
>> Yes, only one can be used at a time, but you can switch at runtime...
>>
>>>
>>> This model is hacky, and will be changed in the forthcoming DSS patches
>>> to a model where only one display device can be present on a single
>>> video bus.
>>
>> What do you mean by "present"?
>> Is it active? or registered? or compiled in?
>>
>>>
>>> This patch creates Kconfig options to select which of the display
>>> devices is present on the board. While this model is also somewhat
>>> hacky, and prevents us from using a single kernel image for all the
>>> display options, it allows us to make the DSS driver changes for DT
>>> adaptation. And with DT, the information about display devices can be
>>> passed from the bootloader, solving the mess.
>>
>> Hmmm, the fact that we cannot use the same binary for multiple displays...
>> This does not sound right and good at all...
>> While we try to move to support multiple platforms in the same binary, we
>> cannot support multiple displays? I agree that the multiplatform stuff is
>> not really related, but you know what I mean...
>
> Yes that's not nice from usability point of view. Can we still switch
> between LCD and DVI during the runtime? I thought the issue was registering
> multiple LCD panels where only one can exist at a time?
I guess I could've been more verbose in my descriptions. And I agree
this is not a nice change.
No, we can't switch between the LCD and DVI. But that's not strictly DSS
issue. The selection between LCD and DVI (or any other displays on the
same bus) are board specific things, sometimes requiring board specific
gpios or even things like i2c commands to muxes.
It works now because we have custom callbacks in the board files to do
those things, but it'll break with DT.
>> I bet there must be a much better solution for DT support.
>
> Well the best legacy support option would be some fbdev/panel generic cmdline
> option to specify which one to use. Maybe there is already something like
> that available that the board-*.c files can parse and can be used also
> later on with DT support to specify the preferred output?
>
> What we don't want to do is add a board specific cmdline option as the
> board-*.c files will be going away as soon as DT is usable for us and we
> don't want to support a board specific cmdline after that. But if it's
> a generic option then parsing it in the board-*.c file or the driver later
> on can be supported.
>
> Of course for some cases it might be possible to detect the configured
> panel based on what's plugged in over i2c.
I could look at using omapdss's module parameter for this. It has
default display parameter. Perhaps the board files could parse this, and
use it to decide which display to register. Perhaps that'd cause less
inconvenience.
It's still quite hacky, as you can only select one display. If there's a
board with two video outputs, and, say, 2 displays connected to each.
You can only select the display for one of the busses. Anyway, we don't
have that kind of board in the mainline, so it's not an issue.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-28 17:12 ` Tomi Valkeinen
@ 2013-03-28 21:28 ` Tony Lindgren
2013-03-29 4:27 ` Tomi Valkeinen
0 siblings, 1 reply; 50+ messages in thread
From: Tony Lindgren @ 2013-03-28 21:28 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Igor Grinberg, linux-omap, Archit Taneja, Mike Rapoport
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130328 10:16]:
> On 2013-03-28 18:53, Tony Lindgren wrote:
> >
> > Yes that's not nice from usability point of view. Can we still switch
> > between LCD and DVI during the runtime? I thought the issue was registering
> > multiple LCD panels where only one can exist at a time?
>
> I guess I could've been more verbose in my descriptions. And I agree
> this is not a nice change.
>
> No, we can't switch between the LCD and DVI. But that's not strictly DSS
> issue. The selection between LCD and DVI (or any other displays on the
> same bus) are board specific things, sometimes requiring board specific
> gpios or even things like i2c commands to muxes.
>
> It works now because we have custom callbacks in the board files to do
> those things, but it'll break with DT.
Well people are already used to changing between LCD and DVI.. So we
need some way of doing it with DT also.
How do you plan to change between LCD and DVI with DT? By using some
custom driver modules?
There's the capebus coming that can be used for that too, but in most
cases all the hardware is permanently connected with LCD and DVI. So
sounds like capebus should only be needed for the add on boards.
> >> I bet there must be a much better solution for DT support.
> >
> > Well the best legacy support option would be some fbdev/panel generic cmdline
> > option to specify which one to use. Maybe there is already something like
> > that available that the board-*.c files can parse and can be used also
> > later on with DT support to specify the preferred output?
> >
> > What we don't want to do is add a board specific cmdline option as the
> > board-*.c files will be going away as soon as DT is usable for us and we
> > don't want to support a board specific cmdline after that. But if it's
> > a generic option then parsing it in the board-*.c file or the driver later
> > on can be supported.
> >
> > Of course for some cases it might be possible to detect the configured
> > panel based on what's plugged in over i2c.
>
> I could look at using omapdss's module parameter for this. It has
> default display parameter. Perhaps the board files could parse this, and
> use it to decide which display to register. Perhaps that'd cause less
> inconvenience.
>
> It's still quite hacky, as you can only select one display. If there's a
> board with two video outputs, and, say, 2 displays connected to each.
> You can only select the display for one of the busses. Anyway, we don't
> have that kind of board in the mainline, so it's not an issue.
If we can use omapdss cmdline params for initializing the selected display,
that allows leaving out the kconfig selection, so that's much nicer for
distros etc.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-28 21:28 ` Tony Lindgren
@ 2013-03-29 4:27 ` Tomi Valkeinen
2013-03-29 15:47 ` Tony Lindgren
0 siblings, 1 reply; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-29 4:27 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Igor Grinberg, linux-omap, Archit Taneja, Mike Rapoport
[-- Attachment #1: Type: text/plain, Size: 2838 bytes --]
On 2013-03-28 23:28, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130328 10:16]:
>> On 2013-03-28 18:53, Tony Lindgren wrote:
>>>
>>> Yes that's not nice from usability point of view. Can we still switch
>>> between LCD and DVI during the runtime? I thought the issue was registering
>>> multiple LCD panels where only one can exist at a time?
>>
>> I guess I could've been more verbose in my descriptions. And I agree
>> this is not a nice change.
>>
>> No, we can't switch between the LCD and DVI. But that's not strictly DSS
>> issue. The selection between LCD and DVI (or any other displays on the
>> same bus) are board specific things, sometimes requiring board specific
>> gpios or even things like i2c commands to muxes.
>>
>> It works now because we have custom callbacks in the board files to do
>> those things, but it'll break with DT.
>
> Well people are already used to changing between LCD and DVI.. So we
> need some way of doing it with DT also.
>
> How do you plan to change between LCD and DVI with DT? By using some
> custom driver modules?
I don't know, but I guess we need board specific drivers.
Do you know if there are other similar cases for other busses? I mean, I
think this is a similar case than, say, having two i2c devices with the
same i2c-id on the same bus. Only one of the devices can be enabled, the
other must be disconnected. And how the connect/disconnect is made is
board specific.
> There's the capebus coming that can be used for that too, but in most
> cases all the hardware is permanently connected with LCD and DVI. So
> sounds like capebus should only be needed for the add on boards.
True.
Well, depends on how you look at it. From one point of view there's no
real difference whether the disabled device is physically on the board
or not, as it has to be disconnected. The details depend on the bus, but
for example for DSI I think the disabled device has to be totally
removed from the DSI bus with some mux or such.
But, from the other point of view, the devices are there, on the board,
and in some cases the HW has been designed to support switching the
displays during runtime.
So what I wish is that I could make the linux device for the display to
be removed when it's disabled. I believe that can be done, but I guess
it requires a board specific driver, with some custom user interface to
do that.
And it would be different user interface than currently, which is again
not so nice. Currently the devices are always there, with their sysfs
files, and those sysfs files are used to enable/disable the devices. If
the device is removed, the sysfs files get removed also...
But I would really like to get rid of the current model, which I think
was a very bad design decision.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-29 4:27 ` Tomi Valkeinen
@ 2013-03-29 15:47 ` Tony Lindgren
0 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2013-03-29 15:47 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Igor Grinberg, linux-omap, Archit Taneja, Mike Rapoport
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130328 21:32]:
> On 2013-03-28 23:28, Tony Lindgren wrote:
> >
> > How do you plan to change between LCD and DVI with DT? By using some
> > custom driver modules?
>
> I don't know, but I guess we need board specific drivers.
>
> Do you know if there are other similar cases for other busses? I mean, I
> think this is a similar case than, say, having two i2c devices with the
> same i2c-id on the same bus. Only one of the devices can be enabled, the
> other must be disconnected. And how the connect/disconnect is made is
> board specific.
No good ideas, unless it all can be controlled via pinctrl framework?
With pinctrl framework the dss driver could request named modes like
"dvi" and "lcd" for sets of pins. And the panel driver could implement
pinctrl functions, so when a named mode "lcd" is requested by the dss
driver, the data lines configured and GPIO and regulators get set.
If we are really muxing the dss data lines, then using that might
make sense.
Note that there may be issues related to waiting sleeping regulators etc.
> > There's the capebus coming that can be used for that too, but in most
> > cases all the hardware is permanently connected with LCD and DVI. So
> > sounds like capebus should only be needed for the add on boards.
>
> True.
>
> Well, depends on how you look at it. From one point of view there's no
> real difference whether the disabled device is physically on the board
> or not, as it has to be disconnected. The details depend on the bus, but
> for example for DSI I think the disabled device has to be totally
> removed from the DSI bus with some mux or such.
Yes, so if we're really muxing lines, then maybe using the pinctrl
framework makes sense until we have the capebus available?
> But, from the other point of view, the devices are there, on the board,
> and in some cases the HW has been designed to support switching the
> displays during runtime.
>
> So what I wish is that I could make the linux device for the display to
> be removed when it's disabled. I believe that can be done, but I guess
> it requires a board specific driver, with some custom user interface to
> do that.
Sounds like capebus will do that when it's available.
> And it would be different user interface than currently, which is again
> not so nice. Currently the devices are always there, with their sysfs
> files, and those sysfs files are used to enable/disable the devices. If
> the device is removed, the sysfs files get removed also...
You can probably keep the user interface the same if the dss driver
requests changing the panels, and can probably support both pinctrl
muxing and capebus pretty easily. The biggest change would be that when
capebus is available there's more than one struct device for the panels,
so the .dts files would have to be updated for that.
Or maybe the pinctrl handler could already easily add and remove devices
depending which named mode is requested by the dss driver, I don't know.
> But I would really like to get rid of the current model, which I think
> was a very bad design decision.
Yes agreed, we need to get rid of the board-*.c file callback functions.
Regards,
Tony
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-28 16:09 ` Igor Grinberg
2013-03-28 16:53 ` Tony Lindgren
@ 2013-03-28 17:02 ` Tomi Valkeinen
2013-03-31 9:17 ` Igor Grinberg
1 sibling, 1 reply; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 17:02 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Mike Rapoport
[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]
On 2013-03-28 18:09, Igor Grinberg wrote:
> On 03/28/13 14:49, Tomi Valkeinen wrote:
>> Boards with multiple display options for the same video bus have all the
>> possible linux display devices present at the same time. Only one of
>> those devices should be used at a time, as the video bus cannot be
>> shared.
>
> Yes, only one can be used at a time, but you can switch at runtime...
Yep. But the panel drivers need to know about this, and they cannot do
more or less anything in the driver probe function, which I think should
be the place to reserve resources and do initialization. With the
current model that would lead to multiple drivers trying to acquire the
same resources.
>> This model is hacky, and will be changed in the forthcoming DSS patches
>> to a model where only one display device can be present on a single
>> video bus.
>
> What do you mean by "present"?
> Is it active? or registered? or compiled in?
I mean that only one device can be registered. Well, nothing strictly
prevents having multiple devices registered, but if the devices have
matching drivers, the drivers would acquire the same resources. Possibly
the same gpios, but at least the same video bus.
>> This patch creates Kconfig options to select which of the display
>> devices is present on the board. While this model is also somewhat
>> hacky, and prevents us from using a single kernel image for all the
>> display options, it allows us to make the DSS driver changes for DT
>> adaptation. And with DT, the information about display devices can be
>> passed from the bootloader, solving the mess.
>
> Hmmm, the fact that we cannot use the same binary for multiple displays...
> This does not sound right and good at all...
> While we try to move to support multiple platforms in the same binary, we
> cannot support multiple displays? I agree that the multiplatform stuff is
> not really related, but you know what I mean...
Yes, I quite agree that this sucks =). There are a few reasons I chose
to try this approach:
- The whole multi-display feature is hacky
- DT support for DSS has been in development too long time. We really
need it, preferably yesterday. This change helps getting DT support ready.
- Common Display Framework won't (most likely) support this kind of
feature, as the feature itself is rather hacky, so this would anyway
disappear.
- DT support should solve this (except for runtime switching), and the
board files are on the way out (as far as I understand). So in that
sense this is temporary.
- Keeping this feature functional consumes considerable amount of
man-hours, which are in short supply.
I still feel quite bad about this, though. Any ideas how to manage this
better are appreciated.
> I bet there must be a much better solution for DT support.
Yes, I think I covered that in the last email. DT will solve the issue,
except for runtime switching, which is still open. I'm not sure how
these board specific drivers would be implemented.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-28 17:02 ` Tomi Valkeinen
@ 2013-03-31 9:17 ` Igor Grinberg
2013-04-02 8:07 ` Tomi Valkeinen
0 siblings, 1 reply; 50+ messages in thread
From: Igor Grinberg @ 2013-03-31 9:17 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Mike Rapoport
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/28/13 19:02, Tomi Valkeinen wrote:
> On 2013-03-28 18:09, Igor Grinberg wrote:
>> On 03/28/13 14:49, Tomi Valkeinen wrote:
>>> Boards with multiple display options for the same video bus have all the
>>> possible linux display devices present at the same time. Only one of
>>> those devices should be used at a time, as the video bus cannot be
>>> shared.
>>
>> Yes, only one can be used at a time, but you can switch at runtime...
>
> Yep. But the panel drivers need to know about this, and they cannot do
> more or less anything in the driver probe function, which I think should
> be the place to reserve resources and do initialization. With the
> current model that would lead to multiple drivers trying to acquire the
> same resources.
Yep, this is a problem, but it only means that probably
the platform device framework is not suitable for this.
What about having some kind of display manager which will have a private
list of registered devices and will instantiate only those that are marked
active?
This also might be useful with DT.
>
>>> This model is hacky, and will be changed in the forthcoming DSS patches
>>> to a model where only one display device can be present on a single
>>> video bus.
>>
>> What do you mean by "present"?
>> Is it active? or registered? or compiled in?
>
> I mean that only one device can be registered. Well, nothing strictly
> prevents having multiple devices registered, but if the devices have
> matching drivers, the drivers would acquire the same resources. Possibly
> the same gpios, but at least the same video bus.
Well, I think, we should follow/extend the already existing EDID concept...
Instantiate a display device only when one has been "plugged in".
By "plugged in" I mean enabled - made active.
>
>>> This patch creates Kconfig options to select which of the display
>>> devices is present on the board. While this model is also somewhat
>>> hacky, and prevents us from using a single kernel image for all the
>>> display options, it allows us to make the DSS driver changes for DT
>>> adaptation. And with DT, the information about display devices can be
>>> passed from the bootloader, solving the mess.
>>
>> Hmmm, the fact that we cannot use the same binary for multiple displays...
>> This does not sound right and good at all...
>> While we try to move to support multiple platforms in the same binary, we
>> cannot support multiple displays? I agree that the multiplatform stuff is
>> not really related, but you know what I mean...
>
> Yes, I quite agree that this sucks =). There are a few reasons I chose
> to try this approach:
>
> - The whole multi-display feature is hacky
>
> - DT support for DSS has been in development too long time. We really
> need it, preferably yesterday. This change helps getting DT support ready.
Yes, but I don't think this should involve removing the existing
functionality..
Let me exaggerate a bit: this is like removing ARM support from mainline,
so it will make less noise and headache to Linus...
>
> - Common Display Framework won't (most likely) support this kind of
> feature, as the feature itself is rather hacky, so this would anyway
> disappear.
Hmmm, I don't think it will disappear, but instead you will keep
receiving hacky patches to bring that support in...
So, IMO, it would be better designed to support this or at least
keep it in mind, so there will no necessity for hacky patches...
>
> - DT support should solve this (except for runtime switching), and the
> board files are on the way out (as far as I understand). So in that
> sense this is temporary.
But not the runtime switching...
The runtime switching should be done in the framework.
>
> - Keeping this feature functional consumes considerable amount of
> man-hours, which are in short supply.
This is where you should request some help from the interested sides...
And mailing lists are quite handy.
>
> I still feel quite bad about this, though. Any ideas how to manage this
> better are appreciated.
>
>> I bet there must be a much better solution for DT support.
>
> Yes, I think I covered that in the last email. DT will solve the issue,
> except for runtime switching, which is still open. I'm not sure how
> these board specific drivers would be implemented.
Well, at least the generic kernel display parameter will do more than
half of the job.
We can discuss the runtime switch stuff, but it is really a non-sense
to compile a kernel for specific display...
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRV/8gAAoJEBDE8YO64EfaGOQQAIEnXwrHiZFlsMkCo5n8uUok
qBBvEoFh5s1h2aaDNna3Q7tvKF42UlaGtZPqwl5bDUHimcEaLnNPy14MQJ/w/dHN
AvDaI2ZoqGCYDVjVa0KUCWqL6Chm7ZpAoU9NeY3T3+U8S7kIeizz0oBJKoZ4bfpk
g6Kq5vnbi36pCWFMqQe+7fEn5CHJNHTp+miPpq3Dsed2zkVgIg9re0nTxpQjlDHO
+kLwJjrHbCqZoBMzE0MacaibROiHhccQ9Xtf25iVemyHQ6CP6g+ibJduFF7S4pOk
kOwH1NY2QiFGDyA0Tj+kuYsbUYe3E1ds7FCu0/9g2KpiGRqSAqrFDghJzj1PojL+
SxL47jgMkDUehEnBC2Eq3DD5jq4YRd2Sn989FH5ov9GWcyFhzBl72LHHhI78YRpu
3QKGAnAcSVOyNcvkDNYhsJRqs9qUpnn9Z89jrx430ckK+SI4T4qiczn4aFEXFPxC
Zqp8Rmvn95X5D9kMBgMScy1cHzkWRZ32GCKSRkOqnaFim2knxrflnX1Riu11jFCL
k1AK+rKhqUB9FaME3Uyn07s+cTKCVX1TWmnP6Er9ObZkOKR2fR7ZwEmTbhA/m0pe
iefjKf6gxuZV/FX+OnTvivorw2CMfGyweolu2JHj9cTuEGvddeq/LhKz+cEzdMVL
Vpj9krR7L6Hq8dFqz8Dk
=sr0U
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-03-31 9:17 ` Igor Grinberg
@ 2013-04-02 8:07 ` Tomi Valkeinen
2013-04-02 11:20 ` Igor Grinberg
0 siblings, 1 reply; 50+ messages in thread
From: Tomi Valkeinen @ 2013-04-02 8:07 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Mike Rapoport
[-- Attachment #1: Type: text/plain, Size: 3826 bytes --]
On 2013-03-31 12:17, Igor Grinberg wrote:
>
>
> On 03/28/13 19:02, Tomi Valkeinen wrote:
>> On 2013-03-28 18:09, Igor Grinberg wrote:
>>> On 03/28/13 14:49, Tomi Valkeinen wrote:
>>>> Boards with multiple display options for the same video bus have all the
>>>> possible linux display devices present at the same time. Only one of
>>>> those devices should be used at a time, as the video bus cannot be
>>>> shared.
>>>
>>> Yes, only one can be used at a time, but you can switch at runtime...
>
>> Yep. But the panel drivers need to know about this, and they cannot do
>> more or less anything in the driver probe function, which I think should
>> be the place to reserve resources and do initialization. With the
>> current model that would lead to multiple drivers trying to acquire the
>> same resources.
>
> Yep, this is a problem, but it only means that probably
> the platform device framework is not suitable for this.
>
> What about having some kind of display manager which will have a private
> list of registered devices and will instantiate only those that are marked
> active?
> This also might be useful with DT.
We can't have a generic manager that handles instantiating the devices,
as we don't know what device they are. They could be platform devices,
i2c, anything. There could even be a single device that creates multiple
displays.
>>>> This model is hacky, and will be changed in the forthcoming DSS patches
>>>> to a model where only one display device can be present on a single
>>>> video bus.
>>>
>>> What do you mean by "present"?
>>> Is it active? or registered? or compiled in?
>
>> I mean that only one device can be registered. Well, nothing strictly
>> prevents having multiple devices registered, but if the devices have
>> matching drivers, the drivers would acquire the same resources. Possibly
>> the same gpios, but at least the same video bus.
>
> Well, I think, we should follow/extend the already existing EDID concept...
> Instantiate a display device only when one has been "plugged in".
> By "plugged in" I mean enabled - made active.
This brings the complication that we need a way to make the display
active even if the display device doesn't exist. So we need to know
about the display even if it's not there.
>>>> This patch creates Kconfig options to select which of the display
>>>> devices is present on the board. While this model is also somewhat
>>>> hacky, and prevents us from using a single kernel image for all the
>>>> display options, it allows us to make the DSS driver changes for DT
>>>> adaptation. And with DT, the information about display devices can be
>>>> passed from the bootloader, solving the mess.
>>>
>>> Hmmm, the fact that we cannot use the same binary for multiple displays...
>>> This does not sound right and good at all...
>>> While we try to move to support multiple platforms in the same binary, we
>>> cannot support multiple displays? I agree that the multiplatform stuff is
>>> not really related, but you know what I mean...
>
>> Yes, I quite agree that this sucks =). There are a few reasons I chose
>> to try this approach:
>
>> - The whole multi-display feature is hacky
>
>> - DT support for DSS has been in development too long time. We really
>> need it, preferably yesterday. This change helps getting DT support ready.
>
> Yes, but I don't think this should involve removing the existing
> functionality..
> Let me exaggerate a bit: this is like removing ARM support from mainline,
> so it will make less noise and headache to Linus...
That is exaggerating quite a bit ;). But yes, I agree that we should not
remove the features. I just couldn't find a manageable way to have them
while still moving forward to DT and CDF.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
2013-04-02 8:07 ` Tomi Valkeinen
@ 2013-04-02 11:20 ` Igor Grinberg
0 siblings, 0 replies; 50+ messages in thread
From: Igor Grinberg @ 2013-04-02 11:20 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Mike Rapoport
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/02/13 11:07, Tomi Valkeinen wrote:
> On 2013-03-31 12:17, Igor Grinberg wrote:
>>
>>
>> On 03/28/13 19:02, Tomi Valkeinen wrote:
>>> On 2013-03-28 18:09, Igor Grinberg wrote:
>>>> On 03/28/13 14:49, Tomi Valkeinen wrote:
>>>>> Boards with multiple display options for the same video bus have all the
>>>>> possible linux display devices present at the same time. Only one of
>>>>> those devices should be used at a time, as the video bus cannot be
>>>>> shared.
>>>>
>>>> Yes, only one can be used at a time, but you can switch at runtime...
>>
>>> Yep. But the panel drivers need to know about this, and they cannot do
>>> more or less anything in the driver probe function, which I think should
>>> be the place to reserve resources and do initialization. With the
>>> current model that would lead to multiple drivers trying to acquire the
>>> same resources.
>>
>> Yep, this is a problem, but it only means that probably
>> the platform device framework is not suitable for this.
>>
>> What about having some kind of display manager which will have a private
>> list of registered devices and will instantiate only those that are marked
>> active?
>> This also might be useful with DT.
>
> We can't have a generic manager that handles instantiating the devices,
> as we don't know what device they are. They could be platform devices,
> i2c, anything. There could even be a single device that creates multiple
> displays.
Unless, the registered device node is descriptive enough,
or the device node can "instantiate itself".
We use the "ops" structures all over the kernel.
What about the capebus? Can it help with abstracting such things?
>
>>>>> This model is hacky, and will be changed in the forthcoming DSS patches
>>>>> to a model where only one display device can be present on a single
>>>>> video bus.
>>>>
>>>> What do you mean by "present"?
>>>> Is it active? or registered? or compiled in?
>>
>>> I mean that only one device can be registered. Well, nothing strictly
>>> prevents having multiple devices registered, but if the devices have
>>> matching drivers, the drivers would acquire the same resources. Possibly
>>> the same gpios, but at least the same video bus.
>>
>> Well, I think, we should follow/extend the already existing EDID concept...
>> Instantiate a display device only when one has been "plugged in".
>> By "plugged in" I mean enabled - made active.
>
> This brings the complication that we need a way to make the display
> active even if the display device doesn't exist. So we need to know
> about the display even if it's not there.
Yes, well, I mean that the process of making the display active can
involve registering the display device, no?
And yes, it does bring the complication, but I don't really see a way we
can avoid such complications and yet support the modern hardware.
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRWr8VAAoJEBDE8YO64Efa5sgP/ArPjYtGakOnWkbFah5ClnPH
sOMDwnTEW76rLpXzPE63dTBIImiBhKpaKNKK3pxdPH7uhZ5qr1usi/s/W59MPrYA
7lsZnkdsJLk/piFKk1IdB9Q+ke7qftCEmVTrv9fXtYrojZ9NHH1yGqmjQIINyzUm
hGTbplKUldfMSh9z+XszUcGgBkkZQgMd435eJKOYw9Bny56u0ekOfPIo5pHTJioc
F4gQybWQ41hpBVWe8OkYH8tN9hOnujbdgQ+K4K5JYizJV0NYnGgxESvescieAINn
0INEYhiyD97Fcr6sFFjOSqkLTZoBaXFLDl0EPWqasImf5sCLapmtkqfpMRlUjoiW
MiVv6XACE5AmFicivjPowDn01HurH0Q8aXXhvhtSEu8oLePN3gH5PW9P6VIjAUbM
85OT+VkPfWIUupw2aeygy+ePoBpjj4NtZWzhpxzdDi/k5HkrZvSh3uGernCbAsYj
/JV4wZRQQVml7j65uYRLmnKx+tMbBnd/QU96OLdSOdGaNor+bY0x0zDcy4DAKuw3
/W0HPGMr6dctBOb26ofYn97jxjLAcULKTWffykxktNyB1ODzN2NdEUnUv6rtq4Bv
6EA7EaK1dehM2TV4eVNiCxxvv88Kk58uJqzuxvx2BHGtDkbygJGxkBZ41/MNWQOT
3UMYsUEKecOie5cT+JtG
=IrRQ
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH 09/28] ARM: OMAP: AM3517EVM: Kconfig option for the display options
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (7 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 08/28] ARM: OMAP: CM-T35: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 10/28] ARM: OMAP: Panda: use new TFP410 platform driver Tomi Valkeinen
` (20 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.
This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.
This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Kconfig | 13 +++++++++
arch/arm/mach-omap2/board-am3517evm.c | 49 ++++++++++++++++++---------------
2 files changed, 40 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 6e73cb4..57e1d37 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -298,6 +298,19 @@ config MACH_OMAP3517EVM
default y
select OMAP_PACKAGE_CBB
+choice
+ depends on MACH_OMAP3517EVM
+ default MACH_OMAP3517EVM_EXPANSION_LCD
+ prompt "OMAP3517/ AM3517 EVM video output"
+
+config MACH_OMAP3517EVM_EXPANSION_LCD
+ bool "OMAP3517/ AM3517 EVM with LCD"
+
+config MACH_OMAP3517EVM_EXPANSION_DVI
+ bool "OMAP3517/ AM3517 EVM with DVI"
+
+endchoice
+
config MACH_CRANEBOARD
bool "AM3517/05 CRANE board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index 25a0894..1d7d0d8 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -121,11 +121,15 @@ static int __init am3517_evm_i2c_init(void)
return 0;
}
-static int lcd_enabled;
-static int dvi_enabled;
+static struct omap_dss_device am3517_evm_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .driver_name = "venc",
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_LCD)
-#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
- defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
static struct gpio am3517_evm_dss_gpios[] __initdata = {
/* GPIO 182 = LCD Backlight Power */
{ LCD_PANEL_BKLIGHT_PWR, GPIOF_OUT_INIT_HIGH, "lcd_backlight_pwr" },
@@ -152,26 +156,16 @@ static void __init am3517_evm_display_init(void)
printk(KERN_INFO "Display initialized successfully\n");
}
-#else
-static void __init am3517_evm_display_init(void) {}
-#endif
static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
gpio_set_value(LCD_PANEL_PWR, 1);
- lcd_enabled = 1;
-
return 0;
}
static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
{
gpio_set_value(LCD_PANEL_PWR, 0);
- lcd_enabled = 0;
}
static struct panel_generic_dpi_data lcd_panel = {
@@ -188,13 +182,23 @@ static struct omap_dss_device am3517_evm_lcd_device = {
.phy.dpi.data_lines = 16,
};
-static struct omap_dss_device am3517_evm_tv_device = {
- .type = OMAP_DISPLAY_TYPE_VENC,
- .name = "tv",
- .driver_name = "venc",
- .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct omap_dss_device *am3517_evm_dss_devices[] = {
+ &am3517_evm_lcd_device,
+ &am3517_evm_tv_device,
+};
+
+static struct omap_dss_board_info am3517_evm_dss_data = {
+ .num_devices = ARRAY_SIZE(am3517_evm_dss_devices),
+ .devices = am3517_evm_dss_devices,
+ .default_display_name = "lcd",
};
+#elif defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_DVI)
+
+static void __init am3517_evm_display_init(void)
+{
+}
+
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio = -1,
.i2c_bus_num = -1,
@@ -209,17 +213,18 @@ static struct omap_dss_device am3517_evm_dvi_device = {
};
static struct omap_dss_device *am3517_evm_dss_devices[] = {
- &am3517_evm_lcd_device,
- &am3517_evm_tv_device,
&am3517_evm_dvi_device,
+ &am3517_evm_tv_device,
};
static struct omap_dss_board_info am3517_evm_dss_data = {
.num_devices = ARRAY_SIZE(am3517_evm_dss_devices),
.devices = am3517_evm_dss_devices,
- .default_device = &am3517_evm_lcd_device,
+ .default_display_name = "dvi",
};
+#endif
+
/*
* Board initialization
*/
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 10/28] ARM: OMAP: Panda: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (8 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 09/28] ARM: OMAP: AM3517EVM: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 11/28] ARM: OMAP: Panda & SDP: use new HDMI driver Tomi Valkeinen
` (19 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 135fdd8..fac4b3e 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -25,6 +25,7 @@
#include <linux/kernel.h>
#include <linux/gpio.h>
+#include <linux/platform_device.h>
#include <video/omapdss.h>
#include <video/omap-panel-tfp410.h>
@@ -42,19 +43,18 @@
/* Display DVI */
#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-/* Using generic display panel */
-static struct tfp410_platform_data omap4_dvi_panel = {
+static struct tfp410_platform_data omap4_tfp410_pdata = {
+ .name = "dvi",
+ .source = "dpi.0",
.i2c_bus_num = 3,
+ .data_lines = 24,
.power_down_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
};
-static struct omap_dss_device omap4_panda_dvi_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = "dvi",
- .driver_name = "tfp410",
- .data = &omap4_dvi_panel,
- .phy.dpi.data_lines = 24,
- .channel = OMAP_DSS_CHANNEL_LCD2,
+static struct platform_device omap4_panda_tfp410_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &omap4_tfp410_pdata,
};
static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
@@ -72,19 +72,19 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
};
static struct omap_dss_device *omap4_panda_dss_devices[] = {
- &omap4_panda_dvi_device,
&omap4_panda_hdmi_device,
};
static struct omap_dss_board_info omap4_panda_dss_data = {
.num_devices = ARRAY_SIZE(omap4_panda_dss_devices),
.devices = omap4_panda_dss_devices,
- .default_device = &omap4_panda_dvi_device,
+ .default_display_name = "dvi",
};
void __init omap4_panda_display_init(void)
{
omap_display_init(&omap4_panda_dss_data);
+ platform_device_register(&omap4_panda_tfp410_device);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -103,6 +103,7 @@ void __init omap4_panda_display_init(void)
void __init omap4_panda_display_init_of(void)
{
omap_display_init(&omap4_panda_dss_data);
+ platform_device_register(&omap4_panda_tfp410_device);
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 11/28] ARM: OMAP: Panda & SDP: use new HDMI driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (9 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 10/28] ARM: OMAP: Panda: use new TFP410 platform driver Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 12/28] ARM: OMAP: 4430SDP: use new Taal driver Tomi Valkeinen
` (18 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Change Pandaboard and 4430SDP to use the new HDMI platform driver
instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 31 ++++++++++++-------------------
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index fac4b3e..1e2c5c0 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -63,21 +63,13 @@ static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
.hpd_gpio = HDMI_GPIO_HPD,
};
-static struct omap_dss_device omap4_panda_hdmi_device = {
- .name = "hdmi",
- .driver_name = "hdmi_panel",
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = &omap4_panda_hdmi_data,
-};
-
-static struct omap_dss_device *omap4_panda_dss_devices[] = {
- &omap4_panda_hdmi_device,
+static struct platform_device omap4_panda_hdmi_device = {
+ .name = "hdmi_panel",
+ .id = 0,
+ .dev.platform_data = &omap4_panda_hdmi_data,
};
static struct omap_dss_board_info omap4_panda_dss_data = {
- .num_devices = ARRAY_SIZE(omap4_panda_dss_devices),
- .devices = omap4_panda_dss_devices,
.default_display_name = "dvi",
};
@@ -85,6 +77,7 @@ void __init omap4_panda_display_init(void)
{
omap_display_init(&omap4_panda_dss_data);
platform_device_register(&omap4_panda_tfp410_device);
+ platform_device_register(&omap4_panda_hdmi_device);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -104,6 +97,7 @@ void __init omap4_panda_display_init_of(void)
{
omap_display_init(&omap4_panda_dss_data);
platform_device_register(&omap4_panda_tfp410_device);
+ platform_device_register(&omap4_panda_hdmi_device);
}
@@ -115,12 +109,10 @@ static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
.hpd_gpio = HDMI_GPIO_HPD,
};
-static struct omap_dss_device sdp4430_hdmi_device = {
- .name = "hdmi",
- .driver_name = "hdmi_panel",
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = &sdp4430_hdmi_data,
+static struct platform_device sdp4430_hdmi_device = {
+ .name = "hdmi_panel",
+ .id = 0,
+ .dev.platform_data = &sdp4430_hdmi_data,
};
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
@@ -235,7 +227,6 @@ static struct omap_dss_device *sdp4430_dss_devices[] = {
#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
&sdp4430_lcd2_device,
#endif
- &sdp4430_hdmi_device,
#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO
&sdp4430_picodlp_device,
#endif
@@ -259,6 +250,7 @@ void __init omap_4430sdp_display_init(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
+ platform_device_register(&sdp4430_hdmi_device);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
* later have external pull up on the HDMI I2C lines
@@ -285,4 +277,5 @@ void __init omap_4430sdp_display_init_of(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
+ platform_device_register(&sdp4430_hdmi_device);
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 12/28] ARM: OMAP: 4430SDP: use new Taal driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (10 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 11/28] ARM: OMAP: Panda & SDP: use new HDMI driver Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 13/28] ARM: OMAP: Beagle: use new TFP410 platform driver Tomi Valkeinen
` (17 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Change 4430SDP to use the new Taal platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 47 +++++++++++++++++---------------------
1 file changed, 21 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 1e2c5c0..0c0fc79 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -118,7 +118,8 @@ static struct platform_device sdp4430_hdmi_device = {
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
static struct nokia_dsi_panel_data dsi1_panel = {
- .name = "taal",
+ .name = "lcd",
+ .source = "dsi.0",
.reset_gpio = 102,
.use_ext_te = false,
.ext_te_gpio = 101,
@@ -129,15 +130,10 @@ static struct nokia_dsi_panel_data dsi1_panel = {
},
};
-static struct omap_dss_device sdp4430_lcd_device = {
- .name = "lcd",
- .driver_name = "taal",
- .type = OMAP_DISPLAY_TYPE_DSI,
- .data = &dsi1_panel,
- .phy.dsi = {
- .module = 0,
- },
- .channel = OMAP_DSS_CHANNEL_LCD,
+static struct platform_device sdp4430_lcd1_device = {
+ .name = "taal",
+ .id = 0,
+ .dev.platform_data = &dsi1_panel,
};
#if defined(CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2)
@@ -145,7 +141,8 @@ static struct omap_dss_device sdp4430_lcd_device = {
static void sdp4430_picodlp_init(void) { }
static struct nokia_dsi_panel_data dsi2_panel = {
- .name = "taal",
+ .name = "lcd2",
+ .source = "dsi.1",
.reset_gpio = 104,
.use_ext_te = false,
.ext_te_gpio = 103,
@@ -156,16 +153,10 @@ static struct nokia_dsi_panel_data dsi2_panel = {
},
};
-static struct omap_dss_device sdp4430_lcd2_device = {
- .name = "lcd2",
- .driver_name = "taal",
- .type = OMAP_DISPLAY_TYPE_DSI,
- .data = &dsi2_panel,
- .phy.dsi = {
-
- .module = 1,
- },
- .channel = OMAP_DSS_CHANNEL_LCD2,
+static struct platform_device sdp4430_lcd2_device = {
+ .name = "taal",
+ .id = 1,
+ .dev.platform_data = &dsi2_panel,
};
#elif defined(CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO)
@@ -223,10 +214,6 @@ static struct omap_dss_device sdp4430_picodlp_device = {
#endif
static struct omap_dss_device *sdp4430_dss_devices[] = {
- &sdp4430_lcd_device,
-#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
- &sdp4430_lcd2_device,
-#endif
#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO
&sdp4430_picodlp_device,
#endif
@@ -235,7 +222,7 @@ static struct omap_dss_device *sdp4430_dss_devices[] = {
static struct omap_dss_board_info sdp4430_dss_data = {
.num_devices = ARRAY_SIZE(sdp4430_dss_devices),
.devices = sdp4430_dss_devices,
- .default_device = &sdp4430_lcd_device,
+ .default_display_name = "lcd",
};
void __init omap_4430sdp_display_init(void)
@@ -251,6 +238,10 @@ void __init omap_4430sdp_display_init(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
platform_device_register(&sdp4430_hdmi_device);
+ platform_device_register(&sdp4430_lcd1_device);
+#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
+ platform_device_register(&sdp4430_lcd2_device);
+#endif
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
* later have external pull up on the HDMI I2C lines
@@ -278,4 +269,8 @@ void __init omap_4430sdp_display_init_of(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
platform_device_register(&sdp4430_hdmi_device);
+ platform_device_register(&sdp4430_lcd1_device);
+#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
+ platform_device_register(&sdp4430_lcd2_device);
+#endif
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 13/28] ARM: OMAP: Beagle: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (11 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 12/28] ARM: OMAP: 4430SDP: use new Taal driver Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:52 ` Peter Meerwald
2013-03-28 12:49 ` [PATCH 14/28] ARM: OMAP: Stalker: " Tomi Valkeinen
` (16 subsequent siblings)
29 siblings, 1 reply; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index c3558f9..1b65e92 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -224,17 +224,18 @@ static struct mtd_partition omap3beagle_nand_partitions[] = {
/* DSS */
-static struct tfp410_platform_data dvi_panel = {
- .i2c_bus_num = 3,
- .power_down_gpio = -1,
+static struct tfp410_platform_data omap4_tfp410_pdata = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .i2c_bus_num = 3,
+ .data_lines = 24,
+ .power_down_gpio = -1,
};
-static struct omap_dss_device beagle_dvi_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = "dvi",
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
+static struct platform_device omap4_panda_tfp410_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &omap4_tfp410_pdata,
};
static struct omap_dss_device beagle_tv_device = {
@@ -245,14 +246,13 @@ static struct omap_dss_device beagle_tv_device = {
};
static struct omap_dss_device *beagle_dss_devices[] = {
- &beagle_dvi_device,
&beagle_tv_device,
};
static struct omap_dss_board_info beagle_dss_data = {
.num_devices = ARRAY_SIZE(beagle_dss_devices),
.devices = beagle_dss_devices,
- .default_device = &beagle_dvi_device,
+ .default_display_name = "dvi",
};
#include "sdram-micron-mt46h32m32lf-6.h"
@@ -316,7 +316,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
if (gpio_request_one(gpio + 1, GPIOF_IN, "EHCI_nOC"))
pr_err("%s: unable to configure EHCI_nOC\n", __func__);
}
- dvi_panel.power_down_gpio = beagle_config.dvi_pd_gpio;
+ omap4_tfp410_pdata.power_down_gpio = beagle_config.dvi_pd_gpio;
gpio_request_one(gpio + TWL4030_GPIO_MAX, beagle_config.usb_pwr_level,
"nEN_USB_PWR");
@@ -450,6 +450,7 @@ static struct platform_device *omap3_beagle_devices[] __initdata = {
&keys_gpio,
&madc_hwmon,
&leds_pwm,
+ &omap4_panda_tfp410_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 14/28] ARM: OMAP: Stalker: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (12 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 13/28] ARM: OMAP: Beagle: use new TFP410 platform driver Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 15/28] ARM: OMAP: OMAP3EVM: " Tomi Valkeinen
` (15 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-omap3stalker.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index d427240..3d10d7c 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -107,27 +107,27 @@ static struct omap_dss_device omap3_stalker_tv_device = {
};
static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
.power_down_gpio = DSS_ENABLE_GPIO,
.i2c_bus_num = -1,
};
-static struct omap_dss_device omap3_stalker_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
+static struct platform_device omap3_stalker_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
};
static struct omap_dss_device *omap3_stalker_dss_devices[] = {
&omap3_stalker_tv_device,
- &omap3_stalker_dvi_device,
};
static struct omap_dss_board_info omap3_stalker_dss_data = {
.num_devices = ARRAY_SIZE(omap3_stalker_dss_devices),
.devices = omap3_stalker_dss_devices,
- .default_device = &omap3_stalker_dvi_device,
+ .default_display_name = "dvi",
};
static struct regulator_consumer_supply omap3stalker_vmmc1_supply[] = {
@@ -349,6 +349,7 @@ static int __init omap3_stalker_i2c_init(void)
static struct platform_device *omap3_stalker_devices[] __initdata = {
&keys_gpio,
+ &omap3_stalker_dvi_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 15/28] ARM: OMAP: OMAP3EVM: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (13 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 14/28] ARM: OMAP: Stalker: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 16/28] ARM: OMAP: IGEP0020: " Tomi Valkeinen
` (14 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-omap3evm.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 2050679..de92965 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -238,21 +238,21 @@ static void __init omap3_evm_display_init(void)
}
static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
.power_down_gpio = OMAP3EVM_DVI_PANEL_EN_GPIO,
.i2c_bus_num = -1,
};
-static struct omap_dss_device omap3_evm_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
+static struct platform_device omap3_evm_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
};
static struct omap_dss_device *omap3_evm_dss_devices[] = {
&omap3_evm_tv_device,
- &omap3_evm_dvi_device,
};
static struct omap_dss_board_info omap3_evm_dss_data = {
@@ -705,6 +705,9 @@ static void __init omap3_evm_init(void)
omap3_evm_i2c_init();
+#if defined(CONFIG_MACH_OMAP3EVM_EXPANSION_DVI)
+ platform_device_register(&omap3_evm_dvi_device);
+#endif
omap_display_init(&omap3_evm_dss_data);
omap_serial_init();
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 16/28] ARM: OMAP: IGEP0020: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (14 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 15/28] ARM: OMAP: OMAP3EVM: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 17/28] ARM: OMAP: Devkit8000: " Tomi Valkeinen
` (13 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-igep0020.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index bf92678..28d0b3e 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -430,30 +430,26 @@ static struct twl4030_gpio_platform_data igep_twl4030_gpio_pdata = {
};
static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
.i2c_bus_num = 3,
.power_down_gpio = IGEP2_GPIO_DVI_PUP,
};
-static struct omap_dss_device igep2_dvi_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = "dvi",
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device *igep2_dss_devices[] = {
- &igep2_dvi_device
+static struct platform_device igep2_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
};
static struct omap_dss_board_info igep2_dss_data = {
- .num_devices = ARRAY_SIZE(igep2_dss_devices),
- .devices = igep2_dss_devices,
- .default_device = &igep2_dvi_device,
+ .default_display_name = "dvi",
};
static struct platform_device *igep_devices[] __initdata = {
&igep_vwlan_device,
+ &igep2_dvi_device,
};
static int igep2_keymap[] = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 17/28] ARM: OMAP: Devkit8000: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (15 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 16/28] ARM: OMAP: IGEP0020: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 18/28] ARM: OMAP: CM-T35: " Tomi Valkeinen
` (12 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-devkit8000.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index e90808c..d05f069 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -163,20 +163,20 @@ static struct omap_dss_board_info devkit8000_dss_data = {
#elif defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
.power_down_gpio = -1,
.i2c_bus_num = 1,
};
-static struct omap_dss_device devkit8000_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
+static struct platform_device devkit8000_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
};
static struct omap_dss_device *devkit8000_dss_devices[] = {
- &devkit8000_dvi_device,
&devkit8000_tv_device,
};
@@ -452,6 +452,9 @@ static struct platform_device *devkit8000_devices[] __initdata = {
&leds_gpio,
&keys_gpio,
&omap_dm9000_dev,
+#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
+ &devkit8000_dvi_device,
+#endif
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 18/28] ARM: OMAP: CM-T35: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (16 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 17/28] ARM: OMAP: Devkit8000: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 19/28] ARM: OMAP: AM3517EVM: " Tomi Valkeinen
` (11 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap
Cc: Archit Taneja, Tomi Valkeinen, Mike Rapoport, Igor Grinberg
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mike Rapoport <mike@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
---
arch/arm/mach-omap2/board-cm-t35.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 1b34c96..4f23be0 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -294,20 +294,20 @@ static void __init cm_t35_init_display(void)
#define CM_T35_DVI_EN_GPIO 54
static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
.power_down_gpio = CM_T35_DVI_EN_GPIO,
.i2c_bus_num = -1,
};
-static struct omap_dss_device cm_t35_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
+static struct platform_device cm_t35_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
};
static struct omap_dss_device *cm_t35_dss_devices[] = {
- &cm_t35_dvi_device,
&cm_t35_tv_device,
};
@@ -321,6 +321,8 @@ static void __init cm_t35_init_display(void)
{
int err;
+ platform_device_register(&cm_t35_dvi_device);
+
err = omap_display_init(&cm_t35_dss_data);
if (err)
pr_err("CM-T35: failed to register DSS device\n");
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 19/28] ARM: OMAP: AM3517EVM: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (17 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 18/28] ARM: OMAP: CM-T35: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 20/28] ARM: OMAP: 3430SDP: " Tomi Valkeinen
` (10 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-am3517evm.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index 1d7d0d8..c545981 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -200,20 +200,20 @@ static void __init am3517_evm_display_init(void)
}
static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
.power_down_gpio = -1,
.i2c_bus_num = -1,
};
-static struct omap_dss_device am3517_evm_dvi_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = "dvi",
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
+static struct platform_device am3517_evm_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
};
static struct omap_dss_device *am3517_evm_dss_devices[] = {
- &am3517_evm_dvi_device,
&am3517_evm_tv_device,
};
@@ -359,6 +359,9 @@ static void __init am3517_evm_init(void)
am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
/* DSS */
am3517_evm_display_init();
+#if defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_DVI)
+ platform_device_register(&am3517_evm_dvi_device);
+#endif
/* RTC - S35390A */
am3517_evm_rtc_init();
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 20/28] ARM: OMAP: 3430SDP: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (18 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 19/28] ARM: OMAP: AM3517EVM: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 21/28] ARM: OMAP: Overo: " Tomi Valkeinen
` (9 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-3430sdp.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 4acd4aa..2f9d4e0 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -119,27 +119,27 @@ static void __init sdp3430_display_init(void)
}
static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
.power_down_gpio = -1,
.i2c_bus_num = -1,
};
-static struct omap_dss_device sdp3430_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
+static struct platform_device sdp3430_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
};
static struct omap_dss_device *sdp3430_dss_devices[] = {
- &sdp3430_dvi_device,
&sdp3430_tv_device,
};
static struct omap_dss_board_info sdp3430_dss_data = {
.num_devices = ARRAY_SIZE(sdp3430_dss_devices),
.devices = sdp3430_dss_devices,
- .default_device = &sdp3430_dvi_device,
+ .default_display_name = "dvi",
};
#elif defined(CONFIG_MACH_OMAP_3430SDP_EXPANSION_LCD)
@@ -612,6 +612,9 @@ static void __init omap_3430sdp_init(void)
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
+#if defined(CONFIG_MACH_OMAP_3430SDP_EXPANSION_DVI)
+ platform_device_register(&sdp3430_dvi_device);
+#endif
enable_board_wakeup_source();
usbhs_init(&usbhs_bdata);
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 21/28] ARM: OMAP: Overo: use new TFP410 platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (19 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 20/28] ARM: OMAP: 3430SDP: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 22/28] ARM: OMAP: Overo: use new generic-dpi-panel " Tomi Valkeinen
` (8 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-overo.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 3253682..9cb29fc 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -148,30 +148,26 @@ static inline void __init overo_init_smsc911x(void) { return; }
#if defined(CONFIG_MACH_OVERO_EXPANSION_SUMMIT)
static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
.i2c_bus_num = 3,
.power_down_gpio = -1,
};
-static struct omap_dss_device overo_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device *overo_dss_devices[] = {
- &overo_dvi_device,
+static struct platform_device overo_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
};
static struct omap_dss_board_info overo_dss_data = {
- .num_devices = ARRAY_SIZE(overo_dss_devices),
- .devices = overo_dss_devices,
.default_display_name = "dvi",
};
static void __init overo_display_init(void)
{
+ platform_device_register(&overo_dvi_device);
}
#elif defined(CONFIG_MACH_OVERO_EXPANSION_PALO35)
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 22/28] ARM: OMAP: Overo: use new generic-dpi-panel platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (20 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 21/28] ARM: OMAP: Overo: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 23/28] ARM: OMAP: LDP: " Tomi Valkeinen
` (7 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-overo.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 9cb29fc..03624c5 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -241,27 +241,22 @@ static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
gpio_set_value(OVERO_GPIO_LCD_BL, 0);
}
-static struct panel_generic_dpi_data lcd43_panel = {
+static struct panel_generic_dpi_data overo_lcd43_data = {
+ .display_name = "lcd43",
+ .source = "dpi.0",
.name = "samsung_lte430wq_f0c",
.platform_enable = overo_panel_enable_lcd,
.platform_disable = overo_panel_disable_lcd,
+ .data_lines = 24,
};
-static struct omap_dss_device overo_lcd43_device = {
- .name = "lcd43",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "generic_dpi_panel",
- .data = &lcd43_panel,
- .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device *overo_dss_devices[] = {
- &overo_lcd43_device,
+static struct platform_device overo_lcd43_device = {
+ .name = "generic_dpi_panel",
+ .id = 0,
+ .dev.platform_data = &overo_lcd43_data,
};
static struct omap_dss_board_info overo_dss_data = {
- .num_devices = ARRAY_SIZE(overo_dss_devices),
- .devices = overo_dss_devices,
.default_display_name = "lcd43",
};
@@ -279,6 +274,8 @@ static void __init overo_display_init(void)
gpio_export(OVERO_GPIO_LCD_EN, 0);
gpio_export(OVERO_GPIO_LCD_BL, 0);
+
+ platform_device_register(&overo_lcd43_device);
}
#endif
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 23/28] ARM: OMAP: LDP: use new generic-dpi-panel platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (21 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 22/28] ARM: OMAP: Overo: use new generic-dpi-panel " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 24/28] ARM: OMAP: H4: " Tomi Valkeinen
` (6 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-ldp.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index b12fe96..78e0470 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -206,27 +206,22 @@ static void ldp_panel_disable_lcd(struct omap_dss_device *dssdev)
}
static struct panel_generic_dpi_data ldp_panel_data = {
+ .display_name = "lcd",
+ .source = "dpi.0",
.name = "nec_nl2432dr22-11b",
+ .data_lines = 18,
.platform_enable = ldp_panel_enable_lcd,
.platform_disable = ldp_panel_disable_lcd,
};
-static struct omap_dss_device ldp_lcd_device = {
- .name = "lcd",
- .driver_name = "generic_dpi_panel",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .phy.dpi.data_lines = 18,
- .data = &ldp_panel_data,
-};
-
-static struct omap_dss_device *ldp_dss_devices[] = {
- &ldp_lcd_device,
+static struct platform_device ldp_lcd_device = {
+ .name = "generic_dpi_panel",
+ .id = 0,
+ .dev.platform_data = &ldp_panel_data,
};
static struct omap_dss_board_info ldp_dss_data = {
- .num_devices = ARRAY_SIZE(ldp_dss_devices),
- .devices = ldp_dss_devices,
- .default_device = &ldp_lcd_device,
+ .default_display_name = "lcd",
};
static void __init ldp_display_init(void)
@@ -364,6 +359,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
static struct platform_device *ldp_devices[] __initdata = {
&ldp_gpio_keys_device,
+ &ldp_lcd_device,
};
#ifdef CONFIG_OMAP_MUX
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 24/28] ARM: OMAP: H4: use new generic-dpi-panel platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (22 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 23/28] ARM: OMAP: LDP: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 25/28] ARM: OMAP: Devkit8000: " Tomi Valkeinen
` (5 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-h4.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 812c829..bbcbc31 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -194,30 +194,26 @@ static struct platform_device h4_flash_device = {
.resource = &h4_flash_resource,
};
-static struct platform_device *h4_devices[] __initdata = {
- &h4_flash_device,
-};
-
static struct panel_generic_dpi_data h4_panel_data = {
+ .display_name = "lcd",
+ .source = "dpi.0",
.name = "h4",
+ .data_lines = 16,
};
-static struct omap_dss_device h4_lcd_device = {
- .name = "lcd",
- .driver_name = "generic_dpi_panel",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .phy.dpi.data_lines = 16,
- .data = &h4_panel_data,
+static struct platform_device h4_lcd_device = {
+ .name = "generic_dpi_panel",
+ .id = 0,
+ .dev.platform_data = &h4_panel_data,
};
-static struct omap_dss_device *h4_dss_devices[] = {
+static struct platform_device *h4_devices[] __initdata = {
+ &h4_flash_device,
&h4_lcd_device,
};
static struct omap_dss_board_info h4_dss_data = {
- .num_devices = ARRAY_SIZE(h4_dss_devices),
- .devices = h4_dss_devices,
- .default_device = &h4_lcd_device,
+ .default_display_name = "lcd",
};
/* 2420 Sysboot setup (2430 is different) */
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 25/28] ARM: OMAP: Devkit8000: use new generic-dpi-panel platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (23 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 24/28] ARM: OMAP: H4: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 26/28] ARM: OMAP: CM-T35: " Tomi Valkeinen
` (4 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-devkit8000.c | 33 ++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index d05f069..1e0343f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -122,35 +122,37 @@ static struct omap_dss_device devkit8000_tv_device = {
#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
+static int lcd_reset_gpio;
+
static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- if (gpio_is_valid(dssdev->reset_gpio))
- gpio_set_value_cansleep(dssdev->reset_gpio, 1);
+ if (gpio_is_valid(lcd_reset_gpio))
+ gpio_set_value_cansleep(lcd_reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
- if (gpio_is_valid(dssdev->reset_gpio))
- gpio_set_value_cansleep(dssdev->reset_gpio, 0);
+ if (gpio_is_valid(lcd_reset_gpio))
+ gpio_set_value_cansleep(lcd_reset_gpio, 0);
}
static struct panel_generic_dpi_data lcd_panel = {
+ .display_name = "lcd",
+ .source = "dpi.0",
.name = "innolux_at070tn83",
+ .data_lines = 24,
.platform_enable = devkit8000_panel_enable_lcd,
.platform_disable = devkit8000_panel_disable_lcd,
};
-static struct omap_dss_device devkit8000_lcd_device = {
- .name = "lcd",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "generic_dpi_panel",
- .data = &lcd_panel,
- .phy.dpi.data_lines = 24,
+static struct platform_device devkit8000_lcd_device = {
+ .name = "generic_dpi_panel",
+ .id = 0,
+ .dev.platform_data = &lcd_panel,
};
static struct omap_dss_device *devkit8000_dss_devices[] = {
- &devkit8000_lcd_device,
&devkit8000_tv_device,
};
@@ -238,11 +240,11 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
/* TWL4030_GPIO_MAX + 0 is "LCD_PWREN" (out, active high) */
- devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
- ret = gpio_request_one(devkit8000_lcd_device.reset_gpio,
+ lcd_reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
+ ret = gpio_request_one(lcd_reset_gpio,
GPIOF_OUT_INIT_LOW, "LCD_PWREN");
if (ret < 0) {
- devkit8000_lcd_device.reset_gpio = -EINVAL;
+ lcd_reset_gpio = -EINVAL;
printk(KERN_ERR "Failed to request GPIO for LCD_PWRN\n");
}
#elif defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
@@ -455,6 +457,9 @@ static struct platform_device *devkit8000_devices[] __initdata = {
#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
&devkit8000_dvi_device,
#endif
+#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
+ &devkit8000_lcd_device,
+#endif
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 26/28] ARM: OMAP: CM-T35: use new generic-dpi-panel platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (24 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 25/28] ARM: OMAP: Devkit8000: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 27/28] ARM: OMAP: AM3517EVM: " Tomi Valkeinen
` (3 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap
Cc: Archit Taneja, Tomi Valkeinen, Mike Rapoport, Igor Grinberg
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mike Rapoport <mike@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
---
arch/arm/mach-omap2/board-cm-t35.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 4f23be0..6b8aa87 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -214,21 +214,21 @@ static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
}
static struct panel_generic_dpi_data lcd_panel = {
+ .display_name = "lcd",
+ .source = "dpi.0",
.name = "toppoly_tdo35s",
+ .data_lines = 18,
.platform_enable = cm_t35_panel_enable_lcd,
.platform_disable = cm_t35_panel_disable_lcd,
};
-static struct omap_dss_device cm_t35_lcd_device = {
- .name = "lcd",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name = "generic_dpi_panel",
- .data = &lcd_panel,
- .phy.dpi.data_lines = 18,
+static struct platform_device cm_t35_lcd_device = {
+ .name = "generic_dpi_panel",
+ .id = 0,
+ .dev.platform_data = &lcd_panel,
};
static struct omap_dss_device *cm_t35_dss_devices[] = {
- &cm_t35_lcd_device,
&cm_t35_tv_device,
};
@@ -282,6 +282,8 @@ static void __init cm_t35_init_display(void)
msleep(50);
gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
+ platform_device_register(&cm_t35_lcd_device);
+
err = omap_display_init(&cm_t35_dss_data);
if (err) {
pr_err("CM-T35: failed to register DSS device\n");
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 27/28] ARM: OMAP: AM3517EVM: use new generic-dpi-panel platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (25 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 26/28] ARM: OMAP: CM-T35: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 12:49 ` [PATCH 28/28] ARM: OMAP: 2430SDP: " Tomi Valkeinen
` (2 subsequent siblings)
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-am3517evm.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index c545981..a7e728e 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -169,21 +169,21 @@ static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
}
static struct panel_generic_dpi_data lcd_panel = {
+ .display_name = "lcd",
+ .source = "dpi.0",
.name = "sharp_lq",
+ .data_lines = 16,
.platform_enable = am3517_evm_panel_enable_lcd,
.platform_disable = am3517_evm_panel_disable_lcd,
};
-static struct omap_dss_device am3517_evm_lcd_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = "lcd",
- .driver_name = "generic_dpi_panel",
- .data = &lcd_panel,
- .phy.dpi.data_lines = 16,
+static struct platform_device am3517_evm_lcd_device = {
+ .name = "generic_dpi_panel",
+ .id = 0,
+ .dev.platform_data = &lcd_panel,
};
static struct omap_dss_device *am3517_evm_dss_devices[] = {
- &am3517_evm_lcd_device,
&am3517_evm_tv_device,
};
@@ -362,6 +362,9 @@ static void __init am3517_evm_init(void)
#if defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_DVI)
platform_device_register(&am3517_evm_dvi_device);
#endif
+#if defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_LCD)
+ platform_device_register(&am3517_evm_lcd_device);
+#endif
/* RTC - S35390A */
am3517_evm_rtc_init();
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH 28/28] ARM: OMAP: 2430SDP: use new generic-dpi-panel platform driver
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (26 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 27/28] ARM: OMAP: AM3517EVM: " Tomi Valkeinen
@ 2013-03-28 12:49 ` Tomi Valkeinen
2013-03-28 15:31 ` [PATCH 00/28] OMAP: DSS related board file changes Igor Grinberg
2013-04-03 9:36 ` Tomi Valkeinen
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 12:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-2430sdp.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index a3e0aaa..4f94dec 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -100,10 +100,6 @@ static struct platform_device sdp2430_flash_device = {
.resource = &sdp2430_flash_resource,
};
-static struct platform_device *sdp2430_devices[] __initdata = {
- &sdp2430_flash_device,
-};
-
/* LCD */
#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO 91
#define SDP2430_LCD_PANEL_ENABLE_GPIO 154
@@ -123,27 +119,27 @@ static void sdp2430_panel_disable_lcd(struct omap_dss_device *dssdev)
}
static struct panel_generic_dpi_data sdp2430_panel_data = {
+ .display_name = "lcd",
+ .source = "dpi.0",
.name = "nec_nl2432dr22-11b",
+ .data_lines = 16,
.platform_enable = sdp2430_panel_enable_lcd,
.platform_disable = sdp2430_panel_disable_lcd,
};
-static struct omap_dss_device sdp2430_lcd_device = {
- .name = "lcd",
- .driver_name = "generic_dpi_panel",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .phy.dpi.data_lines = 16,
- .data = &sdp2430_panel_data,
+static struct platform_device sdp2430_lcd_device = {
+ .name = "generic_dpi_panel",
+ .id = 0,
+ .dev.platform_data = &sdp2430_panel_data,
};
-static struct omap_dss_device *sdp2430_dss_devices[] = {
+static struct platform_device *sdp2430_devices[] __initdata = {
+ &sdp2430_flash_device,
&sdp2430_lcd_device,
};
static struct omap_dss_board_info sdp2430_dss_data = {
- .num_devices = ARRAY_SIZE(sdp2430_dss_devices),
- .devices = sdp2430_dss_devices,
- .default_device = &sdp2430_lcd_device,
+ .default_display_name = "lcd",
};
static void __init sdp2430_display_init(void)
--
1.7.10.4
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (27 preceding siblings ...)
2013-03-28 12:49 ` [PATCH 28/28] ARM: OMAP: 2430SDP: " Tomi Valkeinen
@ 2013-03-28 15:31 ` Igor Grinberg
2013-03-28 16:48 ` Tomi Valkeinen
2013-04-03 9:36 ` Tomi Valkeinen
29 siblings, 1 reply; 50+ messages in thread
From: Igor Grinberg @ 2013-03-28 15:31 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Dmitry Lifshitz
On 03/28/13 14:48, Tomi Valkeinen wrote:
> So here are the DSS related board file changes for 3.10.
>
> First there are a bunch of patches adding the Kconfig options so that only one
> display device is created for a single video bus. Only Overo had more than two
> displays on the same bus, but unfortunately there were multiple boards with a
> setup that puts an LCD and DVI output on the same video bus.
Hmmm, so basically, if one could switch the display at runtime...
This cannot be done anymore...
This sounds like feature removal, no?
I know several of our clients who used this feature
(at least for evaluation purposes).
Is there any strong pros you obtain while removing this feature?
>
> So the ifdeffery is not very nice. But, as discussed, this is the best way
> forward, and should be seen as a temporary solution until we get full DT
> support.
I've missed this discussion, can you please point to it?
And what will change with full DT support?
Will we be able to define several displays through DT and
select and active one during runtime?
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-03-28 15:31 ` [PATCH 00/28] OMAP: DSS related board file changes Igor Grinberg
@ 2013-03-28 16:48 ` Tomi Valkeinen
2013-03-28 16:57 ` Tony Lindgren
2013-03-31 8:39 ` Igor Grinberg
0 siblings, 2 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-03-28 16:48 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Dmitry Lifshitz
[-- Attachment #1: Type: text/plain, Size: 3447 bytes --]
On 2013-03-28 17:31, Igor Grinberg wrote:
> On 03/28/13 14:48, Tomi Valkeinen wrote:
>> So here are the DSS related board file changes for 3.10.
>>
>> First there are a bunch of patches adding the Kconfig options so that only one
>> display device is created for a single video bus. Only Overo had more than two
>> displays on the same bus, but unfortunately there were multiple boards with a
>> setup that puts an LCD and DVI output on the same video bus.
>
> Hmmm, so basically, if one could switch the display at runtime...
> This cannot be done anymore...
> This sounds like feature removal, no?
> I know several of our clients who used this feature
> (at least for evaluation purposes).
At some point in time it was possible to have multiple displays for the
same bus, and switch them at runtime.
Sometime later it was changed so that the board file adds all the
displays, but only one (per bus) is actually added to the list of
panels, but you could still set the default display in the kernel args,
and thus you could select which display gets added.
The reason why the multiple-displays-per-bus is problematic is that the
video bus cannot be shared, and if we have multiple devices on the same
bus, the drivers need extra trickery, delaying initializations, etc, to
handle this. And it still doesn't work right, as it's easy to get two
displays enabled at the same time, configuring the same video bus,
creating a mess.
Quite often the case is that the other displays are not even present
physically. But it is true that some boards have gpio switches that can
be used to change the display during runtime.
> Is there any strong pros you obtain while removing this feature?
For an user, only indirectly. The change will make things sane on the
display side, and will thus make it much easier to proceed towards DT
adaptation, and Common Display Framework. While I can't say it's a
strict must to remove this feature, I can say that it's been a constant
headache for me for, well, ever. And I presume CDF would not have this
feature anyway, as it's rather bad design.
>> So the ifdeffery is not very nice. But, as discussed, this is the best way
>> forward, and should be seen as a temporary solution until we get full DT
>> support.
>
> I've missed this discussion, can you please point to it?
Well, not so much discussion, but a few mails under "Display related
board specific boot args" subject on l-o. I proposed a board specific
kernel argument to select the displays present, Tony was less than
enthusiastic about that.
> And what will change with full DT support?
> Will we be able to define several displays through DT and
> select and active one during runtime?
No, not as such. DT will let the bootloader pass the DT data, thus
telling which displays are present. So we can have single kernel binary,
which will work for all the cases.
Dynamic switching during runtime will still be missing. For that I think
we need board specific drivers. That driver should know about board
specific restrictions etc (which are rather missing currently), remove
the old display device, and create the new one.
Well, actually, if there was a way to add a device while somehow marking
it so that no driver will be bound to it... Then the user could use the
standard sysfs interface to bind a driver to the device. I wonder if
that could be done...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-03-28 16:48 ` Tomi Valkeinen
@ 2013-03-28 16:57 ` Tony Lindgren
2013-03-31 8:41 ` Igor Grinberg
2013-03-31 8:39 ` Igor Grinberg
1 sibling, 1 reply; 50+ messages in thread
From: Tony Lindgren @ 2013-03-28 16:57 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Igor Grinberg, linux-omap, Archit Taneja, Dmitry Lifshitz
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130328 09:53]:
> On 2013-03-28 17:31, Igor Grinberg wrote:
> > On 03/28/13 14:48, Tomi Valkeinen wrote:
> >
> > I've missed this discussion, can you please point to it?
>
> Well, not so much discussion, but a few mails under "Display related
> board specific boot args" subject on l-o. I proposed a board specific
> kernel argument to select the displays present, Tony was less than
> enthusiastic about that.
If we can come up with a Linux generic command line option to select
the panel that can be supported also in the long run, I have no
objections to that naturally. What I'm against is a temporary
custom cmdline option until the board-*.c files go away as we
don't want to support it in the long run.
Regards,
Tony
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-03-28 16:57 ` Tony Lindgren
@ 2013-03-31 8:41 ` Igor Grinberg
0 siblings, 0 replies; 50+ messages in thread
From: Igor Grinberg @ 2013-03-31 8:41 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Tomi Valkeinen, linux-omap, Archit Taneja, Dmitry Lifshitz
On 03/28/13 18:57, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130328 09:53]:
>> On 2013-03-28 17:31, Igor Grinberg wrote:
>>> On 03/28/13 14:48, Tomi Valkeinen wrote:
>>>
>>> I've missed this discussion, can you please point to it?
>>
>> Well, not so much discussion, but a few mails under "Display related
>> board specific boot args" subject on l-o. I proposed a board specific
>> kernel argument to select the displays present, Tony was less than
>> enthusiastic about that.
>
> If we can come up with a Linux generic command line option to select
> the panel that can be supported also in the long run, I have no
> objections to that naturally. What I'm against is a temporary
> custom cmdline option until the board-*.c files go away as we
> don't want to support it in the long run.
Agreed totally, the panel select option does not have to be
board specific (and it better not be...).
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-03-28 16:48 ` Tomi Valkeinen
2013-03-28 16:57 ` Tony Lindgren
@ 2013-03-31 8:39 ` Igor Grinberg
2013-03-31 15:03 ` Greg Kroah-Hartman
2013-04-02 8:01 ` Tomi Valkeinen
1 sibling, 2 replies; 50+ messages in thread
From: Igor Grinberg @ 2013-03-31 8:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap, Archit Taneja, Dmitry Lifshitz,
Greg Kroah-Hartman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/28/13 18:48, Tomi Valkeinen wrote:
> On 2013-03-28 17:31, Igor Grinberg wrote:
>> On 03/28/13 14:48, Tomi Valkeinen wrote:
>>> So here are the DSS related board file changes for 3.10.
>>>
>>> First there are a bunch of patches adding the Kconfig options so that only one
>>> display device is created for a single video bus. Only Overo had more than two
>>> displays on the same bus, but unfortunately there were multiple boards with a
>>> setup that puts an LCD and DVI output on the same video bus.
>>
>> Hmmm, so basically, if one could switch the display at runtime...
>> This cannot be done anymore...
>> This sounds like feature removal, no?
>> I know several of our clients who used this feature
>> (at least for evaluation purposes).
>
> At some point in time it was possible to have multiple displays for the
> same bus, and switch them at runtime.
>
> Sometime later it was changed so that the board file adds all the
> displays, but only one (per bus) is actually added to the list of
> panels, but you could still set the default display in the kernel args,
> and thus you could select which display gets added.
Yeah, I remember we had to hack this to have the functionality back...
>
> The reason why the multiple-displays-per-bus is problematic is that the
> video bus cannot be shared, and if we have multiple devices on the same
> bus, the drivers need extra trickery, delaying initializations, etc, to
> handle this. And it still doesn't work right, as it's easy to get two
> displays enabled at the same time, configuring the same video bus,
> creating a mess.
Yep, looks like additional display manager framework is needed.
Which will manage the displays on per bus basis?
>
> Quite often the case is that the other displays are not even present
> physically. But it is true that some boards have gpio switches that can
> be used to change the display during runtime.
I don't think the runtime switch requirement will ever go away, so we'd
better prepare for it wisely.
>
>> Is there any strong pros you obtain while removing this feature?
>
> For an user, only indirectly. The change will make things sane on the
> display side, and will thus make it much easier to proceed towards DT
> adaptation, and Common Display Framework. While I can't say it's a
> strict must to remove this feature, I can say that it's been a constant
> headache for me for, well, ever. And I presume CDF would not have this
> feature anyway, as it's rather bad design.
Well, I don't know about the CDF, but the runtime switch was there
for ages... Think of a DVI or an HDMI... they have the EDID stuff
to make the switch work as expected and it really brings multiple
displays to the same video bus.
I see this is only a meter of how we represent things.
Instead of real EDID (or in addition), that comes with the display,
currently we have the panel info already in the kernel and
panel driver with board specific callbacks to make it work.
So abstracting the above (in the long run) to CDF or some other
framework, should suit everybody's needs.
Probably, we will need board specific drivers, but that never
was a problem...
>
>>> So the ifdeffery is not very nice. But, as discussed, this is the best way
>>> forward, and should be seen as a temporary solution until we get full DT
>>> support.
>>
>> I've missed this discussion, can you please point to it?
>
> Well, not so much discussion, but a few mails under "Display related
> board specific boot args" subject on l-o. I proposed a board specific
> kernel argument to select the displays present, Tony was less than
> enthusiastic about that.
Yes, I can understand that ;-)
>
>> And what will change with full DT support?
>> Will we be able to define several displays through DT and
>> select and active one during runtime?
>
> No, not as such. DT will let the bootloader pass the DT data, thus
> telling which displays are present. So we can have single kernel binary,
> which will work for all the cases.
IMO, single kernel binary is a must.
>
> Dynamic switching during runtime will still be missing.
This is not good, as it removes a functionality that worked before...
> For that I think
> we need board specific drivers. That driver should know about board
> specific restrictions etc (which are rather missing currently), remove
> the old display device, and create the new one.
Well, yes we need a board specific drivers, but we need even more...
Board specific driver should not poke with devices...
I think for that we will need some kind of generic display manager
(may be a part of CDF) that will deal with the device registration/removal
and board specific drivers should implement some kind of API of the
generic display manger.
>
> Well, actually, if there was a way to add a device while somehow marking
> it so that no driver will be bound to it... Then the user could use the
> standard sysfs interface to bind a driver to the device. I wonder if
> that could be done...
I don't think this can fit current platform device framework.
But may be I'm missing something...
May be Greg can comment on this? Greg?
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRV/YlAAoJEBDE8YO64Efa8tUP/RAMY1oYNkRpmSnBF6Zqeezz
Boq+Et3rUQpxHVsapYrrOXxRkg9FOhgJ9kWt3T5THJcY2KhUNuNM2fM3+ruvzgzl
DHVqEYpNFUXdd6+Cb5ZN48Txuw2/u1CcStOgJYsAEaskj6CqW4K4l8NhwBXWzKEv
AftKYXKEhhmCQiPIXcOPjGuGxV6jdIn0xl7XolTggBF0fZwIFg22en5jKYCLo/s/
GlMw0jBeyXhtPpgJzs+OWkbwZLdRqEyBasJJliNkrVPUm3rAopQ/+TJRTT3MNCUj
Gc3w9JUI35TNt0P8QDQi2L/Nky+r6pZVV8MHtOT4RXz5euKQllm2yiw4MxVcJr18
XHmcOZcaeoTUYH/J0TW7yJK3+Lox0jWLpx/0VyMomRQF6NtZ2h2TtLWKeyh1HG5z
+10nqj6BFCjvinkRYwwFiL877PBVO1efe8ur0AvdnAwW0dBIvOwcC16M/V5Vpzz3
4azvw/Xtpex0fWFI31usgMd0O8pCOdS96A+x1gmGiZBH4UXAiTN0+VOzvNU43kZ4
KgpHFfrkHKr3DU+SpJJfV49Pgjx2czUEgxMeDGYaPcVwcrkE57aP5XyBp+qPOXfi
Jlh+frSBkZ0LPDVA1Tc5h49bupIV+hxeSiDdZKr1ET2ijkwsewNp9AV1ZILRbICP
mrp5py+udPRaIPjQV8v6
=Vrec
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-03-31 8:39 ` Igor Grinberg
@ 2013-03-31 15:03 ` Greg Kroah-Hartman
2013-04-02 8:01 ` Tomi Valkeinen
1 sibling, 0 replies; 50+ messages in thread
From: Greg Kroah-Hartman @ 2013-03-31 15:03 UTC (permalink / raw)
To: Igor Grinberg
Cc: Tomi Valkeinen, Tony Lindgren, linux-omap, Archit Taneja,
Dmitry Lifshitz
On Sun, Mar 31, 2013 at 11:39:01AM +0300, Igor Grinberg wrote:
> > Well, actually, if there was a way to add a device while somehow marking
> > it so that no driver will be bound to it... Then the user could use the
> > standard sysfs interface to bind a driver to the device. I wonder if
> > that could be done...
>
> I don't think this can fit current platform device framework.
> But may be I'm missing something...
> May be Greg can comment on this? Greg?
I have no idea what you all are talking about, sorry.
greg k-h
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-03-31 8:39 ` Igor Grinberg
2013-03-31 15:03 ` Greg Kroah-Hartman
@ 2013-04-02 8:01 ` Tomi Valkeinen
2013-04-02 8:40 ` Igor Grinberg
1 sibling, 1 reply; 50+ messages in thread
From: Tomi Valkeinen @ 2013-04-02 8:01 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Dmitry Lifshitz
[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]
On 2013-03-31 11:39, Igor Grinberg wrote:
> On 03/28/13 18:48, Tomi Valkeinen wrote:
>> On 2013-03-28 17:31, Igor Grinberg wrote:
>>> On 03/28/13 14:48, Tomi Valkeinen wrote:
>>>> So here are the DSS related board file changes for 3.10.
>>>>
>>>> First there are a bunch of patches adding the Kconfig options so that only one
>>>> display device is created for a single video bus. Only Overo had more than two
>>>> displays on the same bus, but unfortunately there were multiple boards with a
>>>> setup that puts an LCD and DVI output on the same video bus.
>>>
>>> Hmmm, so basically, if one could switch the display at runtime...
>>> This cannot be done anymore...
>>> This sounds like feature removal, no?
>>> I know several of our clients who used this feature
>>> (at least for evaluation purposes).
>
>> At some point in time it was possible to have multiple displays for the
>> same bus, and switch them at runtime.
>
>> Sometime later it was changed so that the board file adds all the
>> displays, but only one (per bus) is actually added to the list of
>> panels, but you could still set the default display in the kernel args,
>> and thus you could select which display gets added.
>
> Yeah, I remember we had to hack this to have the functionality back...
Ok. You could've informed me so that I knew it's needed =). I've
received no complaints about it, so I thought nobody is even using it.
>> The reason why the multiple-displays-per-bus is problematic is that the
>> video bus cannot be shared, and if we have multiple devices on the same
>> bus, the drivers need extra trickery, delaying initializations, etc, to
>> handle this. And it still doesn't work right, as it's easy to get two
>> displays enabled at the same time, configuring the same video bus,
>> creating a mess.
>
> Yep, looks like additional display manager framework is needed.
> Which will manage the displays on per bus basis?
>
>
>> Quite often the case is that the other displays are not even present
>> physically. But it is true that some boards have gpio switches that can
>> be used to change the display during runtime.
>
> I don't think the runtime switch requirement will ever go away, so we'd
> better prepare for it wisely.
>
>
>>> Is there any strong pros you obtain while removing this feature?
>
>> For an user, only indirectly. The change will make things sane on the
>> display side, and will thus make it much easier to proceed towards DT
>> adaptation, and Common Display Framework. While I can't say it's a
>> strict must to remove this feature, I can say that it's been a constant
>> headache for me for, well, ever. And I presume CDF would not have this
>> feature anyway, as it's rather bad design.
>
> Well, I don't know about the CDF, but the runtime switch was there
> for ages... Think of a DVI or an HDMI... they have the EDID stuff
> to make the switch work as expected and it really brings multiple
> displays to the same video bus.
> I see this is only a meter of how we represent things.
> Instead of real EDID (or in addition), that comes with the display,
> currently we have the panel info already in the kernel and
> panel driver with board specific callbacks to make it work.
> So abstracting the above (in the long run) to CDF or some other
> framework, should suit everybody's needs.
> Probably, we will need board specific drivers, but that never
> was a problem...
Comparing desktop DVI/HDMI to our case is not a very good comparison.
For desktop DVI/HDMI there are no panel devices or such, so it's trivial
to manage multiple outputs in the display driver.
We need panel device hotplug/unplug support to make this work properly,
and as there's no generic way to do that, we need board specific drivers
to handle the hotplug/unplug.
And we probably need some way to show the information about possible
displays to the userspace. I mean, with a case like DVI/Panel on the
board, it would make sense to show the userspace that there are those
two options, even if the other device is not even present.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-04-02 8:01 ` Tomi Valkeinen
@ 2013-04-02 8:40 ` Igor Grinberg
0 siblings, 0 replies; 50+ messages in thread
From: Igor Grinberg @ 2013-04-02 8:40 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, Archit Taneja, Dmitry Lifshitz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/02/13 11:01, Tomi Valkeinen wrote:
> On 2013-03-31 11:39, Igor Grinberg wrote:
>> On 03/28/13 18:48, Tomi Valkeinen wrote:
>>> On 2013-03-28 17:31, Igor Grinberg wrote:
>>>> On 03/28/13 14:48, Tomi Valkeinen wrote:
>>>>> So here are the DSS related board file changes for 3.10.
>>>>>
>>>>> First there are a bunch of patches adding the Kconfig options so that only one
>>>>> display device is created for a single video bus. Only Overo had more than two
>>>>> displays on the same bus, but unfortunately there were multiple boards with a
>>>>> setup that puts an LCD and DVI output on the same video bus.
>>>>
>>>> Hmmm, so basically, if one could switch the display at runtime...
>>>> This cannot be done anymore...
>>>> This sounds like feature removal, no?
>>>> I know several of our clients who used this feature
>>>> (at least for evaluation purposes).
>>
>>> At some point in time it was possible to have multiple displays for the
>>> same bus, and switch them at runtime.
>>
>>> Sometime later it was changed so that the board file adds all the
>>> displays, but only one (per bus) is actually added to the list of
>>> panels, but you could still set the default display in the kernel args,
>>> and thus you could select which display gets added.
>>
>> Yeah, I remember we had to hack this to have the functionality back...
>
> Ok. You could've informed me so that I knew it's needed =). I've
> received no complaints about it, so I thought nobody is even using it.
Yeah, I know, we wanted to make sure that this is not our fault and when
we did and it worked, I've lost in the amount of patches for DSS that were
sent and what are the real intentions (also taking into account that it all
was post factum).
>
>>> The reason why the multiple-displays-per-bus is problematic is that the
>>> video bus cannot be shared, and if we have multiple devices on the same
>>> bus, the drivers need extra trickery, delaying initializations, etc, to
>>> handle this. And it still doesn't work right, as it's easy to get two
>>> displays enabled at the same time, configuring the same video bus,
>>> creating a mess.
>>
>> Yep, looks like additional display manager framework is needed.
>> Which will manage the displays on per bus basis?
>>
>>
>>> Quite often the case is that the other displays are not even present
>>> physically. But it is true that some boards have gpio switches that can
>>> be used to change the display during runtime.
>>
>> I don't think the runtime switch requirement will ever go away, so we'd
>> better prepare for it wisely.
>>
>>
>>>> Is there any strong pros you obtain while removing this feature?
>>
>>> For an user, only indirectly. The change will make things sane on the
>>> display side, and will thus make it much easier to proceed towards DT
>>> adaptation, and Common Display Framework. While I can't say it's a
>>> strict must to remove this feature, I can say that it's been a constant
>>> headache for me for, well, ever. And I presume CDF would not have this
>>> feature anyway, as it's rather bad design.
>>
>> Well, I don't know about the CDF, but the runtime switch was there
>> for ages... Think of a DVI or an HDMI... they have the EDID stuff
>> to make the switch work as expected and it really brings multiple
>> displays to the same video bus.
>> I see this is only a meter of how we represent things.
>> Instead of real EDID (or in addition), that comes with the display,
>> currently we have the panel info already in the kernel and
>> panel driver with board specific callbacks to make it work.
>> So abstracting the above (in the long run) to CDF or some other
>> framework, should suit everybody's needs.
>> Probably, we will need board specific drivers, but that never
>> was a problem...
>
> Comparing desktop DVI/HDMI to our case is not a very good comparison.
> For desktop DVI/HDMI there are no panel devices or such, so it's trivial
> to manage multiple outputs in the display driver.
Well, reading EDID can sometimes involve additional hackery, but you are
right in the general case.
>
> We need panel device hotplug/unplug support to make this work properly,
> and as there's no generic way to do that, we need board specific drivers
> to handle the hotplug/unplug.
Yep, I don't see any problem with having board specific drivers.
Multiple subsystems have them, so we also can have them in CDF.
>
> And we probably need some way to show the information about possible
> displays to the userspace. I mean, with a case like DVI/Panel on the
> board, it would make sense to show the userspace that there are those
> two options, even if the other device is not even present.
Indeed this is needed for the runtime switch.
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRWplwAAoJEBDE8YO64EfaKH4P/jaMuXrGyvCmfYgD5OLFU0fV
BvsLyy0/DVqoDjB2N8YH8PnuixKrP17L8nEDckq725byXf/ZQEIaYTeyBZ/COYDD
NGAkVn8sFe2w7FLsg+dVa2+GSgYL2Pprvvf4DrJy1JMepBsDlaSkZL7V5LOq7m7J
7PIMizeZIngeDy4OHu4BNAksylPUj/3iqPDGJ9BZpgzoj1TwbPDG/ECyKADD9J8+
JHrK+aSnJFI/5qE+J1j+6ghYhDnIz5OQqtjA/CHNLaBOloNIk6FxgbMAt+Eu+xBZ
7zZ9kk/Esh1QwfdelHHkH1gW7ogfsBqa5lvJ3pa/R06lOaeEAewUSpSzF02+fVqN
hg3shXOjw5ukjxqDytvOtPjb9vJrJ2nHRa2ftmEo2f5w2CJOyOgul1B+QODjztgb
VJCGhAt/+RSxI2RvmRkR9jgG/GNm3psFSBGWQbMN4jND9/ToNEJBDbBP2ewiPe7i
a3ZtAD0ZiUF9sWt27e3r6jT2nHwp0/35uVTigeHzJBTnwliykO/djhyxgO+IGDKn
9iugdPJceh1L8HBfJ+u+MdN+2qpNONzAvP8N1GJWiL5U8hzkR6wNb/r5Hk0gDxaG
crPn8c3BrmSlEcy7kywM2MOe14wZOMPGW5H2LQ6lPA2VXGz4iFioeM3TdEMMv11H
pxMvFk4hNPbXgwSyHlAj
=H7CL
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 00/28] OMAP: DSS related board file changes
2013-03-28 12:48 [PATCH 00/28] OMAP: DSS related board file changes Tomi Valkeinen
` (28 preceding siblings ...)
2013-03-28 15:31 ` [PATCH 00/28] OMAP: DSS related board file changes Igor Grinberg
@ 2013-04-03 9:36 ` Tomi Valkeinen
29 siblings, 0 replies; 50+ messages in thread
From: Tomi Valkeinen @ 2013-04-03 9:36 UTC (permalink / raw)
To: Tony Lindgren, Igor Grinberg; +Cc: linux-omap, Archit Taneja
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
Hi,
On 2013-03-28 14:48, Tomi Valkeinen wrote:
> So here are the DSS related board file changes for 3.10.
>
> First there are a bunch of patches adding the Kconfig options so that only one
> display device is created for a single video bus. Only Overo had more than two
> displays on the same bus, but unfortunately there were multiple boards with a
> setup that puts an LCD and DVI output on the same video bus.
>
> So the ifdeffery is not very nice. But, as discussed, this is the best way
> forward, and should be seen as a temporary solution until we get full DT
> support.
>
> Then the rest are converting the old omap_dss_device style displays to platform
> devices. Only TFP410, generic-dpi-panel, HDMI and Taal drivers have been
> converted yet, but those seem to form the bulk of the display options used.
>
> This series can be found from:
> git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/1-arch-dss
>
> These patches depend on a few dss header file changes. These header file
> changes can be found from:
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
>
> If this series is applied without the relevant omapdss changes, everything
> compiles and the boards boot, but the converted displays do not work. The same
> happens if only the omapdss changes are applied, but not this series.
>
> The related omapdss changes can be found from:
> git://gitorious.org/linux-omap-dss2/linux.git 3.10/3-dss-dev-model
I'll drop these patches and the branches mentioned above, as I don't
have a solution to the multiple-displays-per-output problem. I'll
continue looking at this, but it surely won't make into the next merge
window.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread