[PATCH 0/7] OMAP3: Add basic DT support + i2c + twl

[PATCH 0/7] OMAP3: Add basic DT support + i2c + twl

[Benoit Cousson]

Hi Grant, Tony,

This is second part of the rework of the original series done by Manju:
http://www.spinics.net/lists/linux-omap/msg55827.html

It introduces the OMAP3 DT support incrementaly like it was done for OMAP4.

Patches are based on for_3.2/5_omap_dt_i2c_twl + devicetree/test
and are available here:
git://gitorious.org/omap-pm/linux.git for_3.2/6_omap3_dt_base

Tested on Beagle XM.

Comments are welcome.

Regards,
Benoit


Benoit Cousson (7):
  arm/dts: Add initial device-tree support for OMAP3 SoC
  arm/dts: OMAP3: Add mpu and iva nodes
  arm/dts: OMAP3: Add i2c controllers nodes
  arm/dts: omap3-beagle: Include the generic omap3.dtsi
  arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices
  OMAP3: board-dt: Add generic board file for DT support
  OMAP3: beagleboard: Remove DT support from regular board

 arch/arm/boot/dts/omap3-beagle.dts      |   68 +++++++++++++++++++++-
 arch/arm/boot/dts/omap3.dtsi            |   95 +++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/Kconfig             |   10 +++
 arch/arm/mach-omap2/Makefile            |    1 +
 arch/arm/mach-omap2/board-omap3-dt.c    |   74 ++++++++++++++++++++++++
 arch/arm/mach-omap2/board-omap3beagle.c |   13 ----
 arch/arm/mach-omap2/pm.c                |    6 +-
 7 files changed, 250 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3.dtsi
 create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c

[PATCH 0/7] OMAP3: Add basic DT support + i2c + twl

[Benoit Cousson]

Hi Grant, Tony,

This is second part of the rework of the original series done by Manju:
http://www.spinics.net/lists/linux-omap/msg55827.html

It introduces the OMAP3 DT support incrementaly like it was done for OMAP4.

Patches are based on for_3.2/5_omap_dt_i2c_twl + devicetree/test
and are available here:
git://gitorious.org/omap-pm/linux.git for_3.2/6_omap3_dt_base

Tested on Beagle XM.

Comments are welcome.

Regards,
Benoit


Benoit Cousson (7):
  arm/dts: Add initial device-tree support for OMAP3 SoC
  arm/dts: OMAP3: Add mpu and iva nodes
  arm/dts: OMAP3: Add i2c controllers nodes
  arm/dts: omap3-beagle: Include the generic omap3.dtsi
  arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices
  OMAP3: board-dt: Add generic board file for DT support
  OMAP3: beagleboard: Remove DT support from regular board

 arch/arm/boot/dts/omap3-beagle.dts      |   68 +++++++++++++++++++++-
 arch/arm/boot/dts/omap3.dtsi            |   95 +++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/Kconfig             |   10 +++
 arch/arm/mach-omap2/Makefile            |    1 +
 arch/arm/mach-omap2/board-omap3-dt.c    |   74 ++++++++++++++++++++++++
 arch/arm/mach-omap2/board-omap3beagle.c |   13 ----
 arch/arm/mach-omap2/pm.c                |    6 +-
 7 files changed, 250 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3.dtsi
 create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c

[PATCH 1/7] arm/dts: Add initial device-tree support for OMAP3 SoC

[Benoit Cousson]

Add initial OMAP3 soc file with empty ocp bus.

Based on initial patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55830.html

Signed-off-by: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: G, Manjunath Kondaiah <manjugk-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap3.dtsi |   44 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 44 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3.dtsi

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
new file mode 100644
index 0000000..1b27925
--- /dev/null
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for OMAP3 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "ti,omap3430", "ti,omap3";
+
+	/*
+	 * The soc node represents the soc top level view. It is uses for IPs
+	 * that are not memory mapped in the MPU view or for the MPU itself.
+	 */
+	soc {
+		compatible = "ti,omap-infra";
+	};
+
+	/*
+	 * XXX: Use a flat representation of the OMAP3 interconnect.
+	 * The real OMAP interconnect network is quite complex.
+	 * Since that will not bring real advantage to represent that in DT for
+	 * the moment, just use a fake OCP bus entry to represent the whole bus
+	 * hierarchy.
+	 */
+	ocp {
+		compatible = "ti,l3-smx", "arteris,smx", "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		hwmods = "l3_main";
+
+		intc: interrupt-controller@1 {
+			compatible = "ti,omap3-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+	};
+};
-- 
1.7.0.4

[PATCH 1/7] arm/dts: Add initial device-tree support for OMAP3 SoC

[Benoit Cousson]

Add initial OMAP3 soc file with empty ocp bus.

Based on initial patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55830.html

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3.dtsi |   44 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 44 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3.dtsi

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
new file mode 100644
index 0000000..1b27925
--- /dev/null
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for OMAP3 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "ti,omap3430", "ti,omap3";
+
+	/*
+	 * The soc node represents the soc top level view. It is uses for IPs
+	 * that are not memory mapped in the MPU view or for the MPU itself.
+	 */
+	soc {
+		compatible = "ti,omap-infra";
+	};
+
+	/*
+	 * XXX: Use a flat representation of the OMAP3 interconnect.
+	 * The real OMAP interconnect network is quite complex.
+	 * Since that will not bring real advantage to represent that in DT for
+	 * the moment, just use a fake OCP bus entry to represent the whole bus
+	 * hierarchy.
+	 */
+	ocp {
+		compatible = "ti,l3-smx", "arteris,smx", "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		hwmods = "l3_main";
+
+		intc: interrupt-controller at 1 {
+			compatible = "ti,omap3-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+	};
+};
-- 
1.7.0.4

[PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Benoit Cousson]

Add nodes for devices used by PM code (mpu, iva).
In the case of OMAP3, the dsp was included inside the IVA2.2.

Add an empty cpus node as well as recommended in the DT spec.

Remove mpu and iva devices init if CONFIG_OF is defined.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kevin Hilman <khilman@ti.com>
---
 arch/arm/boot/dts/omap3.dtsi |   24 ++++++++++++++++++++++++
 arch/arm/mach-omap2/pm.c     |    6 ++++--
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1b27925..5a95a69 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -14,11 +14,35 @@
 	compatible = "ti,omap3430", "ti,omap3";
 
 	/*
+	 * XXX: The cpus node is mandatory, but since the CPUs are as well part
+	 * of the mpu subsystem below, it is not clear where the information
+	 * should be. Maybe here with a phandle inside the mpu?
+	 */
+	cpus {
+	};
+
+	/*
 	 * The soc node represents the soc top level view. It is uses for IPs
 	 * that are not memory mapped in the MPU view or for the MPU itself.
 	 */
 	soc {
 		compatible = "ti,omap-infra";
+		mpu {
+			compatible = "ti,omap3-mpu";
+			hwmods = "mpu";
+			cpu@0 {
+				compatible = "arm,cortex-a8";
+			};
+		};
+
+		iva {
+			compatible = "ti,iva22", "ti,iva";
+			hwmods = "iva";
+
+			dsp {
+				compatible = "ti,omap3-c64", "ti,c64";
+			};
+		};
 	};
 
 	/*
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index ba4d187..1fdde69 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -24,6 +24,7 @@
 #include "clockdomain.h"
 #include "pm.h"
 
+#ifndef CONFIG_OF
 static struct omap_device_pm_latency *pm_lats;
 
 static int _init_omap_device(char *name)
@@ -53,17 +54,18 @@ static void omap2_init_processor_devices(void)
 		_init_omap_device("iva");
 
 	if (cpu_is_omap44xx()) {
-#ifndef CONFIG_OF
 		_init_omap_device("mpu");
 		_init_omap_device("l3_main_1");
 		_init_omap_device("dsp");
 		_init_omap_device("iva");
-#endif
 	} else {
 		_init_omap_device("mpu");
 		_init_omap_device("l3_main");
 	}
 }
+#else
+static void omap2_init_processor_devices(void) {}
+#endif
 
 /* Types of sleep_switch used in omap_set_pwrdm_state */
 #define FORCEWAKEUP_SWITCH	0
-- 
1.7.0.4

[PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Benoit Cousson]

Add nodes for devices used by PM code (mpu, iva).
In the case of OMAP3, the dsp was included inside the IVA2.2.

Add an empty cpus node as well as recommended in the DT spec.

Remove mpu and iva devices init if CONFIG_OF is defined.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kevin Hilman <khilman@ti.com>
---
 arch/arm/boot/dts/omap3.dtsi |   24 ++++++++++++++++++++++++
 arch/arm/mach-omap2/pm.c     |    6 ++++--
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1b27925..5a95a69 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -14,11 +14,35 @@
 	compatible = "ti,omap3430", "ti,omap3";
 
 	/*
+	 * XXX: The cpus node is mandatory, but since the CPUs are as well part
+	 * of the mpu subsystem below, it is not clear where the information
+	 * should be. Maybe here with a phandle inside the mpu?
+	 */
+	cpus {
+	};
+
+	/*
 	 * The soc node represents the soc top level view. It is uses for IPs
 	 * that are not memory mapped in the MPU view or for the MPU itself.
 	 */
 	soc {
 		compatible = "ti,omap-infra";
+		mpu {
+			compatible = "ti,omap3-mpu";
+			hwmods = "mpu";
+			cpu at 0 {
+				compatible = "arm,cortex-a8";
+			};
+		};
+
+		iva {
+			compatible = "ti,iva22", "ti,iva";
+			hwmods = "iva";
+
+			dsp {
+				compatible = "ti,omap3-c64", "ti,c64";
+			};
+		};
 	};
 
 	/*
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index ba4d187..1fdde69 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -24,6 +24,7 @@
 #include "clockdomain.h"
 #include "pm.h"
 
+#ifndef CONFIG_OF
 static struct omap_device_pm_latency *pm_lats;
 
 static int _init_omap_device(char *name)
@@ -53,17 +54,18 @@ static void omap2_init_processor_devices(void)
 		_init_omap_device("iva");
 
 	if (cpu_is_omap44xx()) {
-#ifndef CONFIG_OF
 		_init_omap_device("mpu");
 		_init_omap_device("l3_main_1");
 		_init_omap_device("dsp");
 		_init_omap_device("iva");
-#endif
 	} else {
 		_init_omap_device("mpu");
 		_init_omap_device("l3_main");
 	}
 }
+#else
+static void omap2_init_processor_devices(void) {}
+#endif
 
 /* Types of sleep_switch used in omap_set_pwrdm_state */
 #define FORCEWAKEUP_SWITCH	0
-- 
1.7.0.4

[PATCH 3/7] arm/dts: OMAP3: Add i2c controllers nodes

[Benoit Cousson]

Add i2c controllers nodes into the main ocp bus.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3.dtsi |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 5a95a69..aab2129 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,12 @@
 / {
 	compatible = "ti,omap3430", "ti,omap3";
 
+	aliases {
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+	};
+
 	/*
 	 * XXX: The cpus node is mandatory, but since the CPUs are as well part
 	 * of the mpu subsystem below, it is not clear where the information
@@ -64,5 +70,26 @@
 			interrupt-controller;
 			#interrupt-cells = <1>;
 		};
+
+		i2c1: i2c@1 {
+			compatible = "ti,omap3-i2c", "ti,omap-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			hwmods = "i2c1";
+		};
+
+		i2c2: i2c@2 {
+			compatible = "ti,omap3-i2c", "ti,omap-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			hwmods = "i2c2";
+		};
+
+		i2c3: i2c@3 {
+			compatible = "ti,omap3-i2c", "ti,omap-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			hwmods = "i2c3";
+		};
 	};
 };
-- 
1.7.0.4

[PATCH 3/7] arm/dts: OMAP3: Add i2c controllers nodes

[Benoit Cousson]

Add i2c controllers nodes into the main ocp bus.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3.dtsi |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 5a95a69..aab2129 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,12 @@
 / {
 	compatible = "ti,omap3430", "ti,omap3";
 
+	aliases {
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+	};
+
 	/*
 	 * XXX: The cpus node is mandatory, but since the CPUs are as well part
 	 * of the mpu subsystem below, it is not clear where the information
@@ -64,5 +70,26 @@
 			interrupt-controller;
 			#interrupt-cells = <1>;
 		};
+
+		i2c1: i2c at 1 {
+			compatible = "ti,omap3-i2c", "ti,omap-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			hwmods = "i2c1";
+		};
+
+		i2c2: i2c at 2 {
+			compatible = "ti,omap3-i2c", "ti,omap-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			hwmods = "i2c2";
+		};
+
+		i2c3: i2c at 3 {
+			compatible = "ti,omap3-i2c", "ti,omap-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			hwmods = "i2c3";
+		};
 	};
 };
-- 
1.7.0.4

[PATCH 4/7] arm/dts: omap3-beagle: Include the generic omap3.dtsi

[Benoit Cousson]

Update OMAP3 beagleboard DTS file to use the omap3.dtsi
SoC file.
Add a default bootargs line to allow a boot from RAMDISK
Add memory node information.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3-beagle.dts |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 4439466..da13ec7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -1,7 +1,29 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
 /dts-v1/;
-/include/ "skeleton.dtsi"
+
+/include/ "omap3.dtsi"
 
 / {
 	model = "TI OMAP3 BeagleBoard";
-	compatible = "ti,omap3-beagle";
+	compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3";
+
+	/*
+	 * Since the initial device tree board file does not create any
+	 * devices (MMC, network...), the only way to boot is to provide a
+	 * ramdisk.
+	 */
+	chosen {
+		bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 no_console_suspend debug earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x20000000>; /* 512 MB */
+	};
 };
-- 
1.7.0.4

[PATCH 4/7] arm/dts: omap3-beagle: Include the generic omap3.dtsi

[Benoit Cousson]

Update OMAP3 beagleboard DTS file to use the omap3.dtsi
SoC file.
Add a default bootargs line to allow a boot from RAMDISK
Add memory node information.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3-beagle.dts |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 4439466..da13ec7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -1,7 +1,29 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
 /dts-v1/;
-/include/ "skeleton.dtsi"
+
+/include/ "omap3.dtsi"
 
 / {
 	model = "TI OMAP3 BeagleBoard";
-	compatible = "ti,omap3-beagle";
+	compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3";
+
+	/*
+	 * Since the initial device tree board file does not create any
+	 * devices (MMC, network...), the only way to boot is to provide a
+	 * ramdisk.
+	 */
+	chosen {
+		bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 no_console_suspend debug earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x20000000>; /* 512 MB */
+	};
 };
-- 
1.7.0.4

[PATCH 5/7] arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices

[Benoit Cousson]

Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Add required clock frequencies for the i2c client devices existing
on beagle board.

Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3-beagle.dts |   42 ++++++++++++++++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index da13ec7..5d0a558 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,45 @@
 		reg = <0x80000000 0x20000000>; /* 512 MB */
 	};
 };
