[PATCH 00/11]: add remaining support for IGEP boards

[PATCH 00/11]: add remaining support for IGEP boards

[Javier Martinez Canillas]

In order to make mach-omap2 Device Tree only the board file for
IGEP boards was removed even when support for wifi and display
was still not supported by its DTS.

This patch-set adds support for these remaining peripherals and
also adds support for USB, HDMI and user LED for the am33xx SoC
based IGEP Aquila board.

The patch-set is composed of the following patches:

Enric Balletbo i Serra (7):
      ARM: dts: omap3-igep: Fix bus-width for mmc1.
      ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO.
      ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.
      ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display
      ARM: dts: AM33XX BASE0033: add pinmux and user led support.
      ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support.
      ARM: dts: AM33XX IGEP0033: add USB support.

Javier Martinez Canillas (4):
      ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices
      ARM: dts: omap3-igep0020: Add pinmuxing for DVI output
      ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus
      OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

Tony,

Most of these patches are just DTS changes so they have to be picked
by Benoit although there are patches that should go to different trees.

[PATCH 10/11] ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus

have to go through your tree and

[PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

should be picked by Tomi Valkeinen.

Since we have removed the board file for IGEP boards I think these
can be considered as regression fixes for 3.13 although I don't mind
if you prefer to wait for 3.14.

Thanks a lot and best regards,
Javier

[PATCH 01/11] ARM: dts: omap3-igep: Fix bus-width for mmc1.

[Javier Martinez Canillas]

From: Enric Balletbo i Serra <eballetbo@gmail.com>

Both, IGEPv2 and IGEP COM MODULE have a bus-width of 4 not 8, so fix this and
do not mux data pins from mmc1_data4 to mmc1_data7.

Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
---
 arch/arm/boot/dts/omap3-igep.dtsi | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index ba1e58b..d4fecce 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -65,10 +65,6 @@
 			0x11a (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat1.sdmmc1_dat1 */
 			0x11c (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat2.sdmmc1_dat2 */
 			0x11e (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat3.sdmmc1_dat3 */
-			0x120 (PIN_INPUT | MUX_MODE0)		/* sdmmc1_dat4.sdmmc1_dat4 */
-			0x122 (PIN_INPUT | MUX_MODE0)		/* sdmmc1_dat5.sdmmc1_dat5 */
-			0x124 (PIN_INPUT | MUX_MODE0)		/* sdmmc1_dat6.sdmmc1_dat6 */
-			0x126 (PIN_INPUT | MUX_MODE0)		/* sdmmc1_dat7.sdmmc1_dat7 */
 		>;
 	};
 
@@ -114,7 +110,7 @@
       pinctrl-0 = <&mmc1_pins>;
       vmmc-supply = <&vmmc1>;
       vmmc_aux-supply = <&vsim>;
-      bus-width = <8>;
+      bus-width = <4>;
 };
 
 &mmc2 {
-- 
1.8.4.2

[PATCH 02/11] ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO.

[Javier Martinez Canillas]

From: Enric Balletbo i Serra <eballetbo@gmail.com>

The LBEE1USJYC is a WiFi/BT combo module used on OMAP3-based IGEP boards. In
both cases, IGEPv2 Rev. C and IGEP COM MODULE, the module is connected using
the same MMC interface and uses the same GPIOs.

Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
---
 arch/arm/boot/dts/omap3-igep.dtsi | 45 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index d4fecce..b3517b2 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -24,6 +24,25 @@
 		ti,mcbsp = <&mcbsp2>;
 		ti,codec = <&twl_audio>;
 	};
+
+	vdd33: regulator-vdd33 {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd33";
+		regulator-always-on;
+	};
+
+	lbee1usjyc_vmmc: lbee1usjyc_vmmc {
+		pinctrl-names = "default";
+		pinctrl-0 = <&lbee1usjyc_pins>;
+		compatible = "regulator-fixed";
+		regulator-name = "regulator-lbee1usjyc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio5 10 GPIO_ACTIVE_HIGH>;	/* gpio_138 WIFI_PDN */
+		startup-delay-us = <10000>;
+		enable-active-high;
+		vin-supply = <&vdd33>;
+	};
 };
 
 &omap3_pmx_core {
@@ -48,6 +67,15 @@
 		>;
 	};
 
+	/* WiFi/BT combo */
+	lbee1usjyc_pins: pinmux_lbee1usjyc_pins {
+		pinctrl-single,pins = <
+			0x136 (PIN_OUTPUT | MUX_MODE4)	/* sdmmc2_dat5.gpio_137 */
+			0x138 (PIN_OUTPUT | MUX_MODE4)	/* sdmmc2_dat6.gpio_138 */
+			0x13a (PIN_OUTPUT | MUX_MODE4)	/* sdmmc2_dat7.gpio_139 */
+		>;
+	};
+
 	mcbsp2_pins: pinmux_mcbsp2_pins {
 		pinctrl-single,pins = <
 			0x10c (PIN_INPUT | MUX_MODE0)		/* mcbsp2_fsx.mcbsp2_fsx */
@@ -68,6 +96,17 @@
 		>;
 	};
 
+	mmc2_pins: pinmux_mmc2_pins {
+		pinctrl-single,pins = <
+			0x128 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc2_clk.sdmmc2_clk */
+			0x12a (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc2_cmd.sdmmc2_cmd */
+			0x12c (PIN_INPUT_PULLUP | MUX_MODE0) 	/* sdmmc2_dat0.sdmmc2_dat0 */
+			0x12e (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc2_dat1.sdmmc2_dat1 */
+			0x130 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc2_dat2.sdmmc2_dat2 */
+			0x132 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc2_dat3.sdmmc2_dat3 */
+		>;
+	};
+
 	smsc911x_pins: pinmux_smsc911x_pins {
 		pinctrl-single,pins = <
 			0x1a2 (PIN_INPUT | MUX_MODE4)		/* mcspi1_cs2.gpio_176 */
@@ -114,7 +153,11 @@
 };
 
 &mmc2 {
-	status = "disabled";
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins>;
+	vmmc-supply = <&lbee1usjyc_vmmc>;
+	bus-width = <4>;
+	non-removable;
 };
 
 &mmc3 {
-- 
1.8.4.2

[PATCH 03/11] ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.

[Javier Martinez Canillas]

From: Enric Balletbo i Serra <eballetbo@gmail.com>

Most of the boards are using the TI AM/DM37x processor, there is only a small
quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
omap36xx.dtsi include instead of omap34xx.dtsi include.

To avoid confusion we have added to the model the (TI AM/DM37x) comment.

Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
---
 arch/arm/boot/dts/omap3-igep.dtsi    | 4 ++--
 arch/arm/boot/dts/omap3-igep0020.dts | 4 ++--
 arch/arm/boot/dts/omap3-igep0030.dts | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index b3517b2..e4c8769 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for IGEP Technology devices
+ * Common device tree for IGEP boards based on AM/DM37x
  *
  * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
  * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
@@ -10,7 +10,7 @@
  */
 /dts-v1/;
 
-#include "omap34xx.dtsi"
+#include "omap36xx.dtsi"
 
 / {
 	memory {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index d5cc792..33ce123 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for IGEPv2 board
+ * Device Tree Source for IGEPv2 Rev. (TI OMAP AM/DM37x)
  *
  * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
  * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
@@ -13,7 +13,7 @@
 #include "omap-gpmc-smsc911x.dtsi"
 
 / {
-	model = "IGEPv2";
+	model = "IGEPv2 (TI OMAP AM/DM37x)";
 	compatible = "isee,omap3-igep0020", "ti,omap3";
 
 	leds {
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
index 525e6d9..02a23f8 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for IGEP COM Module
+ * Device Tree Source for IGEP COM MODULE (TI OMAP AM/DM37x)
  *
  * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
  * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
@@ -12,7 +12,7 @@
 #include "omap3-igep.dtsi"
 
 / {
-	model = "IGEP COM Module";
+	model = "IGEP COM MODULE (TI OMAP AM/DM37x)";
 	compatible = "isee,omap3-igep0030", "ti,omap3";
 
 	leds {
-- 
1.8.4.2

[PATCH 04/11] ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices

[Javier Martinez Canillas]

Add pin muxing support for IGEP boards i2c controllers.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/omap3-igep.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index e4c8769..165aaf7 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -113,10 +113,33 @@
 		>;
 	};
 
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			0x18a (PIN_INPUT | MUX_MODE0)   /* i2c1_scl.i2c1_scl */
+			0x18c (PIN_INPUT | MUX_MODE0)   /* i2c1_sda.i2c1_sda */
+		>;
+	};
+
+	i2c2_pins: pinmux_i2c2_pins {
+		pinctrl-single,pins = <
+			0x18e (PIN_INPUT | MUX_MODE0)   /* i2c2_scl.i2c2_scl */
+			0x190 (PIN_INPUT | MUX_MODE0)   /* i2c2_sda.i2c2_sda */
+		>;
+	};
+
+	i2c3_pins: pinmux_i2c3_pins {
+		pinctrl-single,pins = <
+			0x192 (PIN_INPUT | MUX_MODE0)   /* i2c3_scl.i2c3_scl */
+			0x194 (PIN_INPUT | MUX_MODE0)   /* i2c3_sda.i2c3_sda */
+		>;
+	};
+
 	leds_pins: pinmux_leds_pins { };
 };
 
 &i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
 	clock-frequency = <2600000>;
 
 	twl: twl@48 {
@@ -136,9 +159,16 @@
 #include "twl4030_omap3.dtsi"
 
 &i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins>;
 	clock-frequency = <400000>;
 };
 
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c3_pins>;
+};
+
 &mcbsp2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mcbsp2_pins>;
-- 
1.8.4.2

[PATCH 05/11] ARM: dts: omap3-igep0020: Add pinmuxing for DVI output

[Javier Martinez Canillas]

The IGEPv2 has a TFP410 DPI-to-DVI encoder attached to OMAP's
Display SubSystem (DSS).

Add mux setup for DSS pins and also for the GPIO 170 pin that
is used to ensure that the DVI-D is powered down on power up.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/omap3-igep0020.dts | 41 ++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index 33ce123..b9a9e17 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -67,6 +67,8 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <
 		&hsusbb1_pins
+		&tfp410_pins
+		&dss_pins
 	>;
 
 	hsusbb1_pins: pinmux_hsusbb1_pins {
@@ -85,6 +87,45 @@
 			0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d7.hsusb1_data3 */
 		>;
 	};
+
+	tfp410_pins: tfp410_dvi_pins {
+		pinctrl-single,pins = <
+			0x196 (PIN_OUTPUT | MUX_MODE4)   /* hdq_sio.gpio_170 */
+		>;
+	};
+
+	dss_pins: pinmux_dss_dvi_pins {
+		pinctrl-single,pins = <
+			0x0a4 (PIN_OUTPUT | MUX_MODE0)   /* dss_pclk.dss_pclk */
+			0x0a6 (PIN_OUTPUT | MUX_MODE0)   /* dss_hsync.dss_hsync */
+			0x0a8 (PIN_OUTPUT | MUX_MODE0)   /* dss_vsync.dss_vsync */
+			0x0aa (PIN_OUTPUT | MUX_MODE0)   /* dss_acbias.dss_acbias */
+			0x0ac (PIN_OUTPUT | MUX_MODE0)   /* dss_data0.dss_data0 */
+			0x0ae (PIN_OUTPUT | MUX_MODE0)   /* dss_data1.dss_data1 */
+			0x0b0 (PIN_OUTPUT | MUX_MODE0)   /* dss_data2.dss_data2 */
+			0x0b2 (PIN_OUTPUT | MUX_MODE0)   /* dss_data3.dss_data3 */
+			0x0b4 (PIN_OUTPUT | MUX_MODE0)   /* dss_data4.dss_data4 */
+			0x0b6 (PIN_OUTPUT | MUX_MODE0)   /* dss_data5.dss_data5 */
+			0x0b8 (PIN_OUTPUT | MUX_MODE0)   /* dss_data6.dss_data6 */
+			0x0ba (PIN_OUTPUT | MUX_MODE0)   /* dss_data7.dss_data7 */
+			0x0bc (PIN_OUTPUT | MUX_MODE0)   /* dss_data8.dss_data8 */
+			0x0be (PIN_OUTPUT | MUX_MODE0)   /* dss_data9.dss_data9 */
+			0x0c0 (PIN_OUTPUT | MUX_MODE0)   /* dss_data10.dss_data10 */
+			0x0c2 (PIN_OUTPUT | MUX_MODE0)   /* dss_data11.dss_data11 */
+			0x0c4 (PIN_OUTPUT | MUX_MODE0)   /* dss_data12.dss_data12 */
+			0x0c6 (PIN_OUTPUT | MUX_MODE0)   /* dss_data13.dss_data13 */
+			0x0c8 (PIN_OUTPUT | MUX_MODE0)   /* dss_data14.dss_data14 */
+			0x0ca (PIN_OUTPUT | MUX_MODE0)   /* dss_data15.dss_data15 */
+			0x0cc (PIN_OUTPUT | MUX_MODE0)   /* dss_data16.dss_data16 */
+			0x0ce (PIN_OUTPUT | MUX_MODE0)   /* dss_data17.dss_data17 */
+			0x0d0 (PIN_OUTPUT | MUX_MODE0)   /* dss_data18.dss_data18 */
+			0x0d2 (PIN_OUTPUT | MUX_MODE0)   /* dss_data19.dss_data19 */
+			0x0d4 (PIN_OUTPUT | MUX_MODE0)   /* dss_data20.dss_data20 */
+			0x0d6 (PIN_OUTPUT | MUX_MODE0)   /* dss_data21.dss_data21 */
+			0x0d8 (PIN_OUTPUT | MUX_MODE0)   /* dss_data22.dss_data22 */
+			0x0da (PIN_OUTPUT | MUX_MODE0)   /* dss_data23.dss_data23 */
+		>;
+	};
 };
 
 &leds_pins {
-- 
1.8.4.2

[PATCH 06/11] ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display

[Javier Martinez Canillas]

From: Enric Balletbo i Serra <eballetbo@gmail.com>

Enable the hdmi output and the LCD Controller on IGEP AQUILA. Also
configure the correct pinmux for output of video data from the SoC
to the HDMI encoder.

Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
---
 arch/arm/boot/dts/am335x-base0033.dts | 47 +++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-base0033.dts b/arch/arm/boot/dts/am335x-base0033.dts
index b4f95c2..3a97613 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -13,4 +13,51 @@
 / {
 	model = "IGEP COM AM335x on AQUILA Expansion";
 	compatible = "isee,am335x-base0033", "isee,am335x-igep0033", "ti,am33xx";
+
+	hdmi {
+		compatible = "ti,tilcdc,slave";
+		i2c = <&i2c0>;
+		pinctrl-names = "default", "off";
+		pinctrl-0 = <&nxp_hdmi_pins>;
+		pinctrl-1 = <&nxp_hdmi_off_pins>;
+		status = "okay";
+	};
+};
+
+&am33xx_pinmux {
+	nxp_hdmi_pins: pinmux_nxp_hdmi_pins {
+		pinctrl-single,pins = <
+			0x1b0 (PIN_OUTPUT | MUX_MODE3)	/* xdma_event_intr0.clkout1 */
+			0xa0 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data0 */
+			0xa4 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data1 */
+			0xa8 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data2 */
+			0xac (PIN_OUTPUT | MUX_MODE0)	/* lcd_data3 */
+			0xb0 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data4 */
+			0xb4 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data5 */
+			0xb8 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data6 */
+			0xbc (PIN_OUTPUT | MUX_MODE0)	/* lcd_data7 */
+			0xc0 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data8 */
+			0xc4 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data9 */
+			0xc8 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data10 */
+			0xcc (PIN_OUTPUT | MUX_MODE0)	/* lcd_data11 */
+			0xd0 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data12 */
+			0xd4 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data13 */
+			0xd8 (PIN_OUTPUT | MUX_MODE0)	/* lcd_data14 */
+			0xdc (PIN_OUTPUT | MUX_MODE0)	/* lcd_data15 */
+			0xe0 (PIN_OUTPUT | MUX_MODE0)	/* lcd_vsync */
+			0xe4 (PIN_OUTPUT | MUX_MODE0)	/* lcd_hsync */
+			0xe8 (PIN_OUTPUT | MUX_MODE0)	/* lcd_pclk */
+			0xec (PIN_OUTPUT | MUX_MODE0)	/* lcd_ac_bias_en */
+		>;
+	};
+	nxp_hdmi_off_pins: pinmux_nxp_hdmi_off_pins {
+		pinctrl-single,pins = <
+			0x1b0 (PIN_OUTPUT | MUX_MODE3)	/* xdma_event_intr0.clkout1 */
+		>;
+	};
 };
+
+&lcdc {
+	status = "okay";
+};
+
-- 
1.8.4.2

[PATCH 07/11] ARM: dts: AM33XX BASE0033: add pinmux and user led support.

[Javier Martinez Canillas]

From: Enric Balletbo i Serra <eballetbo@iseebcn.com>

Enable the user leds on the IGEP AQUILA EXPANSION. The has two leds,
one green and one red, that are controllable by software.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
---
 arch/arm/boot/dts/am335x-base0033.dts | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-base0033.dts b/arch/arm/boot/dts/am335x-base0033.dts
index 3a97613..2878024 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -22,6 +22,25 @@
 		pinctrl-1 = <&nxp_hdmi_off_pins>;
 		status = "okay";
 	};
+
+	leds_base {
+		pinctrl-names = "default";
+		pinctrl-0 = <&leds_base_pins>;
+
+		compatible = "gpio-leds";
+
+		led@0 {
+			label = "base:red:user";
+			gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;	/* gpio1_21 */
+			default-state = "off";
+		};
+
+		led@1 {
+			label = "base:green:user";
+			gpios = <&gpio2 0 GPIO_ACTIVE_HIGH>;	/* gpio2_0 */
+			default-state = "off";
+		};
+	};
 };
 
 &am33xx_pinmux {
@@ -55,6 +74,13 @@
 			0x1b0 (PIN_OUTPUT | MUX_MODE3)	/* xdma_event_intr0.clkout1 */
 		>;
 	};
+
+	leds_base_pins: pinmux_leds_base_pins {
+		pinctrl-single,pins = <
+			0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* gpmc_a5.gpio1_21 */
+			0x88 (PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* gpmc_csn3.gpio2_0 */
+		>;
+	};
 };
 
 &lcdc {
-- 
1.8.4.2

[PATCH 08/11] ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support.

[Javier Martinez Canillas]

From: Enric Balletbo i Serra <eballetbo@iseebcn.com>

The IGEP AQUILA EXPANSION has a 32KBit EEPROM for user data storage.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
---
 arch/arm/boot/dts/am335x-base0033.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-base0033.dts b/arch/arm/boot/dts/am335x-base0033.dts
index 2878024..a76ea11 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -87,3 +87,10 @@
 	status = "okay";
 };
 
+&i2c0 {
+	eeprom: eeprom@50 {
+		compatible = "at,24c256";
+		reg = <0x50>;
+	};
+};
+
-- 
1.8.4.2

[PATCH 09/11] ARM: dts: AM33XX IGEP0033: add USB support.

[Javier Martinez Canillas]

From: Enric Balletbo i Serra <eballetbo@iseebcn.com>

Add node to support the USB Host and the USB OTG on the IGEP AQUILA
Processor Board.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
---
 arch/arm/boot/dts/am335x-igep0033.dtsi | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 6196244..7063311 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -199,6 +199,35 @@
 	pinctrl-0 = <&uart0_pins>;
 };
 
+&usb {
+	status = "okay";
+
+	control@44e10000 {
+		status = "okay";
+	};
+
+	usb-phy@47401300 {
+		status = "okay";
+	};
+
+	usb-phy@47401b00 {
+		status = "okay";
+	};
+
+	usb@47401000 {
+		status = "okay";
+	};
+
+	usb@47401800 {
+		status = "okay";
+		dr_mode = "host";
+	};
+
+	dma-controller@07402000  {
+		status = "okay";
+	};
+};
+
 #include "tps65910.dtsi"
 
 &tps {
-- 
1.8.4.2

[PATCH 10/11] ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus

[Javier Martinez Canillas]

IGEP's DVI connector's DDC pins are connected to OMAP's third i2c bus.

When booting with Device Trees the requested bus number is set to -1
which means that the bus number should be dynamically assigned. So the
third i2c bus has 2 has a bus number.

Since now only DT booting is supported for IGEP boards after commit
06ff74fd ("ARM: OMAP2+: remove legacy support for IGEP boards"), the
i2c bus number has to be changed.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/mach-omap2/dss-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 365bfd3..dadccc9 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -223,7 +223,7 @@ void __init omap_4430sdp_display_init_of(void)
 static struct connector_dvi_platform_data omap3_igep2_dvi_connector_pdata = {
 	.name                   = "dvi",
 	.source                 = "tfp410.0",
-	.i2c_bus_num            = 3,
+	.i2c_bus_num            = 2,
 };
 
 static struct platform_device omap3_igep2_dvi_connector_device = {
-- 
1.8.4.2

[PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

[Javier Martinez Canillas]

On Device Tree boot the VDDS_DSI regulator is not linked to
the DPI device so omapfb driver probing fails with:

[    3.186035] OMAPFB: omapfb_probe
[    3.190704] omapdss DPI error: can't get VDDS_DSI regulator
[    3.196594] omapfb omapfb: failed to connect default display
[    3.202667] omapfb omapfb: failed to init overlay connections
[    3.208892] OMAPFB: free_resources
[    3.212493] OMAPFB: free all fbmem
[    3.216735] omapfb omapfb: failed to setup omapfb

As a workaround try to use the VPLL2 regulator from twl4030 in
dpi_init_regulator() if getting the VDDS_DSI regulator fails.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/video/omap2/dss/dpi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index bd48cde..e328f0b 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -550,6 +550,11 @@ static int dpi_init_regulator(void)
 		return 0;
 
 	vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "vdds_dsi");
+
+        /* DT HACK: try VPLL2 to make omapdss work for OMAP3 IGEPv2 */
+        if (IS_ERR(vdds_dsi))
+                vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "VPLL2");
+
 	if (IS_ERR(vdds_dsi)) {
 		DSSERR("can't get VDDS_DSI regulator\n");
 		return PTR_ERR(vdds_dsi);
-- 
1.8.4.2

Re: [PATCH 00/11]: add remaining support for IGEP boards

[Tony Lindgren]

* Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 05:25]:
> In order to make mach-omap2 Device Tree only the board file for
> IGEP boards was removed even when support for wifi and display
> was still not supported by its DTS.
> 
> This patch-set adds support for these remaining peripherals and
> also adds support for USB, HDMI and user LED for the am33xx SoC
> based IGEP Aquila board.
> 
> The patch-set is composed of the following patches:
> 
> Enric Balletbo i Serra (7):
>       ARM: dts: omap3-igep: Fix bus-width for mmc1.
>       ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO.
>       ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.
>       ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display
>       ARM: dts: AM33XX BASE0033: add pinmux and user led support.
>       ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support.
>       ARM: dts: AM33XX IGEP0033: add USB support.
> 
> Javier Martinez Canillas (4):
>       ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices
>       ARM: dts: omap3-igep0020: Add pinmuxing for DVI output
>       ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus
>       OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found
> 
> Tony,
> 
> Most of these patches are just DTS changes so they have to be picked
> by Benoit although there are patches that should go to different trees.
> 
> [PATCH 10/11] ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus
> 
> have to go through your tree and

OK
 
> [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found
> 
> should be picked by Tomi Valkeinen.

That may not be needed as it can be set in the .dts file, I'll comment
on that patch.
 
> Since we have removed the board file for IGEP boards I think these
> can be considered as regression fixes for 3.13 although I don't mind
> if you prefer to wait for 3.14.

Yes I agree, let's try to fix these issues during the -rc cycle
so the earlier functionality is maintained.

Regards,

Tony

Re: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

[Tony Lindgren]

* Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 05:25]:
> On Device Tree boot the VDDS_DSI regulator is not linked to
> the DPI device so omapfb driver probing fails with:
> 
> [    3.186035] OMAPFB: omapfb_probe
> [    3.190704] omapdss DPI error: can't get VDDS_DSI regulator
> [    3.196594] omapfb omapfb: failed to connect default display
> [    3.202667] omapfb omapfb: failed to init overlay connections
> [    3.208892] OMAPFB: free_resources
> [    3.212493] OMAPFB: free all fbmem
> [    3.216735] omapfb omapfb: failed to setup omapfb
> 
> As a workaround try to use the VPLL2 regulator from twl4030 in
> dpi_init_regulator() if getting the VDDS_DSI regulator fails.

Probably makes sens to fix this in the dpi.c, but this can also be set
in the .dts file. I just set up the following in the omap3-ldp.dts file:

&vaux1 {
	/* Needed for ads7846 */
	regulator-name = "vcc";
};

&vpll2 {
	/* Needed for DSS */
	regulator-name = "vdds_dsi";
};

Regards,

Tony

 
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/video/omap2/dss/dpi.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index bd48cde..e328f0b 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -550,6 +550,11 @@ static int dpi_init_regulator(void)
>  		return 0;
>  
>  	vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "vdds_dsi");
> +
> +        /* DT HACK: try VPLL2 to make omapdss work for OMAP3 IGEPv2 */
> +        if (IS_ERR(vdds_dsi))
> +                vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "VPLL2");
> +
>  	if (IS_ERR(vdds_dsi)) {
>  		DSSERR("can't get VDDS_DSI regulator\n");
>  		return PTR_ERR(vdds_dsi);
> -- 
> 1.8.4.2
> 

Re: [PATCH 00/11]: add remaining support for IGEP boards

[Javier Martinez Canillas]

On 11/16/2013 03:16 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 05:25]:
>> In order to make mach-omap2 Device Tree only the board file for
>> IGEP boards was removed even when support for wifi and display
>> was still not supported by its DTS.
>> 
>> This patch-set adds support for these remaining peripherals and
>> also adds support for USB, HDMI and user LED for the am33xx SoC
>> based IGEP Aquila board.
>> 
>> The patch-set is composed of the following patches:
>> 
>> Enric Balletbo i Serra (7):
>>       ARM: dts: omap3-igep: Fix bus-width for mmc1.
>>       ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO.
>>       ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.
>>       ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display
>>       ARM: dts: AM33XX BASE0033: add pinmux and user led support.
>>       ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support.
>>       ARM: dts: AM33XX IGEP0033: add USB support.
>> 
>> Javier Martinez Canillas (4):
>>       ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices
>>       ARM: dts: omap3-igep0020: Add pinmuxing for DVI output
>>       ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus
>>       OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found
>> 
>> Tony,
>> 
>> Most of these patches are just DTS changes so they have to be picked
>> by Benoit although there are patches that should go to different trees.
>> 
>> [PATCH 10/11] ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus
>> 
>> have to go through your tree and
> 
> OK
>  
>> [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found
>> 
>> should be picked by Tomi Valkeinen.
> 
> That may not be needed as it can be set in the .dts file, I'll comment
> on that patch.
>  

A similar hack is made for OMAP4 on dsi_regulator_init() to use the twl6030
VCXIO regulator if vdds_dsi is not found so I thought it makes sense to do
something similar for DPI and OMAP3.

But if you prefer I can add a regulator-name = "vdds_dsi" property to vpll2 like
you did for omap3-ldp.dts

>> Since we have removed the board file for IGEP boards I think these
>> can be considered as regression fixes for 3.13 although I don't mind
>> if you prefer to wait for 3.14.
> 
> Yes I agree, let's try to fix these issues during the -rc cycle
> so the earlier functionality is maintained.
> 
> Regards,
> 
> Tony
> 

Great, so you can drop [PATCH 11/11] and I'll send a follow up patch doing the
required regulator change in omap3-igep0020.dts.

Thanks a lot and best regards,
Javier

Re: [PATCH 03/11] ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.

[Tony Lindgren]

* Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 05:25]:
> From: Enric Balletbo i Serra <eballetbo@gmail.com>
> 
> Most of the boards are using the TI AM/DM37x processor, there is only a small
> quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
> omap36xx.dtsi include instead of omap34xx.dtsi include.
> 
> To avoid confusion we have added to the model the (TI AM/DM37x) comment.

You could have omap3-igep-common.dtsi that contains most configurations
and then files including that where only the SoC type and name is set.

Regards,

Tony
 
> Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
> ---
>  arch/arm/boot/dts/omap3-igep.dtsi    | 4 ++--
>  arch/arm/boot/dts/omap3-igep0020.dts | 4 ++--
>  arch/arm/boot/dts/omap3-igep0030.dts | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
> index b3517b2..e4c8769 100644
> --- a/arch/arm/boot/dts/omap3-igep.dtsi
> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
> @@ -1,5 +1,5 @@
>  /*
> - * Device Tree Source for IGEP Technology devices
> + * Common device tree for IGEP boards based on AM/DM37x
>   *
>   * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
>   * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
> @@ -10,7 +10,7 @@
>   */
>  /dts-v1/;
>  
> -#include "omap34xx.dtsi"
> +#include "omap36xx.dtsi"
>  
>  / {
>  	memory {
> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
> index d5cc792..33ce123 100644
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -1,5 +1,5 @@
>  /*
> - * Device Tree Source for IGEPv2 board
> + * Device Tree Source for IGEPv2 Rev. (TI OMAP AM/DM37x)
>   *
>   * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
>   * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
> @@ -13,7 +13,7 @@
>  #include "omap-gpmc-smsc911x.dtsi"
>  
>  / {
> -	model = "IGEPv2";
> +	model = "IGEPv2 (TI OMAP AM/DM37x)";
>  	compatible = "isee,omap3-igep0020", "ti,omap3";
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
> index 525e6d9..02a23f8 100644
> --- a/arch/arm/boot/dts/omap3-igep0030.dts
> +++ b/arch/arm/boot/dts/omap3-igep0030.dts
> @@ -1,5 +1,5 @@
>  /*
> - * Device Tree Source for IGEP COM Module
> + * Device Tree Source for IGEP COM MODULE (TI OMAP AM/DM37x)
>   *
>   * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
>   * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
> @@ -12,7 +12,7 @@
>  #include "omap3-igep.dtsi"
>  
>  / {
> -	model = "IGEP COM Module";
> +	model = "IGEP COM MODULE (TI OMAP AM/DM37x)";
>  	compatible = "isee,omap3-igep0030", "ti,omap3";
>  
>  	leds {
> -- 
> 1.8.4.2
> 

Re: [PATCH 03/11] ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.

[Javier Martinez Canillas]

On 11/16/2013 03:44 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 05:25]:
>> From: Enric Balletbo i Serra <eballetbo@gmail.com>
>> 
>> Most of the boards are using the TI AM/DM37x processor, there is only a small
>> quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
>> omap36xx.dtsi include instead of omap34xx.dtsi include.
>> 
>> To avoid confusion we have added to the model the (TI AM/DM37x) comment.
> 
> You could have omap3-igep-common.dtsi that contains most configurations
> and then files including that where only the SoC type and name is set.
> 
> Regards,
> 
> Tony
>  

Hi Tony,

We do have a common DTSI file for IGEP boards which is
arch/arm/boot/dts/omap3-igep.dtsi. Maybe it should be renamed to -common to make
it more clear?

Anyways, there are two models OMAP3 based IGEP boards that include this common
DTSI: IGEPv2 (omap3-igep0020.dts) and IGEP COM Module (omap3-igep0030.dts).

However there are different revisions for each model with variations of the SoC
version used (AM/DM37x or OMAP3530), with wifi or not wifi, flash memory
technology (NAND or OneNAND) and different flash memory sizes.

So, we don't plan to support every single variation on mainline since this will
unnecessary increase the complexity of DTS adding not much benefit.

We just prefer to support the latter and most popular revision for each model
which is AM/DM37x SoC, wifi, 512 MB NAND flash.

Users that have a less popular revision can modify the reference DTS in mainline
to reflect their board.

>> Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
>> ---
>>  arch/arm/boot/dts/omap3-igep.dtsi    | 4 ++--
>>  arch/arm/boot/dts/omap3-igep0020.dts | 4 ++--
>>  arch/arm/boot/dts/omap3-igep0030.dts | 4 ++--
>>  3 files changed, 6 insertions(+), 6 deletions(-)
>> 
>> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
>> index b3517b2..e4c8769 100644
>> --- a/arch/arm/boot/dts/omap3-igep.dtsi
>> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Device Tree Source for IGEP Technology devices
>> + * Common device tree for IGEP boards based on AM/DM37x
>>   *
>>   * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
>>   * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
>> @@ -10,7 +10,7 @@
>>   */
>>  /dts-v1/;
>>  
>> -#include "omap34xx.dtsi"
>> +#include "omap36xx.dtsi"
>>  
>>  / {
>>  	memory {
>> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
>> index d5cc792..33ce123 100644
>> --- a/arch/arm/boot/dts/omap3-igep0020.dts
>> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Device Tree Source for IGEPv2 board
>> + * Device Tree Source for IGEPv2 Rev. (TI OMAP AM/DM37x)
>>   *
>>   * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
>>   * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
>> @@ -13,7 +13,7 @@
>>  #include "omap-gpmc-smsc911x.dtsi"
>>  
>>  / {
>> -	model = "IGEPv2";
>> +	model = "IGEPv2 (TI OMAP AM/DM37x)";
>>  	compatible = "isee,omap3-igep0020", "ti,omap3";
>>  
>>  	leds {
>> diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
>> index 525e6d9..02a23f8 100644
>> --- a/arch/arm/boot/dts/omap3-igep0030.dts
>> +++ b/arch/arm/boot/dts/omap3-igep0030.dts
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Device Tree Source for IGEP COM Module
>> + * Device Tree Source for IGEP COM MODULE (TI OMAP AM/DM37x)
>>   *
>>   * Copyright (C) 2012 Javier Martinez Canillas <javier@collabora.co.uk>
>>   * Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
>> @@ -12,7 +12,7 @@
>>  #include "omap3-igep.dtsi"
>>  
>>  / {
>> -	model = "IGEP COM Module";
>> +	model = "IGEP COM MODULE (TI OMAP AM/DM37x)";
>>  	compatible = "isee,omap3-igep0030", "ti,omap3";
>>  
>>  	leds {
>> -- 
>> 1.8.4.2
>> 
> 

Best regards,
Javier

Re: [PATCH 03/11] ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.

[Tony Lindgren]

* Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 07:21]:
> On 11/16/2013 03:44 PM, Tony Lindgren wrote:
> > * Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 05:25]:
> >> From: Enric Balletbo i Serra <eballetbo@gmail.com>
> >> 
> >> Most of the boards are using the TI AM/DM37x processor, there is only a small
> >> quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
> >> omap36xx.dtsi include instead of omap34xx.dtsi include.
> >> 
> >> To avoid confusion we have added to the model the (TI AM/DM37x) comment.
> > 
> > You could have omap3-igep-common.dtsi that contains most configurations
> > and then files including that where only the SoC type and name is set.
> > 
> > Regards,
> > 
> > Tony
> >  
> 
> Hi Tony,
> 
> We do have a common DTSI file for IGEP boards which is
> arch/arm/boot/dts/omap3-igep.dtsi. Maybe it should be renamed to -common to make
> it more clear?

No that's fine.
 
> Anyways, there are two models OMAP3 based IGEP boards that include this common
> DTSI: IGEPv2 (omap3-igep0020.dts) and IGEP COM Module (omap3-igep0030.dts).
> 
> However there are different revisions for each model with variations of the SoC
> version used (AM/DM37x or OMAP3530), with wifi or not wifi, flash memory
> technology (NAND or OneNAND) and different flash memory sizes.
> 
> So, we don't plan to support every single variation on mainline since this will
> unnecessary increase the complexity of DTS adding not much benefit.
> 
> We just prefer to support the latter and most popular revision for each model
> which is AM/DM37x SoC, wifi, 512 MB NAND flash.
> 
> Users that have a less popular revision can modify the reference DTS in mainline
> to reflect their board.

OK sounds fine to me and can be revisited if needed naturally.

Regards,

Tony

Re: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

[Javier Martinez Canillas]

Hi Tony,

On 11/16/2013 03:18 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 05:25]:
>> On Device Tree boot the VDDS_DSI regulator is not linked to
>> the DPI device so omapfb driver probing fails with:
>> 
>> [    3.186035] OMAPFB: omapfb_probe
>> [    3.190704] omapdss DPI error: can't get VDDS_DSI regulator
>> [    3.196594] omapfb omapfb: failed to connect default display
>> [    3.202667] omapfb omapfb: failed to init overlay connections
>> [    3.208892] OMAPFB: free_resources
>> [    3.212493] OMAPFB: free all fbmem
>> [    3.216735] omapfb omapfb: failed to setup omapfb
>> 
>> As a workaround try to use the VPLL2 regulator from twl4030 in
>> dpi_init_regulator() if getting the VDDS_DSI regulator fails.
> 
> Probably makes sens to fix this in the dpi.c, but this can also be set
> in the .dts file. I just set up the following in the omap3-ldp.dts file:
> 

Sorry is not clear to me if you agree that makes sense to do this fix on dpi.c
or if you think this is a bad idea and prefer to do it in the DTS instead?

I'm asking to know if I have to send a follow up patch or not :)

> &vaux1 {
> 	/* Needed for ads7846 */
> 	regulator-name = "vcc";
> };
> 
> &vpll2 {
> 	/* Needed for DSS */
> 	regulator-name = "vdds_dsi";
> };
> 
> Regards,
> 
> Tony
> 
>  
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>  drivers/video/omap2/dss/dpi.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
>> index bd48cde..e328f0b 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -550,6 +550,11 @@ static int dpi_init_regulator(void)
>>  		return 0;
>>  
>>  	vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "vdds_dsi");
>> +
>> +        /* DT HACK: try VPLL2 to make omapdss work for OMAP3 IGEPv2 */
>> +        if (IS_ERR(vdds_dsi))
>> +                vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "VPLL2");
>> +
>>  	if (IS_ERR(vdds_dsi)) {
>>  		DSSERR("can't get VDDS_DSI regulator\n");
>>  		return PTR_ERR(vdds_dsi);
>> -- 
>> 1.8.4.2
>> 
> 

Best regards,
Javier

Re: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

[Tony Lindgren]

* Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 07:36]:
> Hi Tony,
> 
> On 11/16/2013 03:18 PM, Tony Lindgren wrote:
> > * Javier Martinez Canillas <javier.martinez@collabora.co.uk> [131116 05:25]:
> >> On Device Tree boot the VDDS_DSI regulator is not linked to
> >> the DPI device so omapfb driver probing fails with:
> >> 
> >> [    3.186035] OMAPFB: omapfb_probe
> >> [    3.190704] omapdss DPI error: can't get VDDS_DSI regulator
> >> [    3.196594] omapfb omapfb: failed to connect default display
> >> [    3.202667] omapfb omapfb: failed to init overlay connections
> >> [    3.208892] OMAPFB: free_resources
> >> [    3.212493] OMAPFB: free all fbmem
> >> [    3.216735] omapfb omapfb: failed to setup omapfb
> >> 
> >> As a workaround try to use the VPLL2 regulator from twl4030 in
> >> dpi_init_regulator() if getting the VDDS_DSI regulator fails.
> > 
> > Probably makes sens to fix this in the dpi.c, but this can also be set
> > in the .dts file. I just set up the following in the omap3-ldp.dts file:
> > 
> 
> Sorry is not clear to me if you agree that makes sense to do this fix on dpi.c
> or if you think this is a bad idea and prefer to do it in the DTS instead?
> 
> I'm asking to know if I have to send a follow up patch or not :)

Well let's see what Tomi prefers.

> > &vaux1 {
> > 	/* Needed for ads7846 */
> > 	regulator-name = "vcc";
> > };
> > 
> > &vpll2 {
> > 	/* Needed for DSS */
> > 	regulator-name = "vdds_dsi";
> > };

In the long we'll use regulator phandles anyways in the DSS related
nodes, so from that point of view fixing dpi.c makes sense.

Regards,

Tony

Re: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

[Sebastian Reichel]

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

On Sat, Nov 16, 2013 at 07:45:07AM -0800, Tony Lindgren wrote:
> Well let's see what Tomi prefers.
> 
> > > &vaux1 {
> > > 	/* Needed for ads7846 */
> > > 	regulator-name = "vcc";
> > > };
> > > 
> > > &vpll2 {
> > > 	/* Needed for DSS */
> > > 	regulator-name = "vdds_dsi";
> > > };
> 
> In the long we'll use regulator phandles anyways in the DSS related
> nodes, so from that point of view fixing dpi.c makes sense.

The hack, as being sent by Javier, will result in the wrong
regulator being used on the Nokia N900, which is using vaux1.
It must depend on the machine.

At the same time the N900 device tree file uses V28 as
regulator-name for vaux1 (which is the same one as legacy boot
used). Nothing depends on this, but I don't think it's a
good idea to use this property. Apparently it does not work
if multiple drivers need the same regulator under different
names.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

[Javier Martinez Canillas]

Hi Sebastian,

On 11/16/2013 05:02 PM, Sebastian Reichel wrote:
> On Sat, Nov 16, 2013 at 07:45:07AM -0800, Tony Lindgren wrote:
>> Well let's see what Tomi prefers.
>> 
>> > > &vaux1 {
>> > > 	/* Needed for ads7846 */
>> > > 	regulator-name = "vcc";
>> > > };
>> > > 
>> > > &vpll2 {
>> > > 	/* Needed for DSS */
>> > > 	regulator-name = "vdds_dsi";
>> > > };
>> 
>> In the long we'll use regulator phandles anyways in the DSS related
>> nodes, so from that point of view fixing dpi.c makes sense.
> 
> The hack, as being sent by Javier, will result in the wrong
> regulator being used on the Nokia N900, which is using vaux1.
> It must depend on the machine.
>

I see, so this hack is not generic enough to be usable for all OMAP3 boards so I
think is better to just add the hack on the DTS.

I was more found about adding a hack on dpi.c since the DTB is an stable ABI
while the dpi.c implementation is not. But I guess is not that bad to change the
DTS later once DSS DT bindings are added to mainline.

> At the same time the N900 device tree file uses V28 as
> regulator-name for vaux1 (which is the same one as legacy boot
> used). Nothing depends on this, but I don't think it's a
> good idea to use this property. Apparently it does not work
> if multiple drivers need the same regulator under different
> names.
> 
> -- Sebastian
> 

So, what do you think about the following patch instead?

>From 99f1c60f6db6cac07ea2c0398a9cbb3525dfdd72 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Sat, 16 Nov 2013 17:59:08 +0100
Subject: [PATCH 1/1] ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as
 vdds_dsi

On Device Tree boot the VDDS_DSI regulator is not linked to
the DPI device so omapfb driver probing fails with:

[    3.186035] OMAPFB: omapfb_probe
[    3.190704] omapdss DPI error: can't get VDDS_DSI regulator
[    3.196594] omapfb omapfb: failed to connect default display
[    3.202667] omapfb omapfb: failed to init overlay connections
[    3.208892] OMAPFB: free_resources
[    3.212493] OMAPFB: free all fbmem
[    3.216735] omapfb omapfb: failed to setup omapfb

As a workaround name the VPLL2 regulator from twl4030 as "vdds_dsi"
so getting the VDDS_DSI regulator will succeed on dpi_init_regulator().

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/omap3-igep0020.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index b9a9e17..1c7e74d 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -215,3 +215,8 @@
 &usbhsehci {
 	phys = <&hsusb1_phy>;
 };
+
+&vpll2 {
+        /* Needed for DSS */
+        regulator-name = "vdds_dsi";
+};
-- 
1.8.4.2

Re: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

[Sebastian Reichel]

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

Hi Javier,

On Sat, Nov 16, 2013 at 06:28:00PM +0100, Javier Martinez Canillas wrote:
> > The hack, as being sent by Javier, will result in the wrong
> > regulator being used on the Nokia N900, which is using vaux1.
> > It must depend on the machine.
> 
> I see, so this hack is not generic enough to be usable for all OMAP3 boards so I
> think is better to just add the hack on the DTS.
>
> I was more found about adding a hack on dpi.c since the DTB is an stable ABI
> while the dpi.c implementation is not.

I agree with this. My suggestion would be to get the vdds_dsi regulator name
from platform data. This way each board can setup its own quirk until omapdss
supports DT.

> But I guess is not that bad to change the DTS later once DSS DT
> bindings are added to mainline.

As far as I know DT bindings are supposed to be as stable as
possible.

> > At the same time the N900 device tree file uses V28 as
> > regulator-name for vaux1 (which is the same one as legacy boot
> > used). Nothing depends on this, but I don't think it's a
> > good idea to use this property. Apparently it does not work
> > if multiple drivers need the same regulator under different
> > names.
> > 
> > -- Sebastian
> > 
> 
> So, what do you think about the following patch instead?
> 
> [PATCH]

For Nokia N900 vaux1 is also used for si4713 radio chip, lis3lv02d
accelerometer and battery cover sensor, so I don't like this hack.

If vppl2 is only used for omapdss.dsi on IGEP boards it might be
sensible to label it, though? So it might be ok there.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found

[Javier Martinez Canillas]

Hi Sebastian,

On 11/17/2013 01:26 AM, Sebastian Reichel wrote:
> Hi Javier,
> 
> On Sat, Nov 16, 2013 at 06:28:00PM +0100, Javier Martinez Canillas wrote:
>> > The hack, as being sent by Javier, will result in the wrong
>> > regulator being used on the Nokia N900, which is using vaux1.
>> > It must depend on the machine.
>> 
>> I see, so this hack is not generic enough to be usable for all OMAP3 boards so I
>> think is better to just add the hack on the DTS.
>>
>> I was more found about adding a hack on dpi.c since the DTB is an stable ABI
>> while the dpi.c implementation is not.
> 
> I agree with this. My suggestion would be to get the vdds_dsi regulator name
> from platform data. This way each board can setup its own quirk until omapdss
> supports DT.
> 
>> But I guess is not that bad to change the DTS later once DSS DT
>> bindings are added to mainline.
> 
> As far as I know DT bindings are supposed to be as stable as
> possible.
> 

Indeed, although as far as I understood on the latest ARM kernel summit it was
decided that DT bindings (and DTS) can be changed in incompatible ways if it can
be reasonably argued that nobody will be affected by the change.

IMHO this is the case for IGEP boards since the vendor (ISEE) is still shipping
the boards using an old 2.6.37 forked kernel that uses board files.

So I think is reasonable to remove this DT hack later once we have omapdss + CDF
bindings in mainline since current users that choose to use the mainline kernel
instead of the vendor one have to be able to replace the stock kernel +
bootloader that comes with the boards anyways.

>> > At the same time the N900 device tree file uses V28 as
>> > regulator-name for vaux1 (which is the same one as legacy boot
>> > used). Nothing depends on this, but I don't think it's a
>> > good idea to use this property. Apparently it does not work
>> > if multiple drivers need the same regulator under different
>> > names.
>> > 
>> > -- Sebastian
>> > 
>> 
>> So, what do you think about the following patch instead?
>> 
>> [PATCH]
> 
> For Nokia N900 vaux1 is also used for si4713 radio chip, lis3lv02d
> accelerometer and battery cover sensor, so I don't like this hack.
>
> If vppl2 is only used for omapdss.dsi on IGEP boards it might be
> sensible to label it, though? So it might be ok there.
>

Yes, you can't use this hack for the N900 since other devices already use the
vaux1 regulator named as "V28" so you can't just rename it to "vdds_dsi".

But for IGEP boards vpll2 is only used for omapdss DPI so we don't have that issue.

Let's see what Tomi says that is the best way to handle this to have DVI working
with DT until the propers bindings land in mainline.

> -- Sebastian
> 

Thanks a lot for your feedback and best regards,
Javier