[PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing

[PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing

[Tomi Valkeinen]

New u-boot versions no longer set the pinmuxing for Panda's DPI output,
and the muxing has to be done in the .dts file.

Add pinmuxing for DPI and TFP410. Without these, the DVI output on Panda
does not work with recent u-boot.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi | 43 +++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..fcb8856 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -129,6 +129,8 @@
 			&twl6040_pins
 			&mcpdm_pins
 			&mcbsp1_pins
+			&dss_dpi_pins
+			&tfp410_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
 			&hsusbb1_pins
@@ -166,6 +168,47 @@
 		>;
 	};
 
+	dss_dpi_pins: pinmux_dss_dpi_pins {
+		pinctrl-single,pins = <
+			0x122 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data23 */
+			0x124 (PIN_OUTPUT | MUX_MODE5) 	/* dispc2_data22 */
+			0x126 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data21 */
+			0x128 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data20 */
+			0x12a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data19 */
+			0x12c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data18 */
+			0x12e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data15 */
+			0x130 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data14 */
+			0x132 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data13 */
+			0x134 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data12 */
+			0x136 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data11 */
+
+			0x174 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data10 */
+			0x176 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data9 */
+			0x178 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data16 */
+			0x17a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data17 */
+			0x17c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_hsync */
+			0x17e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_pclk */
+			0x180 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_vsync */
+			0x182 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_de */
+			0x184 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data8 */
+			0x186 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data7 */
+			0x188 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data6 */
+			0x18a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data5 */
+			0x18c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data4 */
+			0x18e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data3 */
+
+			0x190 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data2 */
+			0x192 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data1 */
+			0x194 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data0 */
+		>;
+	};
+
+	tfp410_pins: pinmux_tfp410_pins {
+		pinctrl-single,pins = <
+			0x144 (PIN_OUTPUT | MUX_MODE3)	/* gpio_0 */
+		>;
+	};
+
 	dss_hdmi_pins: pinmux_dss_hdmi_pins {
 		pinctrl-single,pins = <
 			0x5a (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_cec.hdmi_cec */
-- 
1.8.1.2

[PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing

[Tomi Valkeinen]

New u-boot versions no longer set the pinmuxing for Panda's DPI output,
and the muxing has to be done in the .dts file.

Add pinmuxing for DPI and TFP410. Without these, the DVI output on Panda
does not work with recent u-boot.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi | 43 +++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..fcb8856 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -129,6 +129,8 @@
 			&twl6040_pins
 			&mcpdm_pins
 			&mcbsp1_pins
+			&dss_dpi_pins
+			&tfp410_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
 			&hsusbb1_pins
@@ -166,6 +168,47 @@
 		>;
 	};
 
+	dss_dpi_pins: pinmux_dss_dpi_pins {
+		pinctrl-single,pins = <
+			0x122 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data23 */
+			0x124 (PIN_OUTPUT | MUX_MODE5) 	/* dispc2_data22 */
+			0x126 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data21 */
+			0x128 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data20 */
+			0x12a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data19 */
+			0x12c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data18 */
+			0x12e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data15 */
+			0x130 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data14 */
+			0x132 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data13 */
+			0x134 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data12 */
+			0x136 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data11 */
+
+			0x174 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data10 */
+			0x176 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data9 */
+			0x178 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data16 */
+			0x17a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data17 */
+			0x17c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_hsync */
+			0x17e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_pclk */
+			0x180 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_vsync */
+			0x182 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_de */
+			0x184 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data8 */
+			0x186 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data7 */
+			0x188 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data6 */
+			0x18a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data5 */
+			0x18c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data4 */
+			0x18e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data3 */
+
+			0x190 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data2 */
+			0x192 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data1 */
+			0x194 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data0 */
+		>;
+	};
+
+	tfp410_pins: pinmux_tfp410_pins {
+		pinctrl-single,pins = <
+			0x144 (PIN_OUTPUT | MUX_MODE3)	/* gpio_0 */
+		>;
+	};
+
 	dss_hdmi_pins: pinmux_dss_hdmi_pins {
 		pinctrl-single,pins = <
 			0x5a (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_cec.hdmi_cec */
-- 
1.8.1.2

[PATCH 2/3] ARM: dts: omap4-sdp: add LCD pinmuxing

[Tomi Valkeinen]

Add pinmuxing for the LCD panels.

Both panels have a reset GPIO, but the second one has some extra
complexity: some boards have a PicoDLP projector, which shares resources
with the LCD2. We don't currently support switching between the PicoDL
and the LCD2, so we use pin pull-ups and pull-downs to select the LCD2.

GPIO40 is pulled down, which disables the PicoDLP power. GPIO59 is
pulled up, which selects the LCD2.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap4-sdp.dts | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..ed14a7a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -166,6 +166,8 @@
 			&mcbsp2_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
+			&lcd1_pins
+			&lcd2_pins
 	>;
 
 	uart2_pins: pinmux_uart2_pins {
@@ -268,6 +270,25 @@
 		>;
 	};
 
+	lcd1_pins: pinmux_lcd1_pins {
+		pinctrl-single,pins = <
+			0x52 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_102 */
+		>;
+	};
+
+	/*
+	 * GPIO 59 is used to switch between LCD2 and PicoDLP. We don't support
+	 * the switching, so set the pin to PULLUP which enables the LCD2.
+	 * GPIO 40 enables power to PicoDLP. Use PULLDOWN to disable power.
+	 */
+	lcd2_pins: pinmux_lcd2_pins {
+		pinctrl-single,pins = <
+			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
+			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
+			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
+		>;
+	};
+
 	i2c1_pins: pinmux_i2c1_pins {
 		pinctrl-single,pins = <
 			0xe2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_scl */
-- 
1.8.1.2

[PATCH 2/3] ARM: dts: omap4-sdp: add LCD pinmuxing

[Tomi Valkeinen]

Add pinmuxing for the LCD panels.

Both panels have a reset GPIO, but the second one has some extra
complexity: some boards have a PicoDLP projector, which shares resources
with the LCD2. We don't currently support switching between the PicoDL
and the LCD2, so we use pin pull-ups and pull-downs to select the LCD2.

GPIO40 is pulled down, which disables the PicoDLP power. GPIO59 is
pulled up, which selects the LCD2.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap4-sdp.dts | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..ed14a7a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -166,6 +166,8 @@
 			&mcbsp2_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
+			&lcd1_pins
+			&lcd2_pins
 	>;
 
 	uart2_pins: pinmux_uart2_pins {
@@ -268,6 +270,25 @@
 		>;
 	};
 
+	lcd1_pins: pinmux_lcd1_pins {
+		pinctrl-single,pins = <
+			0x52 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_102 */
+		>;
+	};
+
+	/*
+	 * GPIO 59 is used to switch between LCD2 and PicoDLP. We don't support
+	 * the switching, so set the pin to PULLUP which enables the LCD2.
+	 * GPIO 40 enables power to PicoDLP. Use PULLDOWN to disable power.
+	 */
+	lcd2_pins: pinmux_lcd2_pins {
+		pinctrl-single,pins = <
+			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
+			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
+			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
+		>;
+	};
+
 	i2c1_pins: pinmux_i2c1_pins {
 		pinctrl-single,pins = <
 			0xe2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_scl */
-- 
1.8.1.2

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

DISPLAY_SEL_GPIO and DLP_POWER_ON_GPIO are now handled in the .dts file,
so we can remove them from dss-common.c.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index bf89eff..cc70cf9 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -113,9 +113,6 @@ void __init omap4_panda_display_init_of(void)
 
 /* OMAP4 Blaze display data */
 
-#define DISPLAY_SEL_GPIO	59	/* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO	40
-
 static struct panel_dsicm_platform_data dsi1_panel = {
 	.name		= "lcd",
 	.source		= "dsi.0",
@@ -185,26 +182,8 @@ static struct omap_dss_board_info sdp4430_dss_data = {
 	.default_display_name = "lcd",
 };
 
-/*
- * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
- * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
- * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
- * selected by default
- */
 void __init omap_4430sdp_display_init_of(void)
 {
-	int r;
-
-	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
-			"display_sel");
-	if (r)
-		pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
-	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
-		"DLP POWER ON");
-	if (r)
-		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
 	omap_display_init(&sdp4430_dss_data);
 
 	platform_device_register(&sdp4430_lcd_device);
-- 
1.8.1.2

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

DISPLAY_SEL_GPIO and DLP_POWER_ON_GPIO are now handled in the .dts file,
so we can remove them from dss-common.c.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index bf89eff..cc70cf9 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -113,9 +113,6 @@ void __init omap4_panda_display_init_of(void)
 
 /* OMAP4 Blaze display data */
 
-#define DISPLAY_SEL_GPIO	59	/* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO	40
-
 static struct panel_dsicm_platform_data dsi1_panel = {
 	.name		= "lcd",
 	.source		= "dsi.0",
@@ -185,26 +182,8 @@ static struct omap_dss_board_info sdp4430_dss_data = {
 	.default_display_name = "lcd",
 };
 
-/*
- * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
- * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
- * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
- * selected by default
- */
 void __init omap_4430sdp_display_init_of(void)
 {
-	int r;
-
-	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
-			"display_sel");
-	if (r)
-		pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
-	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
-		"DLP POWER ON");
-	if (r)
-		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
 	omap_display_init(&sdp4430_dss_data);
 
 	platform_device_register(&sdp4430_lcd_device);
-- 
1.8.1.2

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 05:07 AM, Tomi Valkeinen wrote:
> DISPLAY_SEL_GPIO and DLP_POWER_ON_GPIO are now handled in the .dts file,
> so we can remove them from dss-common.c.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  arch/arm/mach-omap2/dss-common.c | 21 ---------------------
>  1 file changed, 21 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
> index bf89eff..cc70cf9 100644
> --- a/arch/arm/mach-omap2/dss-common.c
> +++ b/arch/arm/mach-omap2/dss-common.c
> @@ -113,9 +113,6 @@ void __init omap4_panda_display_init_of(void)
>  
>  /* OMAP4 Blaze display data */
>  
> -#define DISPLAY_SEL_GPIO	59	/* LCD2/PicoDLP switch */
> -#define DLP_POWER_ON_GPIO	40
> -
>  static struct panel_dsicm_platform_data dsi1_panel = {
>  	.name		= "lcd",
>  	.source		= "dsi.0",
> @@ -185,26 +182,8 @@ static struct omap_dss_board_info sdp4430_dss_data = {
>  	.default_display_name = "lcd",
>  };
>  
> -/*
> - * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
> - * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
> - * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
> - * selected by default
> - */
>  void __init omap_4430sdp_display_init_of(void)
>  {
> -	int r;
> -
> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
> -			"display_sel");
> -	if (r)
> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
> -
> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
> -		"DLP POWER ON");
> -	if (r)
> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
> -
>  	omap_display_init(&sdp4430_dss_data);
>  
>  	platform_device_register(&sdp4430_lcd_device);
> 
would you not be depending on the weak IO pull done using mux to drive
these GPIO pins since the GPIO is not requested and held?

Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
binding to map to the right GPIO and drive it using the GPIO module?

-- 
Regards,
Nishanth Menon

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 05:07 AM, Tomi Valkeinen wrote:
> DISPLAY_SEL_GPIO and DLP_POWER_ON_GPIO are now handled in the .dts file,
> so we can remove them from dss-common.c.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  arch/arm/mach-omap2/dss-common.c | 21 ---------------------
>  1 file changed, 21 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
> index bf89eff..cc70cf9 100644
> --- a/arch/arm/mach-omap2/dss-common.c
> +++ b/arch/arm/mach-omap2/dss-common.c
> @@ -113,9 +113,6 @@ void __init omap4_panda_display_init_of(void)
>  
>  /* OMAP4 Blaze display data */
>  
> -#define DISPLAY_SEL_GPIO	59	/* LCD2/PicoDLP switch */
> -#define DLP_POWER_ON_GPIO	40
> -
>  static struct panel_dsicm_platform_data dsi1_panel = {
>  	.name		= "lcd",
>  	.source		= "dsi.0",
> @@ -185,26 +182,8 @@ static struct omap_dss_board_info sdp4430_dss_data = {
>  	.default_display_name = "lcd",
>  };
>  
> -/*
> - * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
> - * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
> - * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
> - * selected by default
> - */
>  void __init omap_4430sdp_display_init_of(void)
>  {
> -	int r;
> -
> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
> -			"display_sel");
> -	if (r)
> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
> -
> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
> -		"DLP POWER ON");
> -	if (r)
> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
> -
>  	omap_display_init(&sdp4430_dss_data);
>  
>  	platform_device_register(&sdp4430_lcd_device);
> 
would you not be depending on the weak IO pull done using mux to drive
these GPIO pins since the GPIO is not requested and held?

Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
binding to map to the right GPIO and drive it using the GPIO module?

-- 
Regards,
Nishanth Menon

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On 25/10/13 13:18, Nishanth Menon wrote:

>>  void __init omap_4430sdp_display_init_of(void)
>>  {
>> -	int r;
>> -
>> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
>> -			"display_sel");
>> -	if (r)
>> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
>> -
>> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
>> -		"DLP POWER ON");
>> -	if (r)
>> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
>> -
>>  	omap_display_init(&sdp4430_dss_data);
>>  
>>  	platform_device_register(&sdp4430_lcd_device);
>>
> would you not be depending on the weak IO pull done using mux to drive
> these GPIO pins since the GPIO is not requested and held?

Yes. Is that not enough?

> Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
> binding to map to the right GPIO and drive it using the GPIO module?

Hmm, what do you mean?

I do mux the pins to gpios, but there's nothing in the kernel that would
use those gpios. That's why we had the hack above, but I'd love to get
rid of it.

Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts?

If things were perfect, we probably would have a driver for the "switch"
part. I have no idea what kind of driver that would be, though, so at
the moment we've just gone with the use-LCD2-by-default route.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

On 25/10/13 13:18, Nishanth Menon wrote:

>>  void __init omap_4430sdp_display_init_of(void)
>>  {
>> -	int r;
>> -
>> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
>> -			"display_sel");
>> -	if (r)
>> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
>> -
>> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
>> -		"DLP POWER ON");
>> -	if (r)
>> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
>> -
>>  	omap_display_init(&sdp4430_dss_data);
>>  
>>  	platform_device_register(&sdp4430_lcd_device);
>>
> would you not be depending on the weak IO pull done using mux to drive
> these GPIO pins since the GPIO is not requested and held?

Yes. Is that not enough?

> Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
> binding to map to the right GPIO and drive it using the GPIO module?

Hmm, what do you mean?

I do mux the pins to gpios, but there's nothing in the kernel that would
use those gpios. That's why we had the hack above, but I'd love to get
rid of it.

Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts?

If things were perfect, we probably would have a driver for the "switch"
part. I have no idea what kind of driver that would be, though, so at
the moment we've just gone with the use-LCD2-by-default route.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/b14d1d18/attachment.sig>

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 05:25 AM, Tomi Valkeinen wrote:
> On 25/10/13 13:18, Nishanth Menon wrote:
> 
>>>  void __init omap_4430sdp_display_init_of(void)
>>>  {
>>> -	int r;
>>> -
>>> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
>>> -			"display_sel");
>>> -	if (r)
>>> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
>>> -
>>> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
>>> -		"DLP POWER ON");
>>> -	if (r)
>>> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
>>> -
>>>  	omap_display_init(&sdp4430_dss_data);
>>>  
>>>  	platform_device_register(&sdp4430_lcd_device);
>>>
>> would you not be depending on the weak IO pull done using mux to drive
>> these GPIO pins since the GPIO is not requested and held?
> 
> Yes. Is that not enough?

It depend on what the signal draw is and io drive strength which
varies - original intent of weak pulls were to have a non-active
default state which are overriden by GPIOs as needed. Else we would
not be having strong pulls here in pads.

Typical padmux drive strength for OMAP4460 is around 100uA, min is
around 50uA. meanwhile as Documentation/gpio.txt generically states,
the buffers driving at 1.8v on OMAP4460 could be around 6mA or upto
8mA. Again, these depend on the specific pin in discussion and Data
manual explain is larger detail

Lower current is fine if the switch is ok with it and risk for
transients are reasonably safe. However, board designs generally
assume the stronger GPIO drive strength.

>> Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
>> binding to map to the right GPIO and drive it using the GPIO module?
> 
> Hmm, what do you mean?
> 
> I do mux the pins to gpios, but there's nothing in the kernel that would
> use those gpios. That's why we had the hack above, but I'd love to get
> rid of it.
> 
> Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts?
> 
> If things were perfect, we probably would have a driver for the "switch"
> part. I have no idea what kind of driver that would be, though, so at
> the moment we've just gone with the use-LCD2-by-default route.

I meant you could, in theory provide the gpio numbers and pull
directions in dts and allow the init to drive them as needed.

Something like:
drivers/i2c/busses/i2c-gpio.c as a reference and use
of_get_named_gpio/of_get_gpio to pick themup..


-- 
Regards,
Nishanth Menon

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 05:25 AM, Tomi Valkeinen wrote:
> On 25/10/13 13:18, Nishanth Menon wrote:
> 
>>>  void __init omap_4430sdp_display_init_of(void)
>>>  {
>>> -	int r;
>>> -
>>> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
>>> -			"display_sel");
>>> -	if (r)
>>> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
>>> -
>>> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
>>> -		"DLP POWER ON");
>>> -	if (r)
>>> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
>>> -
>>>  	omap_display_init(&sdp4430_dss_data);
>>>  
>>>  	platform_device_register(&sdp4430_lcd_device);
>>>
>> would you not be depending on the weak IO pull done using mux to drive
>> these GPIO pins since the GPIO is not requested and held?
> 
> Yes. Is that not enough?

It depend on what the signal draw is and io drive strength which
varies - original intent of weak pulls were to have a non-active
default state which are overriden by GPIOs as needed. Else we would
not be having strong pulls here in pads.

Typical padmux drive strength for OMAP4460 is around 100uA, min is
around 50uA. meanwhile as Documentation/gpio.txt generically states,
the buffers driving at 1.8v on OMAP4460 could be around 6mA or upto
8mA. Again, these depend on the specific pin in discussion and Data
manual explain is larger detail

Lower current is fine if the switch is ok with it and risk for
transients are reasonably safe. However, board designs generally
assume the stronger GPIO drive strength.

>> Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
>> binding to map to the right GPIO and drive it using the GPIO module?
> 
> Hmm, what do you mean?
> 
> I do mux the pins to gpios, but there's nothing in the kernel that would
> use those gpios. That's why we had the hack above, but I'd love to get
> rid of it.
> 
> Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts?
> 
> If things were perfect, we probably would have a driver for the "switch"
> part. I have no idea what kind of driver that would be, though, so at
> the moment we've just gone with the use-LCD2-by-default route.

I meant you could, in theory provide the gpio numbers and pull
directions in dts and allow the init to drive them as needed.

Something like:
drivers/i2c/busses/i2c-gpio.c as a reference and use
of_get_named_gpio/of_get_gpio to pick themup..


-- 
Regards,
Nishanth Menon

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 2530 bytes --]

On 25/10/13 13:54, Nishanth Menon wrote:

>>> would you not be depending on the weak IO pull done using mux to drive
>>> these GPIO pins since the GPIO is not requested and held?
>>
>> Yes. Is that not enough?
> 
> It depend on what the signal draw is and io drive strength which
> varies - original intent of weak pulls were to have a non-active
> default state which are overriden by GPIOs as needed. Else we would
> not be having strong pulls here in pads.
> 
> Typical padmux drive strength for OMAP4460 is around 100uA, min is
> around 50uA. meanwhile as Documentation/gpio.txt generically states,
> the buffers driving at 1.8v on OMAP4460 could be around 6mA or upto
> 8mA. Again, these depend on the specific pin in discussion and Data
> manual explain is larger detail
> 
> Lower current is fine if the switch is ok with it and risk for
> transients are reasonably safe. However, board designs generally
> assume the stronger GPIO drive strength.

Ok. Well, it definitely sounds safer to have a proper gpio pull there, then.

>>> Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
>>> binding to map to the right GPIO and drive it using the GPIO module?
>>
>> Hmm, what do you mean?
>>
>> I do mux the pins to gpios, but there's nothing in the kernel that would
>> use those gpios. That's why we had the hack above, but I'd love to get
>> rid of it.
>>
>> Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts?
>>
>> If things were perfect, we probably would have a driver for the "switch"
>> part. I have no idea what kind of driver that would be, though, so at
>> the moment we've just gone with the use-LCD2-by-default route.
> 
> I meant you could, in theory provide the gpio numbers and pull
> directions in dts and allow the init to drive them as needed.
> 
> Something like:
> drivers/i2c/busses/i2c-gpio.c as a reference and use
> of_get_named_gpio/of_get_gpio to pick themup..

I'm still not quite following... What init are you referring to?

The problem here is that the gpios don't really belong to anyone in the
kernel, as we don't have a driver for the switch.

Or did you mean that we'd still have the code in dss-common.c, but just
get the gpio numbers from the .dts instead? That makes sense, although
I'd want to get rid of that code altogether.

Should we have support in the gpio-controller to define default values
for gpios? I don't think we can rely on the boot loader to set things
correctly.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

On 25/10/13 13:54, Nishanth Menon wrote:

>>> would you not be depending on the weak IO pull done using mux to drive
>>> these GPIO pins since the GPIO is not requested and held?
>>
>> Yes. Is that not enough?
> 
> It depend on what the signal draw is and io drive strength which
> varies - original intent of weak pulls were to have a non-active
> default state which are overriden by GPIOs as needed. Else we would
> not be having strong pulls here in pads.
> 
> Typical padmux drive strength for OMAP4460 is around 100uA, min is
> around 50uA. meanwhile as Documentation/gpio.txt generically states,
> the buffers driving at 1.8v on OMAP4460 could be around 6mA or upto
> 8mA. Again, these depend on the specific pin in discussion and Data
> manual explain is larger detail
> 
> Lower current is fine if the switch is ok with it and risk for
> transients are reasonably safe. However, board designs generally
> assume the stronger GPIO drive strength.

Ok. Well, it definitely sounds safer to have a proper gpio pull there, then.

>>> Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
>>> binding to map to the right GPIO and drive it using the GPIO module?
>>
>> Hmm, what do you mean?
>>
>> I do mux the pins to gpios, but there's nothing in the kernel that would
>> use those gpios. That's why we had the hack above, but I'd love to get
>> rid of it.
>>
>> Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts?
>>
>> If things were perfect, we probably would have a driver for the "switch"
>> part. I have no idea what kind of driver that would be, though, so at
>> the moment we've just gone with the use-LCD2-by-default route.
> 
> I meant you could, in theory provide the gpio numbers and pull
> directions in dts and allow the init to drive them as needed.
> 
> Something like:
> drivers/i2c/busses/i2c-gpio.c as a reference and use
> of_get_named_gpio/of_get_gpio to pick themup..

I'm still not quite following... What init are you referring to?

The problem here is that the gpios don't really belong to anyone in the
kernel, as we don't have a driver for the switch.

Or did you mean that we'd still have the code in dss-common.c, but just
get the gpio numbers from the .dts instead? That makes sense, although
I'd want to get rid of that code altogether.

Should we have support in the gpio-controller to define default values
for gpios? I don't think we can rely on the boot loader to set things
correctly.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/dfce2511/attachment.sig>

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 05:54 AM, Nishanth Menon wrote:
> On 10/25/2013 05:25 AM, Tomi Valkeinen wrote:
>> On 25/10/13 13:18, Nishanth Menon wrote:
>>
>>>>  void __init omap_4430sdp_display_init_of(void)
>>>>  {
>>>> -	int r;
>>>> -
>>>> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
>>>> -			"display_sel");
>>>> -	if (r)
>>>> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
>>>> -
>>>> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
>>>> -		"DLP POWER ON");
>>>> -	if (r)
>>>> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
>>>> -
>>>>  	omap_display_init(&sdp4430_dss_data);
>>>>  
>>>>  	platform_device_register(&sdp4430_lcd_device);
>>>>
>>> would you not be depending on the weak IO pull done using mux to drive
>>> these GPIO pins since the GPIO is not requested and held?
>>
>> Yes. Is that not enough?
> 
> It depend on what the signal draw is and io drive strength which
> varies - original intent of weak pulls were to have a non-active
> default state which are overriden by GPIOs as needed. Else we would
> not be having strong pulls here in pads.
> 
> Typical padmux drive strength for OMAP4460 is around 100uA, min is
> around 50uA. meanwhile as Documentation/gpio.txt generically states,
> the buffers driving at 1.8v on OMAP4460 could be around 6mA or upto
> 8mA. Again, these depend on the specific pin in discussion and Data
> manual explain is larger detail
> 
> Lower current is fine if the switch is ok with it and risk for
> transients are reasonably safe. However, board designs generally
> assume the stronger GPIO drive strength.
> 

one additional angle before I forget - this is something we do as part
of power optimization - to identify pins which are programmed for a
pull in non-functional scenario as it has direct impact on idle power
numbers.

For example patch #3 in this series
&omap4_pmx_core {
pinctrl-0
...
	&lcd2_pins
..
}
&lcd2_pins

lcd2_pins: pinmux_lcd2_pins {
+		pinctrl-single,pins = <
+			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
+			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
+			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
+		>;

3 pins are driven around 300uA at boot, even with display OFF -> which
means wasted current that could have been optimized by hooking the pin
to the dts node corresponding to the device and used by the driver
appropriately.

Unfortunately, folks feel simplifying the driver is traditionally a
better alternative but with a 400 odd pins on a typical SoC of today,
these defaults add up and end user tends to suffer with bad overall
power numbers :(..

-- 
Regards,
Nishanth Menon

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 05:54 AM, Nishanth Menon wrote:
> On 10/25/2013 05:25 AM, Tomi Valkeinen wrote:
>> On 25/10/13 13:18, Nishanth Menon wrote:
>>
>>>>  void __init omap_4430sdp_display_init_of(void)
>>>>  {
>>>> -	int r;
>>>> -
>>>> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
>>>> -			"display_sel");
>>>> -	if (r)
>>>> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
>>>> -
>>>> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
>>>> -		"DLP POWER ON");
>>>> -	if (r)
>>>> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
>>>> -
>>>>  	omap_display_init(&sdp4430_dss_data);
>>>>  
>>>>  	platform_device_register(&sdp4430_lcd_device);
>>>>
>>> would you not be depending on the weak IO pull done using mux to drive
>>> these GPIO pins since the GPIO is not requested and held?
>>
>> Yes. Is that not enough?
> 
> It depend on what the signal draw is and io drive strength which
> varies - original intent of weak pulls were to have a non-active
> default state which are overriden by GPIOs as needed. Else we would
> not be having strong pulls here in pads.
> 
> Typical padmux drive strength for OMAP4460 is around 100uA, min is
> around 50uA. meanwhile as Documentation/gpio.txt generically states,
> the buffers driving at 1.8v on OMAP4460 could be around 6mA or upto
> 8mA. Again, these depend on the specific pin in discussion and Data
> manual explain is larger detail
> 
> Lower current is fine if the switch is ok with it and risk for
> transients are reasonably safe. However, board designs generally
> assume the stronger GPIO drive strength.
> 

one additional angle before I forget - this is something we do as part
of power optimization - to identify pins which are programmed for a
pull in non-functional scenario as it has direct impact on idle power
numbers.

For example patch #3 in this series
&omap4_pmx_core {
pinctrl-0
...
	&lcd2_pins
..
}
&lcd2_pins

lcd2_pins: pinmux_lcd2_pins {
+		pinctrl-single,pins = <
+			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
+			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
+			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
+		>;

3 pins are driven around 300uA at boot, even with display OFF -> which
means wasted current that could have been optimized by hooking the pin
to the dts node corresponding to the device and used by the driver
appropriately.

Unfortunately, folks feel simplifying the driver is traditionally a
better alternative but with a 400 odd pins on a typical SoC of today,
these defaults add up and end user tends to suffer with bad overall
power numbers :(..

-- 
Regards,
Nishanth Menon

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On 25/10/13 14:14, Nishanth Menon wrote:

> one additional angle before I forget - this is something we do as part
> of power optimization - to identify pins which are programmed for a
> pull in non-functional scenario as it has direct impact on idle power
> numbers.
> 
> For example patch #3 in this series
> &omap4_pmx_core {
> pinctrl-0
> ...
> 	&lcd2_pins
> ..
> }
> &lcd2_pins
> 
> lcd2_pins: pinmux_lcd2_pins {
> +		pinctrl-single,pins = <
> +			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
> +			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
> +			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
> +		>;
> 
> 3 pins are driven around 300uA at boot, even with display OFF -> which
> means wasted current that could have been optimized by hooking the pin
> to the dts node corresponding to the device and used by the driver
> appropriately.
> 
> Unfortunately, folks feel simplifying the driver is traditionally a
> better alternative but with a 400 odd pins on a typical SoC of today,
> these defaults add up and end user tends to suffer with bad overall
> power numbers :(..

Good point. I guess that also makes my point of having default values
for GPIOs a bit silly. Driving the GPIO high by default would be ever
worse than the mux pull-up, I believe.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

On 25/10/13 14:14, Nishanth Menon wrote:

> one additional angle before I forget - this is something we do as part
> of power optimization - to identify pins which are programmed for a
> pull in non-functional scenario as it has direct impact on idle power
> numbers.
> 
> For example patch #3 in this series
> &omap4_pmx_core {
> pinctrl-0
> ...
> 	&lcd2_pins
> ..
> }
> &lcd2_pins
> 
> lcd2_pins: pinmux_lcd2_pins {
> +		pinctrl-single,pins = <
> +			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
> +			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
> +			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
> +		>;
> 
> 3 pins are driven around 300uA at boot, even with display OFF -> which
> means wasted current that could have been optimized by hooking the pin
> to the dts node corresponding to the device and used by the driver
> appropriately.
> 
> Unfortunately, folks feel simplifying the driver is traditionally a
> better alternative but with a 400 odd pins on a typical SoC of today,
> these defaults add up and end user tends to suffer with bad overall
> power numbers :(..

Good point. I guess that also makes my point of having default values
for GPIOs a bit silly. Driving the GPIO high by default would be ever
worse than the mux pull-up, I believe.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/f57a8993/attachment-0001.sig>

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 06:13 AM, Tomi Valkeinen wrote:
> On 25/10/13 13:54, Nishanth Menon wrote:

[..]
> 
>>>> Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
>>>> binding to map to the right GPIO and drive it using the GPIO module?
>>>
>>> Hmm, what do you mean?
>>>
>>> I do mux the pins to gpios, but there's nothing in the kernel that would
>>> use those gpios. That's why we had the hack above, but I'd love to get
>>> rid of it.
>>>
>>> Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts?
>>>
>>> If things were perfect, we probably would have a driver for the "switch"
>>> part. I have no idea what kind of driver that would be, though, so at
>>> the moment we've just gone with the use-LCD2-by-default route.
>>
>> I meant you could, in theory provide the gpio numbers and pull
>> directions in dts and allow the init to drive them as needed.
>>
>> Something like:
>> drivers/i2c/busses/i2c-gpio.c as a reference and use
>> of_get_named_gpio/of_get_gpio to pick themup..
> 
> I'm still not quite following... What init are you referring to?
> 
> The problem here is that the gpios don't really belong to anyone in the
> kernel, as we don't have a driver for the switch.
> 
> Or did you mean that we'd still have the code in dss-common.c, but just
> get the gpio numbers from the .dts instead? That makes sense, although
> I'd want to get rid of that code altogether.
> 
> Should we have support in the gpio-controller to define default values
> for gpios? I don't think we can rely on the boot loader to set things
> correctly.
> 

I am unfortunately, not in a position to know how you plan to
architect dss_common or the various panels associated with it. if you
model these as panels and a generic driver which controls the panel
could request and control pins and gpios as needed I suppose.

gpio controller cannot drive default pull direction, that is the job
of the driver using the gpio.

Simplest example that I can think of to use to point as reference is [1]

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/leds/leds-gpio.c#n173
-- 
Regards,
Nishanth Menon

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 06:13 AM, Tomi Valkeinen wrote:
> On 25/10/13 13:54, Nishanth Menon wrote:

[..]
> 
>>>> Could we not use Documentation/devicetree/bindings/gpio/gpio.txt
>>>> binding to map to the right GPIO and drive it using the GPIO module?
>>>
>>> Hmm, what do you mean?
>>>
>>> I do mux the pins to gpios, but there's nothing in the kernel that would
>>> use those gpios. That's why we had the hack above, but I'd love to get
>>> rid of it.
>>>
>>> Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts?
>>>
>>> If things were perfect, we probably would have a driver for the "switch"
>>> part. I have no idea what kind of driver that would be, though, so at
>>> the moment we've just gone with the use-LCD2-by-default route.
>>
>> I meant you could, in theory provide the gpio numbers and pull
>> directions in dts and allow the init to drive them as needed.
>>
>> Something like:
>> drivers/i2c/busses/i2c-gpio.c as a reference and use
>> of_get_named_gpio/of_get_gpio to pick themup..
> 
> I'm still not quite following... What init are you referring to?
> 
> The problem here is that the gpios don't really belong to anyone in the
> kernel, as we don't have a driver for the switch.
> 
> Or did you mean that we'd still have the code in dss-common.c, but just
> get the gpio numbers from the .dts instead? That makes sense, although
> I'd want to get rid of that code altogether.
> 
> Should we have support in the gpio-controller to define default values
> for gpios? I don't think we can rely on the boot loader to set things
> correctly.
> 

I am unfortunately, not in a position to know how you plan to
architect dss_common or the various panels associated with it. if you
model these as panels and a generic driver which controls the panel
could request and control pins and gpios as needed I suppose.

gpio controller cannot drive default pull direction, that is the job
of the driver using the gpio.

Simplest example that I can think of to use to point as reference is [1]

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/leds/leds-gpio.c#n173
-- 
Regards,
Nishanth Menon

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

On 25/10/13 14:21, Nishanth Menon wrote:

>> The problem here is that the gpios don't really belong to anyone in the
>> kernel, as we don't have a driver for the switch.
>>
>> Or did you mean that we'd still have the code in dss-common.c, but just
>> get the gpio numbers from the .dts instead? That makes sense, although
>> I'd want to get rid of that code altogether.
>>
>> Should we have support in the gpio-controller to define default values
>> for gpios? I don't think we can rely on the boot loader to set things
>> correctly.
>>
> 
> I am unfortunately, not in a position to know how you plan to
> architect dss_common or the various panels associated with it. if you

The dss-common.c is just a hack, needed during the transition to DT.
It's supposed to go away as soon as we have proper DT support for DSS.

In this case it has just been a convenient place to set the gpios at
boot time. The gpios are not touched after that.

> model these as panels and a generic driver which controls the panel
> could request and control pins and gpios as needed I suppose.
> 
> gpio controller cannot drive default pull direction, that is the job
> of the driver using the gpio.

I agree. But what to do when there is no driver that uses the gpio, but
the gpio still affects the drivers? That's more or less the situation here.

The SDP board has an LCD and a PicoDLP projector, and the board
designers have shared resources between those, meaning only one can be
used at a time.

Having the GPIO pulled down means that LCD2 won't have backlight
(although the gpio doesn't actually enable the backlight, it just
handles the routing if I'm not mistaken) , but PicoDLP will have
something (parallel video datalines, if I recall right).

I can't add that GPIO to either the LCD driver or the PicoDLP driver, as
it's not a property of either of them.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

On 25/10/13 14:21, Nishanth Menon wrote:

>> The problem here is that the gpios don't really belong to anyone in the
>> kernel, as we don't have a driver for the switch.
>>
>> Or did you mean that we'd still have the code in dss-common.c, but just
>> get the gpio numbers from the .dts instead? That makes sense, although
>> I'd want to get rid of that code altogether.
>>
>> Should we have support in the gpio-controller to define default values
>> for gpios? I don't think we can rely on the boot loader to set things
>> correctly.
>>
> 
> I am unfortunately, not in a position to know how you plan to
> architect dss_common or the various panels associated with it. if you

The dss-common.c is just a hack, needed during the transition to DT.
It's supposed to go away as soon as we have proper DT support for DSS.

In this case it has just been a convenient place to set the gpios at
boot time. The gpios are not touched after that.

> model these as panels and a generic driver which controls the panel
> could request and control pins and gpios as needed I suppose.
> 
> gpio controller cannot drive default pull direction, that is the job
> of the driver using the gpio.

I agree. But what to do when there is no driver that uses the gpio, but
the gpio still affects the drivers? That's more or less the situation here.

The SDP board has an LCD and a PicoDLP projector, and the board
designers have shared resources between those, meaning only one can be
used at a time.

Having the GPIO pulled down means that LCD2 won't have backlight
(although the gpio doesn't actually enable the backlight, it just
handles the routing if I'm not mistaken) , but PicoDLP will have
something (parallel video datalines, if I recall right).

I can't add that GPIO to either the LCD driver or the PicoDLP driver, as
it's not a property of either of them.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/319ae9e2/attachment.sig>

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On 25/10/13 14:14, Nishanth Menon wrote:

> lcd2_pins: pinmux_lcd2_pins {
> +		pinctrl-single,pins = <
> +			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
> +			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
> +			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
> +		>;
> 
> 3 pins are driven around 300uA at boot, even with display OFF -> which
> means wasted current that could have been optimized by hooking the pin
> to the dts node corresponding to the device and used by the driver
> appropriately.

One more clarification question.

The gpio 40 is used to enable powers for the picodlp. Shouldn't that one
have a pinctrl pull-down in any case? If it's left floating, and the
driver is not compiled in or doesn't start, the powers could get enabled
depending on sunspot, right?

And I guess the same goes for all gpios used to enable something.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Tomi Valkeinen]

On 25/10/13 14:14, Nishanth Menon wrote:

> lcd2_pins: pinmux_lcd2_pins {
> +		pinctrl-single,pins = <
> +			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
> +			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
> +			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
> +		>;
> 
> 3 pins are driven around 300uA at boot, even with display OFF -> which
> means wasted current that could have been optimized by hooking the pin
> to the dts node corresponding to the device and used by the driver
> appropriately.

One more clarification question.

The gpio 40 is used to enable powers for the picodlp. Shouldn't that one
have a pinctrl pull-down in any case? If it's left floating, and the
driver is not compiled in or doesn't start, the powers could get enabled
depending on sunspot, right?

And I guess the same goes for all gpios used to enable something.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/9be3961c/attachment-0001.sig>

Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 06:46 AM, Tomi Valkeinen wrote:
> On 25/10/13 14:14, Nishanth Menon wrote:
> 
>> lcd2_pins: pinmux_lcd2_pins {
>> +		pinctrl-single,pins = <
>> +			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
>> +			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
>> +			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
>> +		>;
>>
>> 3 pins are driven around 300uA at boot, even with display OFF -> which
>> means wasted current that could have been optimized by hooking the pin
>> to the dts node corresponding to the device and used by the driver
>> appropriately.
> 
> One more clarification question.
> 
> The gpio 40 is used to enable powers for the picodlp. Shouldn't that one
> have a pinctrl pull-down in any case? If it's left floating, and the
> driver is not compiled in or doesn't start, the powers could get enabled
> depending on sunspot, right?
> 
> And I guess the same goes for all gpios used to enable something.
> 
Fair question. The selection of pull up, gpio control needs to be
balanced.
if the peripheral in question has a regulator controlled supply, none
of the pins would matter - driver can adequately sequence this to
ensure there are no weird side-effects. in such a scenario, i'd have a
default MODE3 with no pulls, sequence as follows:
a) control gpio to required default level (disabled)
b) control regulator
c) set GPIO to enable.

if the peripheral in question is always on and controlled with just a
enable pin, it is safer to keep the pin muxed with weak pull.

If the enable has no real functional impact without setting another
pin (say power_on), or if any transient glitches on the line has no
functional impact, I might go with no pull configuration.


It all depends on the schematics and peripherals involved w.r.t how
you'd optimally select the configuration.

-- 
Regards,
Nishanth Menon

[PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common

[Nishanth Menon]

On 10/25/2013 06:46 AM, Tomi Valkeinen wrote:
> On 25/10/13 14:14, Nishanth Menon wrote:
> 
>> lcd2_pins: pinmux_lcd2_pins {
>> +		pinctrl-single,pins = <
>> +			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
>> +			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
>> +			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
>> +		>;
>>
>> 3 pins are driven around 300uA at boot, even with display OFF -> which
>> means wasted current that could have been optimized by hooking the pin
>> to the dts node corresponding to the device and used by the driver
>> appropriately.
> 
> One more clarification question.
> 
> The gpio 40 is used to enable powers for the picodlp. Shouldn't that one
> have a pinctrl pull-down in any case? If it's left floating, and the
> driver is not compiled in or doesn't start, the powers could get enabled
> depending on sunspot, right?
> 
> And I guess the same goes for all gpios used to enable something.
> 
Fair question. The selection of pull up, gpio control needs to be
balanced.
if the peripheral in question has a regulator controlled supply, none
of the pins would matter - driver can adequately sequence this to
ensure there are no weird side-effects. in such a scenario, i'd have a
default MODE3 with no pulls, sequence as follows:
a) control gpio to required default level (disabled)
b) control regulator
c) set GPIO to enable.

if the peripheral in question is always on and controlled with just a
enable pin, it is safer to keep the pin muxed with weak pull.

If the enable has no real functional impact without setting another
pin (say power_on), or if any transient glitches on the line has no
functional impact, I might go with no pull configuration.


It all depends on the schematics and peripherals involved w.r.t how
you'd optimally select the configuration.

-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3129 bytes --]

Hi Tony,

On 25/10/13 13:07, Tomi Valkeinen wrote:
> New u-boot versions no longer set the pinmuxing for Panda's DPI output,
> and the muxing has to be done in the .dts file.
> 
> Add pinmuxing for DPI and TFP410. Without these, the DVI output on Panda
> does not work with recent u-boot.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The two latter patches in this series needs more work and can be
dropped, but this one should be applied to make Panda work properly with
new u-boots.

 Tomi

> ---
>  arch/arm/boot/dts/omap4-panda-common.dtsi | 43 +++++++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index faa95b5..fcb8856 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -129,6 +129,8 @@
>  			&twl6040_pins
>  			&mcpdm_pins
>  			&mcbsp1_pins
> +			&dss_dpi_pins
> +			&tfp410_pins
>  			&dss_hdmi_pins
>  			&tpd12s015_pins
>  			&hsusbb1_pins
> @@ -166,6 +168,47 @@
>  		>;
>  	};
>  
> +	dss_dpi_pins: pinmux_dss_dpi_pins {
> +		pinctrl-single,pins = <
> +			0x122 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data23 */
> +			0x124 (PIN_OUTPUT | MUX_MODE5) 	/* dispc2_data22 */
> +			0x126 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data21 */
> +			0x128 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data20 */
> +			0x12a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data19 */
> +			0x12c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data18 */
> +			0x12e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data15 */
> +			0x130 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data14 */
> +			0x132 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data13 */
> +			0x134 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data12 */
> +			0x136 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data11 */
> +
> +			0x174 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data10 */
> +			0x176 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data9 */
> +			0x178 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data16 */
> +			0x17a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data17 */
> +			0x17c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_hsync */
> +			0x17e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_pclk */
> +			0x180 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_vsync */
> +			0x182 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_de */
> +			0x184 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data8 */
> +			0x186 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data7 */
> +			0x188 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data6 */
> +			0x18a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data5 */
> +			0x18c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data4 */
> +			0x18e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data3 */
> +
> +			0x190 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data2 */
> +			0x192 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data1 */
> +			0x194 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data0 */
> +		>;
> +	};
> +
> +	tfp410_pins: pinmux_tfp410_pins {
> +		pinctrl-single,pins = <
> +			0x144 (PIN_OUTPUT | MUX_MODE3)	/* gpio_0 */
> +		>;
> +	};
> +
>  	dss_hdmi_pins: pinmux_dss_hdmi_pins {
>  		pinctrl-single,pins = <
>  			0x5a (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_cec.hdmi_cec */
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing

[Tomi Valkeinen]

Hi Tony,

On 25/10/13 13:07, Tomi Valkeinen wrote:
> New u-boot versions no longer set the pinmuxing for Panda's DPI output,
> and the muxing has to be done in the .dts file.
> 
> Add pinmuxing for DPI and TFP410. Without these, the DVI output on Panda
> does not work with recent u-boot.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The two latter patches in this series needs more work and can be
dropped, but this one should be applied to make Panda work properly with
new u-boots.

 Tomi

> ---
>  arch/arm/boot/dts/omap4-panda-common.dtsi | 43 +++++++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index faa95b5..fcb8856 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -129,6 +129,8 @@
>  			&twl6040_pins
>  			&mcpdm_pins
>  			&mcbsp1_pins
> +			&dss_dpi_pins
> +			&tfp410_pins
>  			&dss_hdmi_pins
>  			&tpd12s015_pins
>  			&hsusbb1_pins
> @@ -166,6 +168,47 @@
>  		>;
>  	};
>  
> +	dss_dpi_pins: pinmux_dss_dpi_pins {
> +		pinctrl-single,pins = <
> +			0x122 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data23 */
> +			0x124 (PIN_OUTPUT | MUX_MODE5) 	/* dispc2_data22 */
> +			0x126 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data21 */
> +			0x128 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data20 */
> +			0x12a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data19 */
> +			0x12c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data18 */
> +			0x12e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data15 */
> +			0x130 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data14 */
> +			0x132 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data13 */
> +			0x134 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data12 */
> +			0x136 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data11 */
> +
> +			0x174 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data10 */
> +			0x176 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data9 */
> +			0x178 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data16 */
> +			0x17a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data17 */
> +			0x17c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_hsync */
> +			0x17e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_pclk */
> +			0x180 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_vsync */
> +			0x182 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_de */
> +			0x184 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data8 */
> +			0x186 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data7 */
> +			0x188 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data6 */
> +			0x18a (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data5 */
> +			0x18c (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data4 */
> +			0x18e (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data3 */
> +
> +			0x190 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data2 */
> +			0x192 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data1 */
> +			0x194 (PIN_OUTPUT | MUX_MODE5)	/* dispc2_data0 */
> +		>;
> +	};
> +
> +	tfp410_pins: pinmux_tfp410_pins {
> +		pinctrl-single,pins = <
> +			0x144 (PIN_OUTPUT | MUX_MODE3)	/* gpio_0 */
> +		>;
> +	};
> +
>  	dss_hdmi_pins: pinmux_dss_hdmi_pins {
>  		pinctrl-single,pins = <
>  			0x5a (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_cec.hdmi_cec */
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131029/e5ad093b/attachment.sig>

Re: [PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131029 03:16]:
> Hi Tony,
> 
> On 25/10/13 13:07, Tomi Valkeinen wrote:
> > New u-boot versions no longer set the pinmuxing for Panda's DPI output,
> > and the muxing has to be done in the .dts file.
> > 
> > Add pinmuxing for DPI and TFP410. Without these, the DVI output on Panda
> > does not work with recent u-boot.
> > 
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> 
> The two latter patches in this series needs more work and can be
> dropped, but this one should be applied to make Panda work properly with
> new u-boots.

OK I'll pick this patch into omap-for-v3.13/dt.

Regards,

Tony

[PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131029 03:16]:
> Hi Tony,
> 
> On 25/10/13 13:07, Tomi Valkeinen wrote:
> > New u-boot versions no longer set the pinmuxing for Panda's DPI output,
> > and the muxing has to be done in the .dts file.
> > 
> > Add pinmuxing for DPI and TFP410. Without these, the DVI output on Panda
> > does not work with recent u-boot.
> > 
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> 
> The two latter patches in this series needs more work and can be
> dropped, but this one should be applied to make Panda work properly with
> new u-boots.

OK I'll pick this patch into omap-for-v3.13/dt.

Regards,

Tony