+
+&i2c1 {
+	clock-frequency = <2600000>;
+
+	/*
+	 * Integrated Power Management Chip
+	 */
+	twl@48 {
+		compatible = "ti,twl4030";
+		reg = <0x48>;
+		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		interrupt-parent = <&intc>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		ranges = <0 0x48>;
+
+		twl_rtc {
+			compatible = "ti,twl_rtc";
+			interrupts = <11>;
+			reg = <0>;
+		};
+	};
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+
+	/*
+	 * Display monitor features are burnt in the EEPROM
+	 * as EDID data.
+	 */
+	eeprom@50 {
+		compatible = "ti,eeprom";
+		reg = <0x50>;
+	};
+};
-- 
1.7.0.4

[PATCH 5/7] arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices

[Benoit Cousson]

Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Add required clock frequencies for the i2c client devices existing
on beagle board.

Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/boot/dts/omap3-beagle.dts |   42 ++++++++++++++++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index da13ec7..5d0a558 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,45 @@
 		reg = <0x80000000 0x20000000>; /* 512 MB */
 	};
 };
+
+&i2c1 {
+	clock-frequency = <2600000>;
+
+	/*
+	 * Integrated Power Management Chip
+	 */
+	twl at 48 {
+		compatible = "ti,twl4030";
+		reg = <0x48>;
+		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		interrupt-parent = <&intc>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		ranges = <0 0x48>;
+
+		twl_rtc {
+			compatible = "ti,twl_rtc";
+			interrupts = <11>;
+			reg = <0>;
+		};
+	};
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+
+	/*
+	 * Display monitor features are burnt in the EEPROM
+	 * as EDID data.
+	 */
+	eeprom at 50 {
+		compatible = "ti,eeprom";
+		reg = <0x50>;
+	};
+};
-- 
1.7.0.4

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Benoit Cousson]

Create an OMAP3 generic board to start the DT migration.

This file is doing the minimal initialization needed to boot
properly on a RAMDISK filesystem.

As soon as the OMAP3 specifics will be removed, that board will
be converted to an even more generic board-dt.c that will support
every OMAP2+ platforms.

Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55832.html

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/mach-omap2/Kconfig          |   10 +++++
 arch/arm/mach-omap2/Makefile         |    1 +
 arch/arm/mach-omap2/board-omap3-dt.c |   74 ++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5d501d2..82f0df2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -305,6 +305,16 @@ config MACH_OMAP_3630SDP
 	default y
 	select OMAP_PACKAGE_CBP
 
+config MACH_OMAP3_DT
+	bool "Generic OMAP3 board (FDT support)"
+	depends on ARCH_OMAP3
+	select OMAP_PACKAGE_CBB
+	select USE_OF
+	help
+	  Support for generic TI OMAP3 boards using Flattened Device Tree.
+	  Say Y here to enable OMAP3 device tree support
+	  More information at Documentation/devicetree
+
 config MACH_TI8168EVM
 	bool "TI8168 Evaluation Module"
 	depends on SOC_OMAPTI816X
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6ab9116..5144c17 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -197,6 +197,7 @@ obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
 obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o
 obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o
 obj-$(CONFIG_MACH_OMAP_3430SDP)		+= board-3430sdp.o
+obj-$(CONFIG_MACH_OMAP3_DT)		+= board-omap3-dt.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)		+= board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RM680)		+= board-rm680.o \
 					   sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
new file mode 100644
index 0000000..6eb56c6
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3-dt.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP3 Device tree boards support
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/irqdomain.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+
+#include <asm/mach/arch.h>
+#include <plat/common.h>
+
+#include "mux.h"
+#include "common-board-devices.h"
+#include "sdram-micron-mt46h32m32lf-6.h"
+
+
+static void __init omap3_init_early(void)
+{
+	omap2_init_common_infrastructure();
+	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
+				  mt46h32m32lf6_sdrc_params);
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+	{ .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+	{ .compatible = "simple-bus", },
+	{ .compatible = "ti,omap-infra", },
+	{}
+};
+
+static struct of_device_id omap_dt_intc_match[] __initdata = {
+	{ .compatible = "ti,omap3-intc", },
+	{}
+};
+
+static void __init omap3_init(void)
+{
+	struct device_node *node;
+
+	node = of_find_matching_node(NULL, omap_dt_intc_match);
+	if (node)
+		irq_domain_add_simple(node, 0);
+
+	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+	omap_serial_init();
+
+	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+}
+
+static const char *omap3_dt_match[] __initdata = {
+	"ti,omap3",
+	NULL
+};
+
+DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
+	.reserve	= omap_reserve,
+	.map_io		= omap3_map_io,
+	.init_early	= omap3_init_early,
+	.init_irq	= omap3_init_irq,
+	.init_machine	= omap3_init,
+	.timer		= &omap3_timer,
+	.dt_compat	= omap3_dt_match,
+MACHINE_END
-- 
1.7.0.4

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Benoit Cousson]

Create an OMAP3 generic board to start the DT migration.

This file is doing the minimal initialization needed to boot
properly on a RAMDISK filesystem.

As soon as the OMAP3 specifics will be removed, that board will
be converted to an even more generic board-dt.c that will support
every OMAP2+ platforms.

Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55832.html

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/mach-omap2/Kconfig          |   10 +++++
 arch/arm/mach-omap2/Makefile         |    1 +
 arch/arm/mach-omap2/board-omap3-dt.c |   74 ++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5d501d2..82f0df2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -305,6 +305,16 @@ config MACH_OMAP_3630SDP
 	default y
 	select OMAP_PACKAGE_CBP
 
+config MACH_OMAP3_DT
+	bool "Generic OMAP3 board (FDT support)"
+	depends on ARCH_OMAP3
+	select OMAP_PACKAGE_CBB
+	select USE_OF
+	help
+	  Support for generic TI OMAP3 boards using Flattened Device Tree.
+	  Say Y here to enable OMAP3 device tree support
+	  More information at Documentation/devicetree
+
 config MACH_TI8168EVM
 	bool "TI8168 Evaluation Module"
 	depends on SOC_OMAPTI816X
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6ab9116..5144c17 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -197,6 +197,7 @@ obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
 obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o
 obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o
 obj-$(CONFIG_MACH_OMAP_3430SDP)		+= board-3430sdp.o
+obj-$(CONFIG_MACH_OMAP3_DT)		+= board-omap3-dt.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)		+= board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RM680)		+= board-rm680.o \
 					   sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
new file mode 100644
index 0000000..6eb56c6
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3-dt.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP3 Device tree boards support
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/irqdomain.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+
+#include <asm/mach/arch.h>
+#include <plat/common.h>
+
+#include "mux.h"
+#include "common-board-devices.h"
+#include "sdram-micron-mt46h32m32lf-6.h"
+
+
+static void __init omap3_init_early(void)
+{
+	omap2_init_common_infrastructure();
+	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
+				  mt46h32m32lf6_sdrc_params);
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+	{ .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+	{ .compatible = "simple-bus", },
+	{ .compatible = "ti,omap-infra", },
+	{}
+};
+
+static struct of_device_id omap_dt_intc_match[] __initdata = {
+	{ .compatible = "ti,omap3-intc", },
+	{}
+};
+
+static void __init omap3_init(void)
+{
+	struct device_node *node;
+
+	node = of_find_matching_node(NULL, omap_dt_intc_match);
+	if (node)
+		irq_domain_add_simple(node, 0);
+
+	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+	omap_serial_init();
+
+	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+}
+
+static const char *omap3_dt_match[] __initdata = {
+	"ti,omap3",
+	NULL
+};
+
+DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
+	.reserve	= omap_reserve,
+	.map_io		= omap3_map_io,
+	.init_early	= omap3_init_early,
+	.init_irq	= omap3_init_irq,
+	.init_machine	= omap3_init,
+	.timer		= &omap3_timer,
+	.dt_compat	= omap3_dt_match,
+MACHINE_END
-- 
1.7.0.4

[PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Benoit Cousson]

In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.

Any DT work for OMAP3 will have to be done on the generic DT
board file to avoid breaking the legacy board support until
DT migration is done.

Based on orginal patch fropm Manju:
http://www.spinics.net/lists/linux-omap/msg55832.html

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-omap3beagle.c |   13 -------------
 1 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index a7923ca..2c358a2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -19,7 +19,6 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/io.h>
-#include <linux/of_platform.h>
 #include <linux/leds.h>
 #include <linux/gpio.h>
 #include <linux/input.h>
@@ -388,9 +387,7 @@ static int __init omap3_beagle_i2c_init(void)
 	/* Bus 3 is attached to the DVI port where devices like the pico DLP
 	 * projector don't work reliably with 400kHz */
 	omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom));
-#ifdef CONFIG_OF
 	omap_register_i2c_bus(2, 100, NULL, 0);
-#endif /* CONFIG_OF */
 	return 0;
 }
 
@@ -528,10 +525,6 @@ static void __init beagle_opp_init(void)
 
 static void __init omap3_beagle_init(void)
 {
-#ifdef CONFIG_OF
-	of_platform_prepare(NULL, NULL);
-#endif /* CONFIG_OF */
-
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	omap3_beagle_init_rev();
 	omap3_beagle_i2c_init();
@@ -563,11 +556,6 @@ static void __init omap3_beagle_init(void)
 	beagle_opp_init();
 }
 
-static const char *omap3_beagle_dt_match[] __initdata = {
-	"ti,omap3-beagle",
-	NULL
-};
-
 MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
 	/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
 	.boot_params	= 0x80000100,
@@ -577,5 +565,4 @@ MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
 	.init_irq	= omap3_beagle_init_irq,
 	.init_machine	= omap3_beagle_init,
 	.timer		= &omap3_secure_timer,
-	.dt_compat	= omap3_beagle_dt_match,
 MACHINE_END
-- 
1.7.0.4

[PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Benoit Cousson]

In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.

Any DT work for OMAP3 will have to be done on the generic DT
board file to avoid breaking the legacy board support until
DT migration is done.

Based on orginal patch fropm Manju:
http://www.spinics.net/lists/linux-omap/msg55832.html

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-omap3beagle.c |   13 -------------
 1 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index a7923ca..2c358a2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -19,7 +19,6 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/io.h>
-#include <linux/of_platform.h>
 #include <linux/leds.h>
 #include <linux/gpio.h>
 #include <linux/input.h>
@@ -388,9 +387,7 @@ static int __init omap3_beagle_i2c_init(void)
 	/* Bus 3 is attached to the DVI port where devices like the pico DLP
 	 * projector don't work reliably with 400kHz */
 	omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom));
-#ifdef CONFIG_OF
 	omap_register_i2c_bus(2, 100, NULL, 0);
-#endif /* CONFIG_OF */
 	return 0;
 }
 
@@ -528,10 +525,6 @@ static void __init beagle_opp_init(void)
 
 static void __init omap3_beagle_init(void)
 {
-#ifdef CONFIG_OF
-	of_platform_prepare(NULL, NULL);
-#endif /* CONFIG_OF */
-
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	omap3_beagle_init_rev();
 	omap3_beagle_i2c_init();
@@ -563,11 +556,6 @@ static void __init omap3_beagle_init(void)
 	beagle_opp_init();
 }
 
-static const char *omap3_beagle_dt_match[] __initdata = {
-	"ti,omap3-beagle",
-	NULL
-};
-
 MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
 	/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
 	.boot_params	= 0x80000100,
@@ -577,5 +565,4 @@ MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
 	.init_irq	= omap3_beagle_init_irq,
 	.init_machine	= omap3_beagle_init,
 	.timer		= &omap3_secure_timer,
-	.dt_compat	= omap3_beagle_dt_match,
 MACHINE_END
-- 
1.7.0.4

Re: [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Arnd Bergmann]

On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote:
> 
>         /*
> +        * XXX: The cpus node is mandatory, but since the CPUs are as well part
> +        * of the mpu subsystem below, it is not clear where the information
> +        * should be. Maybe here with a phandle inside the mpu?
> +        */
> +       cpus {
> +       };
> +
> +       /*
>          * The soc node represents the soc top level view. It is uses for IPs
>          * that are not memory mapped in the MPU view or for the MPU itself.
>          */
>         soc {
>                 compatible = "ti,omap-infra";
> +               mpu {
> +                       compatible = "ti,omap3-mpu";
> +                       hwmods = "mpu";
> +                       cpu@0 {
> +                               compatible = "arm,cortex-a8";
> +                       };
> +               };
> +

I would always put the cpu nodes in the top-level, even if that's
a slight misrepresentation of the truth. The point is basically
that CPU nodes are special (you cannot have device drivers for them)
and that the device tree is basically laid out from the perspective
of the CPU, which may be different from the perspective that a
hardware designer has.

	Arnd

[PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Arnd Bergmann]

On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote:
> 
>         /*
> +        * XXX: The cpus node is mandatory, but since the CPUs are as well part
> +        * of the mpu subsystem below, it is not clear where the information
> +        * should be. Maybe here with a phandle inside the mpu?
> +        */
> +       cpus {
> +       };
> +
> +       /*
>          * The soc node represents the soc top level view. It is uses for IPs
>          * that are not memory mapped in the MPU view or for the MPU itself.
>          */
>         soc {
>                 compatible = "ti,omap-infra";
> +               mpu {
> +                       compatible = "ti,omap3-mpu";
> +                       hwmods = "mpu";
> +                       cpu at 0 {
> +                               compatible = "arm,cortex-a8";
> +                       };
> +               };
> +

I would always put the cpu nodes in the top-level, even if that's
a slight misrepresentation of the truth. The point is basically
that CPU nodes are special (you cannot have device drivers for them)
and that the device tree is basically laid out from the perspective
of the CPU, which may be different from the perspective that a
hardware designer has.

	Arnd

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Tony Lindgren]

Hi,

* Benoit Cousson <b-cousson@ti.com> [110901 19:52]:
> Create an OMAP3 generic board to start the DT migration.

I don't think this needs to be SoC specific, we can add multiple
DT_MACHINE_START entries into a single file. So it should be
just board-omap-dt.c.
 
> +#include "mux.h"
> +#include "common-board-devices.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +
> +static void __init omap3_init_early(void)
> +{
> +	omap2_init_common_infrastructure();
> +	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
> +				  mt46h32m32lf6_sdrc_params);
> +}

This has changed, see the cleanup branch. Also, let's just leave
out the sdram timings for now as we can work with bootloader
timings until those come from DT too.

> +static void __init omap3_init(void)
> +{
> +	struct device_node *node;
> +
> +	node = of_find_matching_node(NULL, omap_dt_intc_match);
> +	if (node)
> +		irq_domain_add_simple(node, 0);
> +
> +	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> +	omap_serial_init();
> +
> +	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> +	"ti,omap3",
> +	NULL
> +};

Most likely we just need SoC specific init functions in this file
now until the mux data comes from DT also.

> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> +	.reserve	= omap_reserve,
> +	.map_io		= omap3_map_io,
> +	.init_early	= omap3_init_early,
> +	.init_irq	= omap3_init_irq,
> +	.init_machine	= omap3_init,
> +	.timer		= &omap3_timer,
> +	.dt_compat	= omap3_dt_match,
> +MACHINE_END

Here omap3_init_early is now generic in the cleanup branch.

Regards,

Tony

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Tony Lindgren]

Hi,

* Benoit Cousson <b-cousson@ti.com> [110901 19:52]:
> Create an OMAP3 generic board to start the DT migration.

I don't think this needs to be SoC specific, we can add multiple
DT_MACHINE_START entries into a single file. So it should be
just board-omap-dt.c.
 
> +#include "mux.h"
> +#include "common-board-devices.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +
> +static void __init omap3_init_early(void)
> +{
> +	omap2_init_common_infrastructure();
> +	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
> +				  mt46h32m32lf6_sdrc_params);
> +}

This has changed, see the cleanup branch. Also, let's just leave
out the sdram timings for now as we can work with bootloader
timings until those come from DT too.

> +static void __init omap3_init(void)
> +{
> +	struct device_node *node;
> +
> +	node = of_find_matching_node(NULL, omap_dt_intc_match);
> +	if (node)
> +		irq_domain_add_simple(node, 0);
> +
> +	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> +	omap_serial_init();
> +
> +	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> +	"ti,omap3",
> +	NULL
> +};

Most likely we just need SoC specific init functions in this file
now until the mux data comes from DT also.

> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> +	.reserve	= omap_reserve,
> +	.map_io		= omap3_map_io,
> +	.init_early	= omap3_init_early,
> +	.init_irq	= omap3_init_irq,
> +	.init_machine	= omap3_init,
> +	.timer		= &omap3_timer,
> +	.dt_compat	= omap3_dt_match,
> +MACHINE_END

Here omap3_init_early is now generic in the cleanup branch.

Regards,

Tony

Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Tony Lindgren]

* Benoit Cousson <b-cousson@ti.com> [110901 19:52]:
> In order to avoid conflict with the new board-omap3-dt.c file,
> remove the .dt_compat entry from the beagle regular board
> file.
> 
> Any DT work for OMAP3 will have to be done on the generic DT
> board file to avoid breaking the legacy board support until
> DT migration is done.

In general we should not keep duplicate old non-DT data around
now that we have the DT append support. Instead we should just
require the .dts file appended to zImage for all mach-omap2
machines. Otherwise we'll end up with double bloat :)

So it's OK to have the DT entries in board files so drivers
that get converted will work with them.

Tony

[PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Tony Lindgren]

* Benoit Cousson <b-cousson@ti.com> [110901 19:52]:
> In order to avoid conflict with the new board-omap3-dt.c file,
> remove the .dt_compat entry from the beagle regular board
> file.
> 
> Any DT work for OMAP3 will have to be done on the generic DT
> board file to avoid breaking the legacy board support until
> DT migration is done.

In general we should not keep duplicate old non-DT data around
now that we have the DT append support. Instead we should just
require the .dts file appended to zImage for all mach-omap2
machines. Otherwise we'll end up with double bloat :)

So it's OK to have the DT entries in board files so drivers
that get converted will work with them.

Tony

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

Hi Tony,

On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> Hi,
>
> * Benoit Cousson<b-cousson@ti.com>  [110901 19:52]:
>> Create an OMAP3 generic board to start the DT migration.
>
> I don't think this needs to be SoC specific, we can add multiple
> DT_MACHINE_START entries into a single file. So it should be
> just board-omap-dt.c.

I do agree, it should not, I made that comment into the 
board-omap4-dt.c, but for the moment we still have dedicated OMAP 
specifics stuff at board level, like the map_io.

I have an other series that make the map_io DT aware to get rid of that, 
but it still not finalized.

My goal was have a single DT_MACHINE_START for every OMAPs.
But, meanwhile, if you prefer one file with many board descriptors, 
that's fine.

>> +#include "mux.h"
>> +#include "common-board-devices.h"
>> +#include "sdram-micron-mt46h32m32lf-6.h"
>> +
>> +
>> +static void __init omap3_init_early(void)
>> +{
>> +	omap2_init_common_infrastructure();
>> +	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
>> +				  mt46h32m32lf6_sdrc_params);
>> +}
>
> This has changed, see the cleanup branch. Also, let's just leave
> out the sdram timings for now as we can work with bootloader
> timings until those come from DT too.

Yep, I know, but since that series is based on my previous series that 
is based on mainline rc-3, I missed these.

Now, that kernel.org is back, I'll pull you branches :-).

Which one do you recommend in that case, master or cleanup?

>> +static void __init omap3_init(void)
>> +{
>> +	struct device_node *node;
>> +
>> +	node = of_find_matching_node(NULL, omap_dt_intc_match);
>> +	if (node)
>> +		irq_domain_add_simple(node, 0);
>> +
>> +	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>> +	omap_serial_init();
>> +
>> +	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>> +}
>> +
>> +static const char *omap3_dt_match[] __initdata = {
>> +	"ti,omap3",
>> +	NULL
>> +};
>
> Most likely we just need SoC specific init functions in this file
> now until the mux data comes from DT also.

OK, I can get rid of mux stuff then.

>> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
>> +	.reserve	= omap_reserve,
>> +	.map_io		= omap3_map_io,
>> +	.init_early	= omap3_init_early,
>> +	.init_irq	= omap3_init_irq,
>> +	.init_machine	= omap3_init,
>> +	.timer		=&omap3_timer,
>> +	.dt_compat	= omap3_dt_match,
>> +MACHINE_END
>
> Here omap3_init_early is now generic in the cleanup branch.

Cool, I'll update the whole series, including the OMAP4 ones.

Benoit

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

Hi Tony,

On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> Hi,
>
> * Benoit Cousson<b-cousson@ti.com>  [110901 19:52]:
>> Create an OMAP3 generic board to start the DT migration.
>
> I don't think this needs to be SoC specific, we can add multiple
> DT_MACHINE_START entries into a single file. So it should be
> just board-omap-dt.c.

I do agree, it should not, I made that comment into the 
board-omap4-dt.c, but for the moment we still have dedicated OMAP 
specifics stuff at board level, like the map_io.

I have an other series that make the map_io DT aware to get rid of that, 
but it still not finalized.

My goal was have a single DT_MACHINE_START for every OMAPs.
But, meanwhile, if you prefer one file with many board descriptors, 
that's fine.

>> +#include "mux.h"
>> +#include "common-board-devices.h"
>> +#include "sdram-micron-mt46h32m32lf-6.h"
>> +
>> +
>> +static void __init omap3_init_early(void)
>> +{
>> +	omap2_init_common_infrastructure();
>> +	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
>> +				  mt46h32m32lf6_sdrc_params);
>> +}
>
> This has changed, see the cleanup branch. Also, let's just leave
> out the sdram timings for now as we can work with bootloader
> timings until those come from DT too.

Yep, I know, but since that series is based on my previous series that 
is based on mainline rc-3, I missed these.

Now, that kernel.org is back, I'll pull you branches :-).

Which one do you recommend in that case, master or cleanup?

>> +static void __init omap3_init(void)
>> +{
>> +	struct device_node *node;
>> +
>> +	node = of_find_matching_node(NULL, omap_dt_intc_match);
>> +	if (node)
>> +		irq_domain_add_simple(node, 0);
>> +
>> +	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>> +	omap_serial_init();
>> +
>> +	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>> +}
>> +
>> +static const char *omap3_dt_match[] __initdata = {
>> +	"ti,omap3",
>> +	NULL
>> +};
>
> Most likely we just need SoC specific init functions in this file
> now until the mux data comes from DT also.

OK, I can get rid of mux stuff then.

>> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
>> +	.reserve	= omap_reserve,
>> +	.map_io		= omap3_map_io,
>> +	.init_early	= omap3_init_early,
>> +	.init_irq	= omap3_init_irq,
>> +	.init_machine	= omap3_init,
>> +	.timer		=&omap3_timer,
>> +	.dt_compat	= omap3_dt_match,
>> +MACHINE_END
>
> Here omap3_init_early is now generic in the cleanup branch.

Cool, I'll update the whole series, including the OMAP4 ones.

Benoit

Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Cousson, Benoit]

On 9/2/2011 10:12 AM, Tony Lindgren wrote:
> * Benoit Cousson<b-cousson@ti.com>  [110901 19:52]:
>> In order to avoid conflict with the new board-omap3-dt.c file,
>> remove the .dt_compat entry from the beagle regular board
>> file.
>>
>> Any DT work for OMAP3 will have to be done on the generic DT
>> board file to avoid breaking the legacy board support until
>> DT migration is done.
>
> In general we should not keep duplicate old non-DT data around
> now that we have the DT append support. Instead we should just
> require the .dts file appended to zImage for all mach-omap2
> machines. Otherwise we'll end up with double bloat :)

Mmm, I'm not sure to get your point. We are not duplicating, since a 
pure DT generic board will not have anything except a 
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
And the regular board files will keep initializing devices statically.
The drivers will then for the moment support both pdata and DT method to 
get board parameters.

> So it's OK to have the DT entries in board files so drivers
> that get converted will work with them.

Well, it will be a little bit more tricky, because having DT in current 
board files will be a mess with a bunch of #ifdef CONFIG_OF, and adding 
DT compatible inside each boards will prevent the pure generic DT one to 
work. In that case we will duplicate the DT migration in every legacy 
boards files...

That's why the current strategy is to keep the current board files 
non-DT aware and add the DT support only to the generic DT board file.

Regards,
Benoit

[PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Cousson, Benoit]

On 9/2/2011 10:12 AM, Tony Lindgren wrote:
> * Benoit Cousson<b-cousson@ti.com>  [110901 19:52]:
>> In order to avoid conflict with the new board-omap3-dt.c file,
>> remove the .dt_compat entry from the beagle regular board
>> file.
>>
>> Any DT work for OMAP3 will have to be done on the generic DT
>> board file to avoid breaking the legacy board support until
>> DT migration is done.
>
> In general we should not keep duplicate old non-DT data around
> now that we have the DT append support. Instead we should just
> require the .dts file appended to zImage for all mach-omap2
> machines. Otherwise we'll end up with double bloat :)

Mmm, I'm not sure to get your point. We are not duplicating, since a 
pure DT generic board will not have anything except a 
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
And the regular board files will keep initializing devices statically.
The drivers will then for the moment support both pdata and DT method to 
get board parameters.

> So it's OK to have the DT entries in board files so drivers
> that get converted will work with them.

Well, it will be a little bit more tricky, because having DT in current 
board files will be a mess with a bunch of #ifdef CONFIG_OF, and adding 
DT compatible inside each boards will prevent the pure generic DT one to 
work. In that case we will duplicate the DT migration in every legacy 
boards files...

That's why the current strategy is to keep the current board files 
non-DT aware and add the DT support only to the generic DT board file.

Regards,
Benoit

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Russell King - ARM Linux]

On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
> Now, that kernel.org is back, I'll pull you branches :-).

Umm.  Are you sure?  What are you checking - that some kernel.org
servers are reachable or that master.kernel.org is reachable (it
isn't.)

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Russell King - ARM Linux]

On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
> Now, that kernel.org is back, I'll pull you branches :-).

Umm.  Are you sure?  What are you checking - that some kernel.org
servers are reachable or that master.kernel.org is reachable (it
isn't.)

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>> Now, that kernel.org is back, I'll pull you branches :-).
>
> Umm.  Are you sure?  What are you checking - that some kernel.org
> servers are reachable or that master.kernel.org is reachable (it
> isn't.)

I was not about to fetch 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
yesterday, but it works today.

Benoit

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>> Now, that kernel.org is back, I'll pull you branches :-).
>
> Umm.  Are you sure?  What are you checking - that some kernel.org
> servers are reachable or that master.kernel.org is reachable (it
> isn't.)

I was not about to fetch 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
yesterday, but it works today.

Benoit

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Russell King - ARM Linux]

On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
> On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
>> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>>> Now, that kernel.org is back, I'll pull you branches :-).
>>
>> Umm.  Are you sure?  What are you checking - that some kernel.org
>> servers are reachable or that master.kernel.org is reachable (it
>> isn't.)
>
> I was not about to fetch  
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git  
> yesterday, but it works today.

git.kernel.org != master.kernel.org.

git.kernel.org is an alias for a set of servers which are selected
depending on your geographical location, whereas master.kernel.org
a single machine to which we upload our trees and which has been down
since Wednesday.  I don't believe master.kernel.org is part of the
public serving infrastructure (it certainly never used to be.)

So, I suspect your non-reachability of git.kernel.org yesterday was
due to some other problem.

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Russell King - ARM Linux]

On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
> On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
>> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>>> Now, that kernel.org is back, I'll pull you branches :-).
>>
>> Umm.  Are you sure?  What are you checking - that some kernel.org
>> servers are reachable or that master.kernel.org is reachable (it
>> isn't.)
>
> I was not about to fetch  
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git  
> yesterday, but it works today.

git.kernel.org != master.kernel.org.

git.kernel.org is an alias for a set of servers which are selected
depending on your geographical location, whereas master.kernel.org
a single machine to which we upload our trees and which has been down
since Wednesday.  I don't believe master.kernel.org is part of the
public serving infrastructure (it certainly never used to be.)

So, I suspect your non-reachability of git.kernel.org yesterday was
due to some other problem.

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

On 9/2/2011 11:21 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
>> On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
>>> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>>>> Now, that kernel.org is back, I'll pull you branches :-).
>>>
>>> Umm.  Are you sure?  What are you checking - that some kernel.org
>>> servers are reachable or that master.kernel.org is reachable (it
>>> isn't.)
>>
>> I was not about to fetch
>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
>> yesterday, but it works today.
>
> git.kernel.org != master.kernel.org.
>
> git.kernel.org is an alias for a set of servers which are selected
> depending on your geographical location, whereas master.kernel.org
> a single machine to which we upload our trees and which has been down
> since Wednesday.  I don't believe master.kernel.org is part of the
> public serving infrastructure (it certainly never used to be.)

Interesting, thanks for the explanations.

> So, I suspect your non-reachability of git.kernel.org yesterday was
> due to some other problem.

OK, maybe. The good point is that now it works :-)

The bad point is that Kevin cannot push his updated branches, so I still 
do not have the latest :-(

Thanks,
Benoit

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

On 9/2/2011 11:21 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
>> On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
>>> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>>>> Now, that kernel.org is back, I'll pull you branches :-).
>>>
>>> Umm.  Are you sure?  What are you checking - that some kernel.org
>>> servers are reachable or that master.kernel.org is reachable (it
>>> isn't.)
>>
>> I was not about to fetch
>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
>> yesterday, but it works today.
>
> git.kernel.org != master.kernel.org.
>
> git.kernel.org is an alias for a set of servers which are selected
> depending on your geographical location, whereas master.kernel.org
> a single machine to which we upload our trees and which has been down
> since Wednesday.  I don't believe master.kernel.org is part of the
> public serving infrastructure (it certainly never used to be.)

Interesting, thanks for the explanations.

> So, I suspect your non-reachability of git.kernel.org yesterday was
> due to some other problem.

OK, maybe. The good point is that now it works :-)

The bad point is that Kevin cannot push his updated branches, so I still 
do not have the latest :-(

Thanks,
Benoit

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 11:13]:
> Hi Tony,
> 
> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> >Hi,
> >
> >* Benoit Cousson<b-cousson@ti.com>  [110901 19:52]:
> >>Create an OMAP3 generic board to start the DT migration.
> >
> >I don't think this needs to be SoC specific, we can add multiple
> >DT_MACHINE_START entries into a single file. So it should be
> >just board-omap-dt.c.
> 
> I do agree, it should not, I made that comment into the
> board-omap4-dt.c, but for the moment we still have dedicated OMAP
> specifics stuff at board level, like the map_io.

Well map_io can also be set in DT_MACHINE_START. For most part
it already is generic like omap3_map_io and omap4_map_io.
So that should not stop anything.
 
> I have an other series that make the map_io DT aware to get rid of
> that, but it still not finalized.

Hmm maybe take a look again? We've already sorted out quite a bit
of the init stuff over past few merge windows. If there's still
something blocking that, let's clear it out ASAP.
 
> My goal was have a single DT_MACHINE_START for every OMAPs.
> But, meanwhile, if you prefer one file with many board descriptors,
> that's fine.

Yes that's better. We should only need a separate DT_MACHINE_START
for major SoC variants.

Regards,

Tony

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 11:13]:
> Hi Tony,
> 
> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> >Hi,
> >
> >* Benoit Cousson<b-cousson@ti.com>  [110901 19:52]:
> >>Create an OMAP3 generic board to start the DT migration.
> >
> >I don't think this needs to be SoC specific, we can add multiple
> >DT_MACHINE_START entries into a single file. So it should be
> >just board-omap-dt.c.
> 
> I do agree, it should not, I made that comment into the
> board-omap4-dt.c, but for the moment we still have dedicated OMAP
> specifics stuff at board level, like the map_io.

Well map_io can also be set in DT_MACHINE_START. For most part
it already is generic like omap3_map_io and omap4_map_io.
So that should not stop anything.
 
> I have an other series that make the map_io DT aware to get rid of
> that, but it still not finalized.

Hmm maybe take a look again? We've already sorted out quite a bit
of the init stuff over past few merge windows. If there's still
something blocking that, let's clear it out ASAP.
 
> My goal was have a single DT_MACHINE_START for every OMAPs.
> But, meanwhile, if you prefer one file with many board descriptors,
> that's fine.

Yes that's better. We should only need a separate DT_MACHINE_START
for major SoC variants.

Regards,

Tony

Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 11:26]:
> On 9/2/2011 10:12 AM, Tony Lindgren wrote:
> >* Benoit Cousson<b-cousson@ti.com>  [110901 19:52]:
> >>In order to avoid conflict with the new board-omap3-dt.c file,
> >>remove the .dt_compat entry from the beagle regular board
> >>file.
> >>
> >>Any DT work for OMAP3 will have to be done on the generic DT
> >>board file to avoid breaking the legacy board support until
> >>DT migration is done.
> >
> >In general we should not keep duplicate old non-DT data around
> >now that we have the DT append support. Instead we should just
> >require the .dts file appended to zImage for all mach-omap2
> >machines. Otherwise we'll end up with double bloat :)
> 
> Mmm, I'm not sure to get your point. We are not duplicating, since a
> pure DT generic board will not have anything except a
> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> And the regular board files will keep initializing devices statically.
> The drivers will then for the moment support both pdata and DT
> method to get board parameters.

Well when converting a driver to DT, we should just drop pdata
support. No need to keep it around as it will just make it harder
for us to clean up afterwards.
 
> >So it's OK to have the DT entries in board files so drivers
> >that get converted will work with them.
> 
> Well, it will be a little bit more tricky, because having DT in
> current board files will be a mess with a bunch of #ifdef CONFIG_OF,
> and adding DT compatible inside each boards will prevent the pure
> generic DT one to work. In that case we will duplicate the DT
> migration in every legacy boards files...

We should just select CONFIG_OF deal with it that way.
 
> That's why the current strategy is to keep the current board files
> non-DT aware and add the DT support only to the generic DT board
> file.

Well I don't like that, it will be a big mess. We'll end up with
twice the amount of platform_data and init code. It's OK to
require CONFIG_OF as it's known to work with the append support
for older boards.

It's easier just to require DT append for all the boards. In most
cases it's just a trivial include of the common dts file for now.

When we convert something to DT, there's no point going back.

Regards,

Tony

[PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 11:26]:
> On 9/2/2011 10:12 AM, Tony Lindgren wrote:
> >* Benoit Cousson<b-cousson@ti.com>  [110901 19:52]:
> >>In order to avoid conflict with the new board-omap3-dt.c file,
> >>remove the .dt_compat entry from the beagle regular board
> >>file.
> >>
> >>Any DT work for OMAP3 will have to be done on the generic DT
> >>board file to avoid breaking the legacy board support until
> >>DT migration is done.
> >
> >In general we should not keep duplicate old non-DT data around
> >now that we have the DT append support. Instead we should just
> >require the .dts file appended to zImage for all mach-omap2
> >machines. Otherwise we'll end up with double bloat :)
> 
> Mmm, I'm not sure to get your point. We are not duplicating, since a
> pure DT generic board will not have anything except a
> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> And the regular board files will keep initializing devices statically.
> The drivers will then for the moment support both pdata and DT
> method to get board parameters.

Well when converting a driver to DT, we should just drop pdata
support. No need to keep it around as it will just make it harder
for us to clean up afterwards.
 
> >So it's OK to have the DT entries in board files so drivers
> >that get converted will work with them.
> 
> Well, it will be a little bit more tricky, because having DT in
> current board files will be a mess with a bunch of #ifdef CONFIG_OF,
> and adding DT compatible inside each boards will prevent the pure
> generic DT one to work. In that case we will duplicate the DT
> migration in every legacy boards files...

We should just select CONFIG_OF deal with it that way.
 
> That's why the current strategy is to keep the current board files
> non-DT aware and add the DT support only to the generic DT board
> file.

Well I don't like that, it will be a big mess. We'll end up with
twice the amount of platform_data and init code. It's OK to
require CONFIG_OF as it's known to work with the append support
for older boards.

It's easier just to require DT append for all the boards. In most
cases it's just a trivial include of the common dts file for now.

When we convert something to DT, there's no point going back.

Regards,

Tony

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

On 9/2/2011 12:43 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110902 11:13]:
>> Hi Tony,
>>
>> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Benoit Cousson<b-cousson@ti.com>   [110901 19:52]:
>>>> Create an OMAP3 generic board to start the DT migration.
>>>
>>> I don't think this needs to be SoC specific, we can add multiple
>>> DT_MACHINE_START entries into a single file. So it should be
>>> just board-omap-dt.c.
>>
>> I do agree, it should not, I made that comment into the
>> board-omap4-dt.c, but for the moment we still have dedicated OMAP
>> specifics stuff at board level, like the map_io.
> 
> Well map_io can also be set in DT_MACHINE_START. For most part
> it already is generic like omap3_map_io and omap4_map_io.
> So that should not stop anything.

OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.

Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.

It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack. 
I will let the device-tree experts answering that question :-)
For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.

>> I have an other series that make the map_io DT aware to get rid of
>> that, but it still not finalized.
> 
> Hmm maybe take a look again? We've already sorted out quite a bit
> of the init stuff over past few merge windows. If there's still
> something blocking that, let's clear it out ASAP.

Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
The clear advantage of your method is that not further effort will be require for this part. At least for the moment.

>> My goal was have a single DT_MACHINE_START for every OMAPs.
>> But, meanwhile, if you prefer one file with many board descriptors,
>> that's fine.
> 
> Yes that's better. We should only need a separate DT_MACHINE_START
> for major SoC variants.

OK, I'll try that.

Thanks,
Benoit

---
>From a8edcd113b6fa38620dae11bcbb55daa84dfb07c Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Mon, 22 Aug 2011 11:10:38 +0200
Subject: [PATCH] OMAP2+: Add a common method to init globals using DT compatible

Thanks to the DT root node compatible information, we can extract
the compatible SoC and use it to select the proper globals.
Create a common omap2_set_globals API that can be used by every
OMAP2+ platforms.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/common.c             |   73 ++++++++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/common.h |    1 +
 2 files changed, 74 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 3f20cbb..ee5a225 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -16,6 +16,7 @@
 #include <linux/init.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <linux/of_fdt.h>
 
 #include <plat/common.h>
 #include <plat/board.h>
@@ -140,3 +141,75 @@ void __init omap2_set_globals_443x(void)
 }
 #endif
 
+#ifdef CONFIG_OF
+/*
+ * DT method to get the proper globals configuration
+ */
+static const struct of_device_id omap_soc_match[] = {
+#if defined(CONFIG_ARCH_OMAP4)
+        {
+                .compatible = "ti,omap4",
+                .data = &omap4_globals,
+        },
+#endif
+#if defined(CONFIG_ARCH_OMAP3)
+        {
+                .compatible = "ti,omap3",
+                .data = &omap3_globals,
+        },
+#endif
+#if defined(CONFIG_SOC_OMAP2430)
+        {
+                .compatible = "ti,omap2430",
+                .data = &omap243x_globals,
+        },
+#endif
+#if defined(CONFIG_SOC_OMAP2420)
+        {
+                .compatible = "ti,omap2420",
+                .data = &omap242x_globals,
+        },
+#endif
+	{},
+};
+
+/* Helper to find the proper of_device_id from a FDT */
+static __init const struct of_device_id *_fdt_match_node(
+					const struct of_device_id *matches,
+					int fdt_node)
+{
+	unsigned int score = 0;
+
+	if (!matches)
+		return NULL;
+
+	while (matches->compatible[0]) {
+		score = of_flat_dt_is_compatible(fdt_node, matches->compatible);
+		if (score > 0)
+			return matches;
+		matches++;
+	}
+	return NULL;
+}
+
+void __init omap2_set_globals(void)
+{
+        unsigned long fdt_root;
+	const struct of_device_id *match;
+
+	/* the DT is still flat at map_io time... */
+        fdt_root = of_get_flat_dt_root();
+	match = _fdt_match_node(omap_soc_match, fdt_root);
+	if (!match) {
+		pr_err("%s(): Cannot initialize the platform globals data\n",
+		       __func__);
+	}
+
+	pr_info("%s(): %s\n", __func__, match->compatible);
+
+	omap2_set_globals_tap(match->data);
+	omap2_set_globals_sdrc(match->data);
+	omap2_set_globals_control(match->data);
+	omap2_set_globals_prcm(match->data);
+}
+#endif
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index 4564cc6..fb79269 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -67,6 +67,7 @@ void omap2_set_globals_243x(void);
 void omap2_set_globals_3xxx(void);
 void omap2_set_globals_443x(void);
 void omap2_set_globals_ti816x(void);
+void omap2_set_globals(void);
 
 /* These get called from omap2_set_globals_xxxx(), do not call these */
 void omap2_set_globals_tap(struct omap_globals *);
-- 
1.7.0.4

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

On 9/2/2011 12:43 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110902 11:13]:
>> Hi Tony,
>>
>> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Benoit Cousson<b-cousson@ti.com>   [110901 19:52]:
>>>> Create an OMAP3 generic board to start the DT migration.
>>>
>>> I don't think this needs to be SoC specific, we can add multiple
>>> DT_MACHINE_START entries into a single file. So it should be
>>> just board-omap-dt.c.
>>
>> I do agree, it should not, I made that comment into the
>> board-omap4-dt.c, but for the moment we still have dedicated OMAP
>> specifics stuff at board level, like the map_io.
> 
> Well map_io can also be set in DT_MACHINE_START. For most part
> it already is generic like omap3_map_io and omap4_map_io.
> So that should not stop anything.

OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.

Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.

It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack. 
I will let the device-tree experts answering that question :-)
For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.

>> I have an other series that make the map_io DT aware to get rid of
>> that, but it still not finalized.
> 
> Hmm maybe take a look again? We've already sorted out quite a bit
> of the init stuff over past few merge windows. If there's still
> something blocking that, let's clear it out ASAP.

Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
The clear advantage of your method is that not further effort will be require for this part. At least for the moment.

>> My goal was have a single DT_MACHINE_START for every OMAPs.
>> But, meanwhile, if you prefer one file with many board descriptors,
>> that's fine.
> 
> Yes that's better. We should only need a separate DT_MACHINE_START
> for major SoC variants.

OK, I'll try that.

Thanks,
Benoit

---

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 14:10]:
> On 9/2/2011 12:43 PM, Tony Lindgren wrote:
> > * Cousson, Benoit<b-cousson@ti.com>  [110902 11:13]:
> >> Hi Tony,
> >>
> >> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> >>> Hi,
> >>>
> >>> * Benoit Cousson<b-cousson@ti.com>   [110901 19:52]:
> >>>> Create an OMAP3 generic board to start the DT migration.
> >>>
> >>> I don't think this needs to be SoC specific, we can add multiple
> >>> DT_MACHINE_START entries into a single file. So it should be
> >>> just board-omap-dt.c.
> >>
> >> I do agree, it should not, I made that comment into the
> >> board-omap4-dt.c, but for the moment we still have dedicated OMAP
> >> specifics stuff at board level, like the map_io.
> > 
> > Well map_io can also be set in DT_MACHINE_START. For most part
> > it already is generic like omap3_map_io and omap4_map_io.
> > So that should not stop anything.
> 
> OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
> Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.
>
> Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.

Sure that can be changed. But why not get the whole data that's
now in various structs from DT too? It's just something like:

        .class  = OMAP243X_CLASS,
        .tap    = OMAP2_L4_IO_ADDRESS(0x4900a000),
        .sdrc   = OMAP243X_SDRC_BASE,
        .sms    = OMAP243X_SMS_BASE,
        .ctrl   = OMAP243X_CTRL_BASE,
        .prm    = OMAP2430_PRM_BASE,
        .cm     = OMAP2430_CM_BASE,

And all these could be just defined in DT right?
 
> It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack. 
> I will let the device-tree experts answering that question :-)
> For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.

Sure I agree.
 
> >> I have an other series that make the map_io DT aware to get rid of
> >> that, but it still not finalized.
> > 
> > Hmm maybe take a look again? We've already sorted out quite a bit
> > of the init stuff over past few merge windows. If there's still
> > something blocking that, let's clear it out ASAP.
> 
> Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
> The clear advantage of your method is that not further effort will be require for this part. At least for the moment.

Well I guess the globals could come from device tree still :)

In general, I'd like to get rid of the cpu_is_omapxxxx stuff
and SoC detection early as that always requires DEBUG_LL to
see any decent debug info when things go wrong.

If we get the SoC major type from DT, then we only need to
do SoC specific ES revision and GP/HS omap detection. And that's
very simple code compared to the current cpu_is_omapxxxx stuff.

Then we can boot with the DT information pretty far to map_io
and initialize low-level serial console, and then set up things
further while having a decent console ;)

Regards,

Tony

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 14:10]:
> On 9/2/2011 12:43 PM, Tony Lindgren wrote:
> > * Cousson, Benoit<b-cousson@ti.com>  [110902 11:13]:
> >> Hi Tony,
> >>
> >> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> >>> Hi,
> >>>
> >>> * Benoit Cousson<b-cousson@ti.com>   [110901 19:52]:
> >>>> Create an OMAP3 generic board to start the DT migration.
> >>>
> >>> I don't think this needs to be SoC specific, we can add multiple
> >>> DT_MACHINE_START entries into a single file. So it should be
> >>> just board-omap-dt.c.
> >>
> >> I do agree, it should not, I made that comment into the
> >> board-omap4-dt.c, but for the moment we still have dedicated OMAP
> >> specifics stuff at board level, like the map_io.
> > 
> > Well map_io can also be set in DT_MACHINE_START. For most part
> > it already is generic like omap3_map_io and omap4_map_io.
> > So that should not stop anything.
> 
> OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
> Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.
>
> Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.

Sure that can be changed. But why not get the whole data that's
now in various structs from DT too? It's just something like:

        .class  = OMAP243X_CLASS,
        .tap    = OMAP2_L4_IO_ADDRESS(0x4900a000),
        .sdrc   = OMAP243X_SDRC_BASE,
        .sms    = OMAP243X_SMS_BASE,
        .ctrl   = OMAP243X_CTRL_BASE,
        .prm    = OMAP2430_PRM_BASE,
        .cm     = OMAP2430_CM_BASE,

And all these could be just defined in DT right?
 
> It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack. 
> I will let the device-tree experts answering that question :-)
> For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.

Sure I agree.
 
> >> I have an other series that make the map_io DT aware to get rid of
> >> that, but it still not finalized.
> > 
> > Hmm maybe take a look again? We've already sorted out quite a bit
> > of the init stuff over past few merge windows. If there's still
> > something blocking that, let's clear it out ASAP.
> 
> Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
> The clear advantage of your method is that not further effort will be require for this part. At least for the moment.

Well I guess the globals could come from device tree still :)

In general, I'd like to get rid of the cpu_is_omapxxxx stuff
and SoC detection early as that always requires DEBUG_LL to
see any decent debug info when things go wrong.

If we get the SoC major type from DT, then we only need to
do SoC specific ES revision and GP/HS omap detection. And that's
very simple code compared to the current cpu_is_omapxxxx stuff.

Then we can boot with the DT information pretty far to map_io
and initialize low-level serial console, and then set up things
further while having a decent console ;)

Regards,

Tony

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

On 9/2/2011 1:57 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110902 14:10]:
>> On 9/2/2011 12:43 PM, Tony Lindgren wrote:
>>> * Cousson, Benoit<b-cousson@ti.com>   [110902 11:13]:
>>>> Hi Tony,
>>>>
>>>> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
>>>>> Hi,
>>>>>
>>>>> * Benoit Cousson<b-cousson@ti.com>    [110901 19:52]:
>>>>>> Create an OMAP3 generic board to start the DT migration.
>>>>>
>>>>> I don't think this needs to be SoC specific, we can add multiple
>>>>> DT_MACHINE_START entries into a single file. So it should be
>>>>> just board-omap-dt.c.
>>>>
>>>> I do agree, it should not, I made that comment into the
>>>> board-omap4-dt.c, but for the moment we still have dedicated OMAP
>>>> specifics stuff at board level, like the map_io.
>>>
>>> Well map_io can also be set in DT_MACHINE_START. For most part
>>> it already is generic like omap3_map_io and omap4_map_io.
>>> So that should not stop anything.
>>
>> OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
>> Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.
>>
>> Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.
>
> Sure that can be changed. But why not get the whole data that's
> now in various structs from DT too? It's just something like:
>
>          .class  = OMAP243X_CLASS,
>          .tap    = OMAP2_L4_IO_ADDRESS(0x4900a000),

BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS?

>          .sdrc   = OMAP243X_SDRC_BASE,
>          .sms    = OMAP243X_SMS_BASE,
>          .ctrl   = OMAP243X_CTRL_BASE,
>          .prm    = OMAP2430_PRM_BASE,
>          .cm     = OMAP2430_CM_BASE,
>
> And all these could be just defined in DT right?

Hehe, it is just a phase-one-proof-of-concept... the phase two was 
supposed to move that to DT. But for the moment, I was trying to have a 
more conservative approach using the existing data like for hwmod.

The other point is that we still have to deal with the FDT at that 
point, the DT is not yest available that why I didn't extract too many 
informations from the FDT.
Moreover, in theory, these informations will not be mixed like today, 
but will be in their own relevant DT nodes, somewhere inside the tree.
Bottomline... it was a little bit more tricky.

>> It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack.
>> I will let the device-tree experts answering that question :-)
>> For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.
>
> Sure I agree.
>
>>>> I have an other series that make the map_io DT aware to get rid of
>>>> that, but it still not finalized.
>>>
>>> Hmm maybe take a look again? We've already sorted out quite a bit
>>> of the init stuff over past few merge windows. If there's still
>>> something blocking that, let's clear it out ASAP.
>>
>> Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
>> The clear advantage of your method is that not further effort will be require for this part. At least for the moment.
>
> Well I guess the globals could come from device tree still :)

Fully agree. It just needs some more time :-)

> In general, I'd like to get rid of the cpu_is_omapxxxx stuff
> and SoC detection early as that always requires DEBUG_LL to
> see any decent debug info when things go wrong.
>
> If we get the SoC major type from DT, then we only need to
> do SoC specific ES revision and GP/HS omap detection. And that's
> very simple code compared to the current cpu_is_omapxxxx stuff.

In fact only the tap should be required at map_io time to get the 
DEVICE_ID, I guess that the others entries could be retrieve later?

           .sdrc   = OMAP243X_SDRC_BASE,
           .sms    = OMAP243X_SMS_BASE,
           .ctrl   = OMAP243X_CTRL_BASE,
           .prm    = OMAP2430_PRM_BASE,
           .cm     = OMAP2430_CM_BASE,

If this is the case, we can then add a DEVICE_ID address entry in DT 
root to be retrieved easily with the FDT.

> Then we can boot with the DT information pretty far to map_io
> and initialize low-level serial console, and then set up things
> further while having a decent console ;)

Yeah! The holy grail.

Benoit

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Cousson, Benoit]

On 9/2/2011 1:57 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110902 14:10]:
>> On 9/2/2011 12:43 PM, Tony Lindgren wrote:
>>> * Cousson, Benoit<b-cousson@ti.com>   [110902 11:13]:
>>>> Hi Tony,
>>>>
>>>> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
>>>>> Hi,
>>>>>
>>>>> * Benoit Cousson<b-cousson@ti.com>    [110901 19:52]:
>>>>>> Create an OMAP3 generic board to start the DT migration.
>>>>>
>>>>> I don't think this needs to be SoC specific, we can add multiple
>>>>> DT_MACHINE_START entries into a single file. So it should be
>>>>> just board-omap-dt.c.
>>>>
>>>> I do agree, it should not, I made that comment into the
>>>> board-omap4-dt.c, but for the moment we still have dedicated OMAP
>>>> specifics stuff at board level, like the map_io.
>>>
>>> Well map_io can also be set in DT_MACHINE_START. For most part
>>> it already is generic like omap3_map_io and omap4_map_io.
>>> So that should not stop anything.
>>
>> OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
>> Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.
>>
>> Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.
>
> Sure that can be changed. But why not get the whole data that's
> now in various structs from DT too? It's just something like:
>
>          .class  = OMAP243X_CLASS,
>          .tap    = OMAP2_L4_IO_ADDRESS(0x4900a000),

BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS?

>          .sdrc   = OMAP243X_SDRC_BASE,
>          .sms    = OMAP243X_SMS_BASE,
>          .ctrl   = OMAP243X_CTRL_BASE,
>          .prm    = OMAP2430_PRM_BASE,
>          .cm     = OMAP2430_CM_BASE,
>
> And all these could be just defined in DT right?

Hehe, it is just a phase-one-proof-of-concept... the phase two was 
supposed to move that to DT. But for the moment, I was trying to have a 
more conservative approach using the existing data like for hwmod.

The other point is that we still have to deal with the FDT at that 
point, the DT is not yest available that why I didn't extract too many 
informations from the FDT.
Moreover, in theory, these informations will not be mixed like today, 
but will be in their own relevant DT nodes, somewhere inside the tree.
Bottomline... it was a little bit more tricky.

>> It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack.
>> I will let the device-tree experts answering that question :-)
>> For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.
>
> Sure I agree.
>
>>>> I have an other series that make the map_io DT aware to get rid of
>>>> that, but it still not finalized.
>>>
>>> Hmm maybe take a look again? We've already sorted out quite a bit
>>> of the init stuff over past few merge windows. If there's still
>>> something blocking that, let's clear it out ASAP.
>>
>> Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
>> The clear advantage of your method is that not further effort will be require for this part. At least for the moment.
>
> Well I guess the globals could come from device tree still :)

Fully agree. It just needs some more time :-)

> In general, I'd like to get rid of the cpu_is_omapxxxx stuff
> and SoC detection early as that always requires DEBUG_LL to
> see any decent debug info when things go wrong.
>
> If we get the SoC major type from DT, then we only need to
> do SoC specific ES revision and GP/HS omap detection. And that's
> very simple code compared to the current cpu_is_omapxxxx stuff.

In fact only the tap should be required at map_io time to get the 
DEVICE_ID, I guess that the others entries could be retrieve later?

           .sdrc   = OMAP243X_SDRC_BASE,
           .sms    = OMAP243X_SMS_BASE,
           .ctrl   = OMAP243X_CTRL_BASE,
           .prm    = OMAP2430_PRM_BASE,
           .cm     = OMAP2430_CM_BASE,

If this is the case, we can then add a DEVICE_ID address entry in DT 
root to be retrieved easily with the FDT.

> Then we can boot with the DT information pretty far to map_io
> and initialize low-level serial console, and then set up things
> further while having a decent console ;)

Yeah! The holy grail.

Benoit

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 14:47]:
> >         .tap    = OMAP2_L4_IO_ADDRESS(0x4900a000),
> 
> BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS?

That needs to be mapped early for SoC detection to work
for cpu_is_omapxxxx stuff :(
 
> In fact only the tap should be required at map_io time to get the
> DEVICE_ID, I guess that the others entries could be retrieve later?

Yes well whatever needs to be mapped early for the SoC
revision detection. It could be that we can map timers
and serial port only early, then set up the mappings for
the rest later on. That is if we can avoid SoC and revision
detection early.

Tony

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 14:47]:
> >         .tap    = OMAP2_L4_IO_ADDRESS(0x4900a000),
> 
> BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS?

That needs to be mapped early for SoC detection to work
for cpu_is_omapxxxx stuff :(
 
> In fact only the tap should be required at map_io time to get the
> DEVICE_ID, I guess that the others entries could be retrieve later?

Yes well whatever needs to be mapped early for the SoC
revision detection. It could be that we can map timers
and serial port only early, then set up the mappings for
the rest later on. That is if we can avoid SoC and revision
detection early.

Tony

Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Cousson, Benoit]

On 9/2/2011 12:48 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110902 11:26]:
>> On 9/2/2011 10:12 AM, Tony Lindgren wrote:
>>> * Benoit Cousson<b-cousson@ti.com>   [110901 19:52]:
>>>> In order to avoid conflict with the new board-omap3-dt.c file,
>>>> remove the .dt_compat entry from the beagle regular board
>>>> file.
>>>>
>>>> Any DT work for OMAP3 will have to be done on the generic DT
>>>> board file to avoid breaking the legacy board support until
>>>> DT migration is done.
>>>
>>> In general we should not keep duplicate old non-DT data around
>>> now that we have the DT append support. Instead we should just
>>> require the .dts file appended to zImage for all mach-omap2
>>> machines. Otherwise we'll end up with double bloat :)
>>
>> Mmm, I'm not sure to get your point. We are not duplicating, since a
>> pure DT generic board will not have anything except a
>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>> And the regular board files will keep initializing devices statically.
>> The drivers will then for the moment support both pdata and DT
>> method to get board parameters.
>
> Well when converting a driver to DT, we should just drop pdata
> support. No need to keep it around as it will just make it harder
> for us to clean up afterwards.

I'm not sure it is that simple. We have 20+ OMAP3+ boards supported so 
far. Dropping pdata when a driver is adapted means that all these boards 
should be properly adapted to DT and tested... (board-XXX.dts + 
board-XXX.c).
That's a huge effort for my point of view. Whereas keeping the legacy 
pdata method will allow progressing on the boart-dt only without 
breaking any legacy boards. It will allow the board manufacturers to 
potentially do the DTS file for their own system using then the generic 
board-dt.c file.

That being said, keeping the legacy pdata code in some driver along with 
the DT is a big pain as well:-(
In some cases, DT can even provide some good way to encode HW 
information that we do not have today with hwmod/omap_device. So in that 
case we do not even have any alternative method yet.

>>> So it's OK to have the DT entries in board files so drivers
>>> that get converted will work with them.
>>
>> Well, it will be a little bit more tricky, because having DT in
>> current board files will be a mess with a bunch of #ifdef CONFIG_OF,
>> and adding DT compatible inside each boards will prevent the pure
>> generic DT one to work. In that case we will duplicate the DT
>> migration in every legacy boards files...
>
> We should just select CONFIG_OF deal with it that way.
>
>> That's why the current strategy is to keep the current board files
>> non-DT aware and add the DT support only to the generic DT board
>> file.
>
> Well I don't like that, it will be a big mess. We'll end up with
> twice the amount of platform_data and init code. It's OK to
> require CONFIG_OF as it's known to work with the append support
> for older boards.
>
> It's easier just to require DT append for all the boards. In most
> cases it's just a trivial include of the common dts file for now.

That part is easy indeed, this is hacking every board-XXX.c and testing 
them that will be tricky. This is as well the board specifics settings 
that are tricky not the generic OMAP stuff. We do have to set GPIOs, pin 
mux, regulator bindings, audio codec stuff...

> When we convert something to DT, there's no point going back.

Agree on that, in theory, I'm just wondering how practical it will be to 
progress on every board at the same time.

I guess we do need some advice from the DT gurus on that as well.

It looks to me that both approaches are painful and will require some 
efforts.
It is too bad that nobody did a 
devicetree-migration-o-matic-for-lazy-developer.py script to handle that...

Regards,
Benoit

[PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Cousson, Benoit]

On 9/2/2011 12:48 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110902 11:26]:
>> On 9/2/2011 10:12 AM, Tony Lindgren wrote:
>>> * Benoit Cousson<b-cousson@ti.com>   [110901 19:52]:
>>>> In order to avoid conflict with the new board-omap3-dt.c file,
>>>> remove the .dt_compat entry from the beagle regular board
>>>> file.
>>>>
>>>> Any DT work for OMAP3 will have to be done on the generic DT
>>>> board file to avoid breaking the legacy board support until
>>>> DT migration is done.
>>>
>>> In general we should not keep duplicate old non-DT data around
>>> now that we have the DT append support. Instead we should just
>>> require the .dts file appended to zImage for all mach-omap2
>>> machines. Otherwise we'll end up with double bloat :)
>>
>> Mmm, I'm not sure to get your point. We are not duplicating, since a
>> pure DT generic board will not have anything except a
>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>> And the regular board files will keep initializing devices statically.
>> The drivers will then for the moment support both pdata and DT
>> method to get board parameters.
>
> Well when converting a driver to DT, we should just drop pdata
> support. No need to keep it around as it will just make it harder
> for us to clean up afterwards.

I'm not sure it is that simple. We have 20+ OMAP3+ boards supported so 
far. Dropping pdata when a driver is adapted means that all these boards 
should be properly adapted to DT and tested... (board-XXX.dts + 
board-XXX.c).
That's a huge effort for my point of view. Whereas keeping the legacy 
pdata method will allow progressing on the boart-dt only without 
breaking any legacy boards. It will allow the board manufacturers to 
potentially do the DTS file for their own system using then the generic 
board-dt.c file.

That being said, keeping the legacy pdata code in some driver along with 
the DT is a big pain as well:-(
In some cases, DT can even provide some good way to encode HW 
information that we do not have today with hwmod/omap_device. So in that 
case we do not even have any alternative method yet.

>>> So it's OK to have the DT entries in board files so drivers
>>> that get converted will work with them.
>>
>> Well, it will be a little bit more tricky, because having DT in
>> current board files will be a mess with a bunch of #ifdef CONFIG_OF,
>> and adding DT compatible inside each boards will prevent the pure
>> generic DT one to work. In that case we will duplicate the DT
>> migration in every legacy boards files...
>
> We should just select CONFIG_OF deal with it that way.
>
>> That's why the current strategy is to keep the current board files
>> non-DT aware and add the DT support only to the generic DT board
>> file.
>
> Well I don't like that, it will be a big mess. We'll end up with
> twice the amount of platform_data and init code. It's OK to
> require CONFIG_OF as it's known to work with the append support
> for older boards.
>
> It's easier just to require DT append for all the boards. In most
> cases it's just a trivial include of the common dts file for now.

That part is easy indeed, this is hacking every board-XXX.c and testing 
them that will be tricky. This is as well the board specifics settings 
that are tricky not the generic OMAP stuff. We do have to set GPIOs, pin 
mux, regulator bindings, audio codec stuff...

> When we convert something to DT, there's no point going back.

Agree on that, in theory, I'm just wondering how practical it will be to 
progress on every board at the same time.

I guess we do need some advice from the DT gurus on that as well.

It looks to me that both approaches are painful and will require some 
efforts.
It is too bad that nobody did a 
devicetree-migration-o-matic-for-lazy-developer.py script to handle that...

Regards,
Benoit

Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 15:02]:
> On 9/2/2011 12:48 PM, Tony Lindgren wrote:
> 
> I'm not sure it is that simple. We have 20+ OMAP3+ boards supported
> so far. Dropping pdata when a driver is adapted means that all these
> boards should be properly adapted to DT and tested... (board-XXX.dts
> + board-XXX.c).
> That's a huge effort for my point of view. Whereas keeping the
> legacy pdata method will allow progressing on the boart-dt only
> without breaking any legacy boards. It will allow the board
> manufacturers to potentially do the DTS file for their own system
> using then the generic board-dt.c file.

Yeah but we've seen how badly "we'll clean it up later" approach
works :(

Unfortunately that path means nobody comes back to clean-up
anything after the party is over and all that work falls on the
maintainers.

So the one driver at a time conversion approach is better.
 
> That being said, keeping the legacy pdata code in some driver along
> with the DT is a big pain as well:-(

Yup and duplicate data will lead to nasty bugs and support issues.

> >It's easier just to require DT append for all the boards. In most
> >cases it's just a trivial include of the common dts file for now.
> 
> That part is easy indeed, this is hacking every board-XXX.c and
> testing them that will be tricky. This is as well the board
> specifics settings that are tricky not the generic OMAP stuff. We do
> have to set GPIOs, pin mux, regulator bindings, audio codec stuff...

Right but for most part it's just removing the data. The board
specific things are usually number of MMC data lines, number of
USB transceiver data lines, GPIO to enable etc. Pretty trivial
stuff that the board maintainers can test.
 
> >When we convert something to DT, there's no point going back.
> 
> Agree on that, in theory, I'm just wondering how practical it will
> be to progress on every board at the same time.

That should not be too bad for most part. For example, the board-*.c
files all just call  omap_register_i2c_bus with the controllers.
So not much there to convert, just add the controllers to board
.dts files and remove from board-*.c files.
 
> I guess we do need some advice from the DT gurus on that as well.
> 
> It looks to me that both approaches are painful and will require
> some efforts.

Yes, but if we don't drop the pdata then we'll be in half-converted
state eternally.

> It is too bad that nobody did a
> devicetree-migration-o-matic-for-lazy-developer.py script to handle
> that...

The conversion for some drivers can be scripted for sure :)

Regards,

Tony

[PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110902 15:02]:
> On 9/2/2011 12:48 PM, Tony Lindgren wrote:
> 
> I'm not sure it is that simple. We have 20+ OMAP3+ boards supported
> so far. Dropping pdata when a driver is adapted means that all these
> boards should be properly adapted to DT and tested... (board-XXX.dts
> + board-XXX.c).
> That's a huge effort for my point of view. Whereas keeping the
> legacy pdata method will allow progressing on the boart-dt only
> without breaking any legacy boards. It will allow the board
> manufacturers to potentially do the DTS file for their own system
> using then the generic board-dt.c file.

Yeah but we've seen how badly "we'll clean it up later" approach
works :(

Unfortunately that path means nobody comes back to clean-up
anything after the party is over and all that work falls on the
maintainers.

So the one driver at a time conversion approach is better.
 
> That being said, keeping the legacy pdata code in some driver along
> with the DT is a big pain as well:-(

Yup and duplicate data will lead to nasty bugs and support issues.

> >It's easier just to require DT append for all the boards. In most
> >cases it's just a trivial include of the common dts file for now.
> 
> That part is easy indeed, this is hacking every board-XXX.c and
> testing them that will be tricky. This is as well the board
> specifics settings that are tricky not the generic OMAP stuff. We do
> have to set GPIOs, pin mux, regulator bindings, audio codec stuff...

Right but for most part it's just removing the data. The board
specific things are usually number of MMC data lines, number of
USB transceiver data lines, GPIO to enable etc. Pretty trivial
stuff that the board maintainers can test.
 
> >When we convert something to DT, there's no point going back.
> 
> Agree on that, in theory, I'm just wondering how practical it will
> be to progress on every board at the same time.

That should not be too bad for most part. For example, the board-*.c
files all just call  omap_register_i2c_bus with the controllers.
So not much there to convert, just add the controllers to board
.dts files and remove from board-*.c files.
 
> I guess we do need some advice from the DT gurus on that as well.
> 
> It looks to me that both approaches are painful and will require
> some efforts.

Yes, but if we don't drop the pdata then we'll be in half-converted
state eternally.

> It is too bad that nobody did a
> devicetree-migration-o-matic-for-lazy-developer.py script to handle
> that...

The conversion for some drivers can be scripted for sure :)

Regards,

Tony

Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[G, Manjunath Kondaiah]

Minor comments:

On Thu, Sep 01, 2011 at 07:25:11PM +0200, Benoit Cousson wrote:
> Create an OMAP3 generic board to start the DT migration.
> 
> This file is doing the minimal initialization needed to boot
> properly on a RAMDISK filesystem.
> 
> As soon as the OMAP3 specifics will be removed, that board will
> be converted to an even more generic board-dt.c that will support
> every OMAP2+ platforms.
> 
> Based on original patch from Manju:
> http://www.spinics.net/lists/linux-omap/msg55832.html
> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
>  arch/arm/mach-omap2/Kconfig          |   10 +++++
>  arch/arm/mach-omap2/Makefile         |    1 +
>  arch/arm/mach-omap2/board-omap3-dt.c |   74 ++++++++++++++++++++++++++++++++++
>  3 files changed, 85 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 5d501d2..82f0df2 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -305,6 +305,16 @@ config MACH_OMAP_3630SDP
>  	default y
>  	select OMAP_PACKAGE_CBP
>  
> +config MACH_OMAP3_DT
> +	bool "Generic OMAP3 board (FDT support)"
> +	depends on ARCH_OMAP3
> +	select OMAP_PACKAGE_CBB
> +	select USE_OF
> +	help
> +	  Support for generic TI OMAP3 boards using Flattened Device Tree.
> +	  Say Y here to enable OMAP3 device tree support
> +	  More information at Documentation/devicetree
> +
>  config MACH_TI8168EVM
>  	bool "TI8168 Evaluation Module"
>  	depends on SOC_OMAPTI816X
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 6ab9116..5144c17 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -197,6 +197,7 @@ obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
>  obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o
>  obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o
>  obj-$(CONFIG_MACH_OMAP_3430SDP)		+= board-3430sdp.o
> +obj-$(CONFIG_MACH_OMAP3_DT)		+= board-omap3-dt.o
>  obj-$(CONFIG_MACH_NOKIA_N8X0)		+= board-n8x0.o
>  obj-$(CONFIG_MACH_NOKIA_RM680)		+= board-rm680.o \
>  					   sdram-nokia.o
> diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
> new file mode 100644
> index 0000000..6eb56c6
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-omap3-dt.c
> @@ -0,0 +1,74 @@
> +/*
> + * OMAP3 Device tree boards support
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/irqdomain.h>
> +#include <linux/of_platform.h>
> +#include <linux/i2c/twl.h>
this header is redundant
> +
> +#include <asm/mach/arch.h>
> +#include <plat/common.h>
> +
> +#include "mux.h"
> +#include "common-board-devices.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +
extra blank line

-M
> +static void __init omap3_init_early(void)
> +{
> +	omap2_init_common_infrastructure();
> +	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
> +				  mt46h32m32lf6_sdrc_params);
> +}
> +
> +#ifdef CONFIG_OMAP_MUX
> +static struct omap_board_mux board_mux[] __initdata = {
> +	{ .reg_offset = OMAP_MUX_TERMINATOR },
> +};
> +#endif
> +
> +static struct of_device_id omap_dt_match_table[] __initdata = {
> +	{ .compatible = "simple-bus", },
> +	{ .compatible = "ti,omap-infra", },
> +	{}
> +};
> +
> +static struct of_device_id omap_dt_intc_match[] __initdata = {
> +	{ .compatible = "ti,omap3-intc", },
> +	{}
> +};
> +
> +static void __init omap3_init(void)
> +{
> +	struct device_node *node;
> +
> +	node = of_find_matching_node(NULL, omap_dt_intc_match);
> +	if (node)
> +		irq_domain_add_simple(node, 0);
> +
> +	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> +	omap_serial_init();
> +
> +	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> +	"ti,omap3",
> +	NULL
> +};
> +
> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> +	.reserve	= omap_reserve,
> +	.map_io		= omap3_map_io,
> +	.init_early	= omap3_init_early,
> +	.init_irq	= omap3_init_irq,
> +	.init_machine	= omap3_init,
> +	.timer		= &omap3_timer,
> +	.dt_compat	= omap3_dt_match,
> +MACHINE_END
> -- 
> 1.7.0.4
> 

[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support

[G, Manjunath Kondaiah]

Minor comments:

On Thu, Sep 01, 2011 at 07:25:11PM +0200, Benoit Cousson wrote:
> Create an OMAP3 generic board to start the DT migration.
> 
> This file is doing the minimal initialization needed to boot
> properly on a RAMDISK filesystem.
> 
> As soon as the OMAP3 specifics will be removed, that board will
> be converted to an even more generic board-dt.c that will support
> every OMAP2+ platforms.
> 
> Based on original patch from Manju:
> http://www.spinics.net/lists/linux-omap/msg55832.html
> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
>  arch/arm/mach-omap2/Kconfig          |   10 +++++
>  arch/arm/mach-omap2/Makefile         |    1 +
>  arch/arm/mach-omap2/board-omap3-dt.c |   74 ++++++++++++++++++++++++++++++++++
>  3 files changed, 85 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 5d501d2..82f0df2 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -305,6 +305,16 @@ config MACH_OMAP_3630SDP
>  	default y
>  	select OMAP_PACKAGE_CBP
>  
> +config MACH_OMAP3_DT
> +	bool "Generic OMAP3 board (FDT support)"
> +	depends on ARCH_OMAP3
> +	select OMAP_PACKAGE_CBB
> +	select USE_OF
> +	help
> +	  Support for generic TI OMAP3 boards using Flattened Device Tree.
> +	  Say Y here to enable OMAP3 device tree support
> +	  More information at Documentation/devicetree
> +
>  config MACH_TI8168EVM
>  	bool "TI8168 Evaluation Module"
>  	depends on SOC_OMAPTI816X
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 6ab9116..5144c17 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -197,6 +197,7 @@ obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
>  obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o
>  obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o
>  obj-$(CONFIG_MACH_OMAP_3430SDP)		+= board-3430sdp.o
> +obj-$(CONFIG_MACH_OMAP3_DT)		+= board-omap3-dt.o
>  obj-$(CONFIG_MACH_NOKIA_N8X0)		+= board-n8x0.o
>  obj-$(CONFIG_MACH_NOKIA_RM680)		+= board-rm680.o \
>  					   sdram-nokia.o
> diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
> new file mode 100644
> index 0000000..6eb56c6
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-omap3-dt.c
> @@ -0,0 +1,74 @@
> +/*
> + * OMAP3 Device tree boards support
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/irqdomain.h>
> +#include <linux/of_platform.h>
> +#include <linux/i2c/twl.h>
this header is redundant
> +
> +#include <asm/mach/arch.h>
> +#include <plat/common.h>
> +
> +#include "mux.h"
> +#include "common-board-devices.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +
extra blank line

-M
> +static void __init omap3_init_early(void)
> +{
> +	omap2_init_common_infrastructure();
> +	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
> +				  mt46h32m32lf6_sdrc_params);
> +}
> +
> +#ifdef CONFIG_OMAP_MUX
> +static struct omap_board_mux board_mux[] __initdata = {
> +	{ .reg_offset = OMAP_MUX_TERMINATOR },
> +};
> +#endif
> +
> +static struct of_device_id omap_dt_match_table[] __initdata = {
> +	{ .compatible = "simple-bus", },
> +	{ .compatible = "ti,omap-infra", },
> +	{}
> +};
> +
> +static struct of_device_id omap_dt_intc_match[] __initdata = {
> +	{ .compatible = "ti,omap3-intc", },
> +	{}
> +};
> +
> +static void __init omap3_init(void)
> +{
> +	struct device_node *node;
> +
> +	node = of_find_matching_node(NULL, omap_dt_intc_match);
> +	if (node)
> +		irq_domain_add_simple(node, 0);
> +
> +	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> +	omap_serial_init();
> +
> +	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> +	"ti,omap3",
> +	NULL
> +};
> +
> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> +	.reserve	= omap_reserve,
> +	.map_io		= omap3_map_io,
> +	.init_early	= omap3_init_early,
> +	.init_irq	= omap3_init_irq,
> +	.init_machine	= omap3_init,
> +	.timer		= &omap3_timer,
> +	.dt_compat	= omap3_dt_match,
> +MACHINE_END
> -- 
> 1.7.0.4
> 

Re: [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Cousson, Benoit]

Hi Arnd,

On 9/1/2011 8:17 PM, Arnd Bergmann wrote:
> On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote:
>>
>>          /*
>> +        * XXX: The cpus node is mandatory, but since the CPUs are as well part
>> +        * of the mpu subsystem below, it is not clear where the information
>> +        * should be. Maybe here with a phandle inside the mpu?
>> +        */
>> +       cpus {
>> +       };
>> +
>> +       /*
>>           * The soc node represents the soc top level view. It is uses for IPs
>>           * that are not memory mapped in the MPU view or for the MPU itself.
>>           */
>>          soc {
>>                  compatible = "ti,omap-infra";
>> +               mpu {
>> +                       compatible = "ti,omap3-mpu";
>> +                       hwmods = "mpu";
>> +                       cpu@0 {
>> +                               compatible = "arm,cortex-a8";
>> +                       };
>> +               };
>> +
>
> I would always put the cpu nodes in the top-level, even if that's
> a slight misrepresentation of the truth. The point is basically
> that CPU nodes are special (you cannot have device drivers for them)
> and that the device tree is basically laid out from the perspective
> of the CPU, which may be different from the perspective that a
> hardware designer has.

Yeah, I saw that in the "cpus" node documentation. My point here is that 
I do need to represent the MPU subsystem that will contain the cpus. And 
thus the Cortex is inside the MPU subsystem.

I can potentially keep the CPUs inside the cpus node, and just represent 
the mpu node inside the soc, with potentially some phandle to the real 
cpu nodes.

Something like that:

cpus {
	cpu0: cpu@0 {
			compatible = "arm,cortex-a8";
	};
};

[...]

soc {
	compatible = "ti,omap-infra";
	mpu {
		compatible = "ti,omap3-mpu";
		hwmods = "mpu";
		cpu@0 {
			phandle = <&cpu0>;
			[...]
		};
	};
};


Does that look better?

Thanks,
Benoit

[PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Cousson, Benoit]

Hi Arnd,

On 9/1/2011 8:17 PM, Arnd Bergmann wrote:
> On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote:
>>
>>          /*
>> +        * XXX: The cpus node is mandatory, but since the CPUs are as well part
>> +        * of the mpu subsystem below, it is not clear where the information
>> +        * should be. Maybe here with a phandle inside the mpu?
>> +        */
>> +       cpus {
>> +       };
>> +
>> +       /*
>>           * The soc node represents the soc top level view. It is uses for IPs
>>           * that are not memory mapped in the MPU view or for the MPU itself.
>>           */
>>          soc {
>>                  compatible = "ti,omap-infra";
>> +               mpu {
>> +                       compatible = "ti,omap3-mpu";
>> +                       hwmods = "mpu";
>> +                       cpu at 0 {
>> +                               compatible = "arm,cortex-a8";
>> +                       };
>> +               };
>> +
>
> I would always put the cpu nodes in the top-level, even if that's
> a slight misrepresentation of the truth. The point is basically
> that CPU nodes are special (you cannot have device drivers for them)
> and that the device tree is basically laid out from the perspective
> of the CPU, which may be different from the perspective that a
> hardware designer has.

Yeah, I saw that in the "cpus" node documentation. My point here is that 
I do need to represent the MPU subsystem that will contain the cpus. And 
thus the Cortex is inside the MPU subsystem.

I can potentially keep the CPUs inside the cpus node, and just represent 
the mpu node inside the soc, with potentially some phandle to the real 
cpu nodes.

Something like that:

cpus {
	cpu0: cpu at 0 {
			compatible = "arm,cortex-a8";
	};
};

[...]

soc {
	compatible = "ti,omap-infra";
	mpu {
		compatible = "ti,omap3-mpu";
		hwmods = "mpu";
		cpu at 0 {
			phandle = <&cpu0>;
			[...]
		};
	};
};


Does that look better?

Thanks,
Benoit

Re: [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Arnd Bergmann]

On Monday 05 September 2011, Cousson, Benoit wrote:
> Yeah, I saw that in the "cpus" node documentation. My point here is that 
> I do need to represent the MPU subsystem that will contain the cpus. And 
> thus the Cortex is inside the MPU subsystem.
> 
> I can potentially keep the CPUs inside the cpus node, and just represent 
> the mpu node inside the soc, with potentially some phandle to the real 
> cpu nodes.
> 
> Something like that:
> 
> cpus {
>         cpu0: cpu@0 {
>                         compatible = "arm,cortex-a8";
>         };
> };
> 
> [...]
> 
> soc {
>         compatible = "ti,omap-infra";
>         mpu {
>                 compatible = "ti,omap3-mpu";
>                 hwmods = "mpu";
>                 cpu@0 {
>                         phandle = <&cpu0>;
>                         [...]
>                 };
>         };
> };

Yes, that looks good. I wouldn't name the attribute "phandle" if I could
think of anything better (which I can't at the moment).

	Arnd

[PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Arnd Bergmann]

On Monday 05 September 2011, Cousson, Benoit wrote:
> Yeah, I saw that in the "cpus" node documentation. My point here is that 
> I do need to represent the MPU subsystem that will contain the cpus. And 
> thus the Cortex is inside the MPU subsystem.
> 
> I can potentially keep the CPUs inside the cpus node, and just represent 
> the mpu node inside the soc, with potentially some phandle to the real 
> cpu nodes.
> 
> Something like that:
> 
> cpus {
>         cpu0: cpu at 0 {
>                         compatible = "arm,cortex-a8";
>         };
> };
> 
> [...]
> 
> soc {
>         compatible = "ti,omap-infra";
>         mpu {
>                 compatible = "ti,omap3-mpu";
>                 hwmods = "mpu";
>                 cpu at 0 {
>                         phandle = <&cpu0>;
>                         [...]
>                 };
>         };
> };

Yes, that looks good. I wouldn't name the attribute "phandle" if I could
think of anything better (which I can't at the moment).

	Arnd

Re: [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Mitch Bradley]

On 9/5/2011 7:23 AM, Arnd Bergmann wrote:
> On Monday 05 September 2011, Cousson, Benoit wrote:
>> Yeah, I saw that in the "cpus" node documentation. My point here is that
>> I do need to represent the MPU subsystem that will contain the cpus. And
>> thus the Cortex is inside the MPU subsystem.


The device tree hierarchy does not represent "containment", but rather 
addressing from the standpoint of a program running on a CPU.

 From that viewpoint, it might be better to have a phandle reference to 
the mpu in each CPU node.

>>
>> I can potentially keep the CPUs inside the cpus node, and just represent
>> the mpu node inside the soc, with potentially some phandle to the real
>> cpu nodes.
>>
>> Something like that:
>>
>> cpus {
>>          cpu0: cpu@0 {
>>                          compatible = "arm,cortex-a8";
>>          };
>> };
>>
>> [...]
>>
>> soc {
>>          compatible = "ti,omap-infra";
>>          mpu {
>>                  compatible = "ti,omap3-mpu";
>>                  hwmods = "mpu";
>>                  cpu@0 {
>>                          phandle =<&cpu0>;
>>                          [...]
>>                  };
>>          };
>> };
>
> Yes, that looks good. I wouldn't name the attribute "phandle" if I could
> think of anything better (which I can't at the moment).
>
> 	Arnd
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

[PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Mitch Bradley]

On 9/5/2011 7:23 AM, Arnd Bergmann wrote:
> On Monday 05 September 2011, Cousson, Benoit wrote:
>> Yeah, I saw that in the "cpus" node documentation. My point here is that
>> I do need to represent the MPU subsystem that will contain the cpus. And
>> thus the Cortex is inside the MPU subsystem.


The device tree hierarchy does not represent "containment", but rather 
addressing from the standpoint of a program running on a CPU.

 From that viewpoint, it might be better to have a phandle reference to 
the mpu in each CPU node.

>>
>> I can potentially keep the CPUs inside the cpus node, and just represent
>> the mpu node inside the soc, with potentially some phandle to the real
>> cpu nodes.
>>
>> Something like that:
>>
>> cpus {
>>          cpu0: cpu at 0 {
>>                          compatible = "arm,cortex-a8";
>>          };
>> };
>>
>> [...]
>>
>> soc {
>>          compatible = "ti,omap-infra";
>>          mpu {
>>                  compatible = "ti,omap3-mpu";
>>                  hwmods = "mpu";
>>                  cpu at 0 {
>>                          phandle =<&cpu0>;
>>                          [...]
>>                  };
>>          };
>> };
>
> Yes, that looks good. I wouldn't name the attribute "phandle" if I could
> think of anything better (which I can't at the moment).
>
> 	Arnd
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

Re: [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Cousson, Benoit]

On 9/5/2011 7:46 PM, Mitch Bradley wrote:
> On 9/5/2011 7:23 AM, Arnd Bergmann wrote:
>> On Monday 05 September 2011, Cousson, Benoit wrote:
>>> Yeah, I saw that in the "cpus" node documentation. My point here is that
>>> I do need to represent the MPU subsystem that will contain the cpus. And
>>> thus the Cortex is inside the MPU subsystem.
>
>
> The device tree hierarchy does not represent "containment", but rather
> addressing from the standpoint of a program running on a CPU.
>
>   From that viewpoint, it might be better to have a phandle reference to
> the mpu in each CPU node.

So in that case, I'd rather use a scheme similar to a shared cache 
between CPUs:

cpus {
	cpu@0 {
		compatible = "arm,cortex-a8";
		subsystem = <&mpu>

		mpu: arm_mpu {
			compatible = "ti,omap3-mpu";
			hwmods = "mpu";
	};
};

And for an OMAP4 SMP system:

cpus {
	cpu@0 {
		compatible = "arm,cortex-a9";
		subsystem = <&mpu>

		mpu: arm_mpu {
			compatible = "ti,omap4-mpu";
			hwmods = "mpu";
	};

	cpu@1 {
		compatible = "arm,cortex-a9";
		subsystem = <&mpu>
	};
};

Ideally the interrupt-controller/GIC should probably be inside that MPU 
node, isn't it?

Thanks,
Benoit


>
>>>
>>> I can potentially keep the CPUs inside the cpus node, and just represent
>>> the mpu node inside the soc, with potentially some phandle to the real
>>> cpu nodes.
>>>
>>> Something like that:
>>>
>>> cpus {
>>>           cpu0: cpu@0 {
>>>                           compatible = "arm,cortex-a8";
>>>           };
>>> };
>>>
>>> [...]
>>>
>>> soc {
>>>           compatible = "ti,omap-infra";
>>>           mpu {
>>>                   compatible = "ti,omap3-mpu";
>>>                   hwmods = "mpu";
>>>                   cpu@0 {
>>>                           phandle =<&cpu0>;
>>>                           [...]
>>>                   };
>>>           };
>>> };
>>
>> Yes, that looks good. I wouldn't name the attribute "phandle" if I could
>> think of anything better (which I can't at the moment).
>>
>> 	Arnd
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>>

[PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes

[Cousson, Benoit]

On 9/5/2011 7:46 PM, Mitch Bradley wrote:
> On 9/5/2011 7:23 AM, Arnd Bergmann wrote:
>> On Monday 05 September 2011, Cousson, Benoit wrote:
>>> Yeah, I saw that in the "cpus" node documentation. My point here is that
>>> I do need to represent the MPU subsystem that will contain the cpus. And
>>> thus the Cortex is inside the MPU subsystem.
>
>
> The device tree hierarchy does not represent "containment", but rather
> addressing from the standpoint of a program running on a CPU.
>
>   From that viewpoint, it might be better to have a phandle reference to
> the mpu in each CPU node.

So in that case, I'd rather use a scheme similar to a shared cache 
between CPUs:

cpus {
	cpu at 0 {
		compatible = "arm,cortex-a8";
		subsystem = <&mpu>

		mpu: arm_mpu {
			compatible = "ti,omap3-mpu";
			hwmods = "mpu";
	};
};

And for an OMAP4 SMP system:

cpus {
	cpu at 0 {
		compatible = "arm,cortex-a9";
		subsystem = <&mpu>

		mpu: arm_mpu {
			compatible = "ti,omap4-mpu";
			hwmods = "mpu";
	};

	cpu at 1 {
		compatible = "arm,cortex-a9";
		subsystem = <&mpu>
	};
};

Ideally the interrupt-controller/GIC should probably be inside that MPU 
node, isn't it?

Thanks,
Benoit


>
>>>
>>> I can potentially keep the CPUs inside the cpus node, and just represent
>>> the mpu node inside the soc, with potentially some phandle to the real
>>> cpu nodes.
>>>
>>> Something like that:
>>>
>>> cpus {
>>>           cpu0: cpu at 0 {
>>>                           compatible = "arm,cortex-a8";
>>>           };
>>> };
>>>
>>> [...]
>>>
>>> soc {
>>>           compatible = "ti,omap-infra";
>>>           mpu {
>>>                   compatible = "ti,omap3-mpu";
>>>                   hwmods = "mpu";
>>>                   cpu at 0 {
>>>                           phandle =<&cpu0>;
>>>                           [...]
>>>                   };
>>>           };
>>> };
>>
>> Yes, that looks good. I wouldn't name the attribute "phandle" if I could
>> think of anything better (which I can't at the moment).
>>
>> 	Arnd
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>>