DRA7xx core support

Hi,

Quoted 4 lines · Rajendra Nayak

(quoted diff) +0 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 5 lines

(quoted diff) +5 -0

+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

Quoted 7 lines · Felipe Balbi

Hi,

Quoted 4 lines · Rajendra Nayak

(quoted diff) +0 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 

Quoted 8 lines

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 5 lines

(quoted diff) +5 -0

+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

s/correct of_/correct and use of_

Hi,

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 9 lines · Rajendra Nayak

(quoted diff) +5 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

I patched this for OMAP5 (compile-tested only, no boards available) and came out with the patch below (still needs to be split):

arch/arm/boot/dts/omap5-uevm.dts +0 -0

index 08b7267..b3136e5 100644

arch/arm/boot/dts/omap5-uevm.dts +0 -0

 	memory {
 		device_type = "memory";

arch/arm/boot/dts/omap5.dtsi +1 -1

index 07be2cd..a7bc906 100644
@@ -17,7 +17,7 @@
 	#address-cells = <1>;
 	#size-cells = <1>;
 
-	compatible = "ti,omap5";
+	compatible = "ti,omap5432-es2.0", "ti,omap5430-es2.0", "ti,omap5";
 	interrupt-parent = <&gic>;
 
 	aliases {

arch/arm/mach-omap2/id.c +0 -43

index 2dc62a2..ee94309 100644
@@ -563,49 +563,6 @@ void __init omap4xxx_check_revision(void)
 	pr_info("%s %s\n", soc_name, soc_rev);
 }
 
-void __init omap5xxx_check_revision(void)
-{
-	u32 idcode;
-	u16 hawkeye;
-	u8 rev;
-
-	idcode = read_tap_reg(OMAP_TAP_IDCODE);
-	hawkeye = (idcode >> 12) & 0xffff;
-	rev = (idcode >> 28) & 0xff;
-	switch (hawkeye) {
-	case 0xb942:
-		switch (rev) {
-		case 0:
-			omap_revision = OMAP5430_REV_ES1_0;
-			break;
-		case 1:
-		default:
-			omap_revision = OMAP5430_REV_ES2_0;
-		}
-		break;
-
-	case 0xb998:
-		switch (rev) {
-		case 0:
-			omap_revision = OMAP5432_REV_ES1_0;
-			break;
-		case 1:
-		default:
-			omap_revision = OMAP5432_REV_ES2_0;
-		}
-		break;
-
-	default:
-		/* Unknown default to latest silicon rev as default*/
-		omap_revision = OMAP5430_REV_ES2_0;
-	}
-
-	sprintf(soc_name, "OMAP%04x", omap_rev() >> 16);
-	sprintf(soc_rev, "ES%d.0", (omap_rev() >> 12) & 0xf);
-
-	pr_info("%s %s\n", soc_name, soc_rev);
-}
-
 /*
  * Set up things for map_io and processor detection later on. Gets called
  * pretty much first thing from board init. For multi-omap, this gets

arch/arm/mach-omap2/io.c +1 -3

index 4a3f06f..aa28940 100644
@@ -633,8 +633,7 @@ void __init omap4430_init_late(void)
 #ifdef CONFIG_SOC_OMAP5
 void __init omap5_init_early(void)
 {
-	omap2_set_globals_tap(OMAP54XX_CLASS,
-			      OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
+	omap2_set_globals_tap(-1, OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
 	omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
 				  OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE));
 	omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));

@@ -644,7 +643,6 @@ void __init omap5_init_early(void)
 	omap_prm_base_init();
 	omap_cm_base_init();
 	omap44xx_prm_init();
-	omap5xxx_check_revision();
 	omap54xx_voltagedomains_init();
 	omap54xx_powerdomains_init();
 	omap54xx_clockdomains_init();

arch/arm/mach-omap2/soc.h +5 -13

index 8c616e4..b8339ad 100644
@@ -35,6 +35,7 @@
 #ifndef __ASSEMBLY__
 
 #include <linux/bitops.h>
+#include <linux/of.h>
 
 /*
  * Test if multicore OMAP support is needed

@@ -194,7 +195,6 @@ IS_OMAP_CLASS(24xx, 0x24)
 IS_OMAP_CLASS(34xx, 0x34)
 IS_OMAP_CLASS(44xx, 0x44)
 IS_AM_CLASS(35xx, 0x35)
-IS_OMAP_CLASS(54xx, 0x54)
 IS_AM_CLASS(33xx, 0x33)
 IS_AM_CLASS(43xx, 0x43)
 

@@ -207,7 +207,6 @@ IS_OMAP_SUBCLASS(363x, 0x363)
 IS_OMAP_SUBCLASS(443x, 0x443)
 IS_OMAP_SUBCLASS(446x, 0x446)
 IS_OMAP_SUBCLASS(447x, 0x447)
-IS_OMAP_SUBCLASS(543x, 0x543)
 
 IS_TI_SUBCLASS(816x, 0x816)
 IS_TI_SUBCLASS(814x, 0x814)

@@ -373,10 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
 # endif
 
 # if defined(CONFIG_SOC_OMAP5)
-# undef soc_is_omap54xx
-# undef soc_is_omap543x
-# define soc_is_omap54xx()		is_omap54xx()
-# define soc_is_omap543x()		is_omap543x()
+# undef  soc_is_omap54xx
+# undef  soc_is_omap543x
+# define soc_is_omap54xx()		(of_machine_is_compatible("ti,omap5"))
+# define soc_is_omap543x()		(soc_is_omap54xx())
 #endif
 
 /* Various silicon revisions for omap2 */

@@ -437,16 +436,9 @@ IS_OMAP_TYPE(3430, 0x3430)
 #define OMAP447X_CLASS		0x44700044
 #define OMAP4470_REV_ES1_0	(OMAP447X_CLASS | (0x10 << 8))
 
-#define OMAP54XX_CLASS		0x54000054
-#define OMAP5430_REV_ES1_0	(OMAP54XX_CLASS | (0x30 << 16) | (0x10 << 8))
-#define OMAP5430_REV_ES2_0	(OMAP54XX_CLASS | (0x30 << 16) | (0x20 << 8))
-#define OMAP5432_REV_ES1_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8))
-#define OMAP5432_REV_ES2_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x20 << 8))
-
 void omap2xxx_check_revision(void);
 void omap3xxx_check_revision(void);
 void omap4xxx_check_revision(void);
-void omap5xxx_check_revision(void);
 void omap3xxx_check_features(void);
 void ti81xx_check_features(void);
 void am33xx_check_features(void);

Quoted 24 lines · Felipe Balbi

Hi,

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 9 lines · Rajendra Nayak

(quoted diff) +5 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

I patched this for OMAP5 (compile-tested only, no boards available) and came out with the patch below (still needs to be split):

arch/arm/boot/dts/omap5-uevm.dts +0 -0

index 08b7267..b3136e5 100644
@@ -13,7 +13,7 @@
 

arch/arm/boot/dts/omap5-uevm.dts line 17

Quoted 5 lines

arch/arm/boot/dts/omap5-uevm.dts +1 -1

 / {
 	model = "TI OMAP5 uEVM board";
-	compatible = "ti,omap5-uevm", "ti,omap5";
+	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
 

ok, nice and simpler way.
But would this make different revisions, to appear the same ?

Hi,

Quoted 25 lines · Sricharan R

Quoted 24 lines · Felipe Balbi

Hi,

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 9 lines · Rajendra Nayak

(quoted diff) +5 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

I patched this for OMAP5 (compile-tested only, no boards available) and came out with the patch below (still needs to be split):

arch/arm/boot/dts/omap5-uevm.dts +0 -0

index 08b7267..b3136e5 100644
@@ -13,7 +13,7 @@
 

Quoted 7 lines

arch/arm/boot/dts/omap5-uevm.dts line 17

Quoted 5 lines

arch/arm/boot/dts/omap5-uevm.dts +1 -1

 / {
 	model = "TI OMAP5 uEVM board";
-	compatible = "ti,omap5-uevm", "ti,omap5";
+	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
 

ok, nice and simpler way.
But would this make different revisions, to appear the same ?

well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, it should be treated as such, then you can pass a different string to that new board's compatible attribute.

Quoted 35 lines · Felipe Balbi

Hi,

Quoted 25 lines · Sricharan R

Quoted 24 lines · Felipe Balbi

Hi,

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 9 lines · Rajendra Nayak

(quoted diff) +5 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

I patched this for OMAP5 (compile-tested only, no boards available) and came out with the patch below (still needs to be split):

arch/arm/boot/dts/omap5-uevm.dts +0 -0

index 08b7267..b3136e5 100644
@@ -13,7 +13,7 @@
 

Quoted 7 lines

arch/arm/boot/dts/omap5-uevm.dts line 17

Quoted 5 lines

arch/arm/boot/dts/omap5-uevm.dts +1 -1

 / {
 	model = "TI OMAP5 uEVM board";
-	compatible = "ti,omap5-uevm", "ti,omap5";
+	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
 

ok, nice and simpler way.
But would this make different revisions, to appear the same ?

Quoted 4 lines

well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, it should be treated as such, then you can pass a different string to that new board's compatible attribute.

Yes for OMAP5. I was thinking in general about this approach. For example, for OMAP4 we have same board and different revisions can be socketed there.

For OMAP5, this is good.

Hi,

Quoted 44 lines · Sricharan R

Quoted 35 lines · Felipe Balbi

Hi,

Quoted 25 lines · Sricharan R

Quoted 24 lines · Felipe Balbi

Hi,

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 9 lines · Rajendra Nayak

(quoted diff) +5 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

I patched this for OMAP5 (compile-tested only, no boards available) and came out with the patch below (still needs to be split):

arch/arm/boot/dts/omap5-uevm.dts +0 -0

index 08b7267..b3136e5 100644
@@ -13,7 +13,7 @@
 

Quoted 7 lines

arch/arm/boot/dts/omap5-uevm.dts line 17

Quoted 5 lines

arch/arm/boot/dts/omap5-uevm.dts +1 -1

 / {
 	model = "TI OMAP5 uEVM board";
-	compatible = "ti,omap5-uevm", "ti,omap5";
+	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
 

ok, nice and simpler way.
But would this make different revisions, to appear the same ?

Quoted 4 lines

well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, it should be treated as such, then you can pass a different string to that new board's compatible attribute.
s

Yes for OMAP5. I was thinking in general about this approach. For example, for OMAP4 we have same board and different revisions can be socketed there.

Quoted 1 line

For OMAP5, this is good.

do we really production socketed boards? Well, at least Blaze has such thing. But do we have too many differences that need to be trated at arch/arm or should/could those be handled by reading IP's revision register (e.g. usb host erratas)

Hi,

Quoted 47 lines · Felipe Balbi

Hi,

Quoted 44 lines · Sricharan R

Quoted 35 lines · Felipe Balbi

Hi,

Quoted 25 lines · Sricharan R

Quoted 24 lines · Felipe Balbi

Hi,

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 9 lines · Rajendra Nayak

(quoted diff) +5 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
  # define soc_is_omap543x()		is_omap543x()
  #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

I patched this for OMAP5 (compile-tested only, no boards available) and came out with the patch below (still needs to be split):

arch/arm/boot/dts/omap5-uevm.dts +0 -0

index 08b7267..b3136e5 100644
@@ -13,7 +13,7 @@
 

Quoted 7 lines

arch/arm/boot/dts/omap5-uevm.dts line 17

Quoted 5 lines

arch/arm/boot/dts/omap5-uevm.dts +1 -1

  / {
  	model = "TI OMAP5 uEVM board";
-	compatible = "ti,omap5-uevm", "ti,omap5";
+	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
 

ok, nice and simpler way.
But would this make different revisions, to appear the same ?

Quoted 4 lines

well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, it should be treated as such, then you can pass a different string to that new board's compatible attribute.
s

Yes for OMAP5. I was thinking in general about this approach. For example, for OMAP4 we have same board and different revisions can be socketed there.

Quoted 6 lines

Quoted 1 line

For OMAP5, this is good.

do we really production socketed boards? Well, at least Blaze has such thing. But do we have too many differences that need to be trated at arch/arm or should/could those be handled by reading IP's revision register (e.g. usb host erratas)

OMAP4 SDP is socketed as well.

Ya, revision checks used only in few places and as you said we handle them using IP revisions, but that we have to look and clean up those places, if we really intend to do this for other socs.

Quoted 55 lines · Sricharan R

Hi,

Quoted 53 lines · Felipe Balbi

Hi,

Quoted 40 lines · Sricharan R

Quoted 35 lines · Felipe Balbi

Hi,

Quoted 25 lines · Sricharan R

Quoted 24 lines · Felipe Balbi

Hi,

Review IS_OMAP_TYPE(3430, 0x3430) · line 414

Quoted 9 lines · Rajendra Nayak

(quoted diff) +5 -0

@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
  # define soc_is_omap543x()        is_omap543x()
  #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()        is_dra7xx()
+# define soc_is_dra75x()        is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

I patched this for OMAP5 (compile-tested only, no boards available) and came out with the patch below (still needs to be split):

arch/arm/boot/dts/omap5-uevm.dts +0 -0

index 08b7267..b3136e5 100644
@@ -13,7 +13,7 @@
 

Quoted 7 lines

arch/arm/boot/dts/omap5-uevm.dts line 17

Quoted 5 lines

arch/arm/boot/dts/omap5-uevm.dts +1 -1

  / {
      model = "TI OMAP5 uEVM board";
-    compatible = "ti,omap5-uevm", "ti,omap5";
+    compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
 

ok, nice and simpler way.
But would this make different revisions, to appear the same ?

Quoted 4 lines

well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, it should be treated as such, then you can pass a different string to that new board's compatible attribute.
s

Quoted 5 lines

Yes for OMAP5. I was thinking in general about this approach. For example, for OMAP4 we have same board and different revisions can be socketed there.

For OMAP5, this is good.

do we really production socketed boards? Well, at least Blaze has such thing. But do we have too many differences that need to be trated at arch/arm or should/could those be handled by reading IP's revision register (e.g. usb host erratas)

Quoted 1 line

OMAP4 SDP is socketed as well.

a) OMAP4SDP is not production device
b) OMAP4SDP uses SOM (System On Module)
c) Socketted SOMs were used only during initial days of SoC
d) almost all latest OMAP4 SDP switched to using soldered in SOM
e) we claim compatibility of OMAP4 SDP with Blaze.

So, I dont think this is a rational argument for keeping soc checks with dts.

Quoted 4 lines

Ya, revision checks used only in few places and as you said we handle them using IP revisions, but that we have to look and clean up those places, if we really intend to do this for other socs.

I agree this is the right approach :).

Tony, what do you suggest we do for this series? Since we have just an es1.0 and one board at this point for dra7xx, things would be fine even if we do a dt based parsing to identify the device, and I am fine with it if thats what we feel is the right way forward. For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of these rev checks from the kernel and depending on DT parsing needs to be a separate series anyway and I dont plan to address those as part of this series.

Quoted 7 lines · Rajendra Nayak

Tony, what do you suggest we do for this series? Since we have just an es1.0 and one board at this point for dra7xx, things would be fine even if we do a dt based parsing to identify the device, and I am fine with it if thats what we feel is the right way forward. For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of these rev checks from the kernel and depending on DT parsing needs to be a separate series anyway and I dont plan to address those as part of this series.

Well I'd say there's no need to drop the hardware revision checks at this point at least for existing hardware. That's a very minimal piece of code and there are way bigger issues to tackle.

For new SoCs, we could do it based on the compatible flag. If it helps booting newer hardware with older kernels, then that's a good reason to do it.

Regards,

Tony

From: R Sricharan <[email protected]>

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

arch/arm/mach-omap2/Makefile obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o · line 192

Quoted 9 lines

  # Clock framework
  obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o

arch/arm/mach-omap2/Makefile +2 -0

@@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
  obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
  obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
  obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
 

are these in sync with DRA7 support being introduced for clock data in [1]?

[1] http://marc.info/?l=linux-omap&m=137456411706971&w=2

Quoted 14 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

arch/arm/mach-omap2/Makefile obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o · line 192

Quoted 9 lines

   # Clock framework
   obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o

arch/arm/mach-omap2/Makefile +2 -0

@@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
   obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
   obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
   obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
 

are these in sync with DRA7 support being introduced for clock data in [1]?

I don't want to have a dependency on those patches since I am not sure of them making it into 3.12.

Quoted 5 lines

[1] http://marc.info/?l=linux-omap&m=137456411706971&w=2

Quoted 16 lines · Rajendra Nayak

Quoted 14 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

arch/arm/mach-omap2/Makefile obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o · line 192

Quoted 9 lines

   # Clock framework
   obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o

arch/arm/mach-omap2/Makefile +2 -0

@@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
   obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
   obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
   obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
 

are these in sync with DRA7 support being introduced for clock data in [1]?

Quoted 2 lines

I don't want to have a dependency on those patches since I am not sure of them making it into 3.12.

Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?

Quoted 7 lines

Quoted 6 lines

[1] http://marc.info/?l=linux-omap&m=137456411706971&w=2

Quoted 17 lines · Nishanth Menon

Quoted 16 lines · Rajendra Nayak

Quoted 14 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

arch/arm/mach-omap2/Makefile obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o · line 192

Quoted 9 lines

# Clock framework
obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o

arch/arm/mach-omap2/Makefile +2 -0

@@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
    obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
    obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
    obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
 

are these in sync with DRA7 support being introduced for clock data in [1]?

Quoted 4 lines

Quoted 2 lines

I don't want to have a dependency on those patches since I am not sure of them making it into 3.12.

Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?

I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out. Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the dpll files for DRA7? Is that what you are worried we might have to revert?

Quoted 9 lines

Quoted 7 lines

Quoted 6 lines

[1] http://marc.info/?l=linux-omap&m=137456411706971&w=2

Quoted 21 lines · Rajendra Nayak

Quoted 20 lines · Nishanth Menon

Quoted 18 lines · Rajendra Nayak

Quoted 14 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

arch/arm/mach-omap2/Makefile obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o · line 192

Quoted 9 lines

# Clock framework
obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o

arch/arm/mach-omap2/Makefile +2 -0

@@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
    obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
    obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
    obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
 

are these in sync with DRA7 support being introduced for clock data in [1]?

I don't want to have a dependency on those patches since I am not sure of them making it into 3.12.

Quoted 5 lines

Quoted 1 line

Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?

I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out. Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the dpll files for DRA7? Is that what you are worried we might have to revert?

yes - lets just drop that change. that allows what ever alignment we have for clock data/driver to handle it appropriately. IMHO, could also keeps your series independent from Tero's series.

Quoted 11 lines

Quoted 10 lines

Quoted 8 lines

Quoted 7 lines

[1] http://marc.info/?l=linux-omap&m=137456411706971&w=2

From: R Sricharan <[email protected]>

Add minimal device tree source needed for DRA7 based SoCs. Also add a board dts file for the dra7-evm (based on dra752) which contains 1.5G of memory with 1G interleaved and 512MB non-interleaved. Also added in the board file are pin configuration details for i2c, mcspi and uart devices on board.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Rajendra Nayak <[email protected]>

Signed-off-by Sourav Poddar <[email protected]>

---
  arch/arm/boot/dts/Makefile     |    3 +-
  arch/arm/boot/dts/dra7-evm.dts |  163 ++++++++++++++
  arch/arm/boot/dts/dra7.dtsi    |  488 ++++++++++++++++++++++++++++++++++++++++
  3 files changed, 653 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/boot/dts/dra7-evm.dts create mode 100644 arch/arm/boot/dts/dra7.dtsi

arch/arm/boot/dts/Makefile +2 -1

index 641b3c9..e2f8566 100644
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
  	am335x-bone.dtb \
  	am3517-evm.dtb \
  	am3517_mt_ventoux.dtb \
-	am43x-epos-evm.dtb
+	am43x-epos-evm.dtb \
+	dra7-evm.dtb
  dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
  dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
  dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \

arch/arm/boot/dts/dra7-evm.dts new file +163 -0

new file mode 100644
index 0000000..7b0b563
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2013 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/ "dra7.dtsi"
+
+/ {
+	model = "TI DRA7";
+	compatible = "ti,dra7-evm", "ti,dra7";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x60000000>; /* 1536 MB */
+	};
+};
+
+&dra7_pmx_core {
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			0x400 0x60000	/* i2c1_sda */
+			0x404 0x60000	/* i2c1_scl */
+		>;
+	};
+
+	i2c2_pins: pinmux_i2c2_pins {
+		pinctrl-single,pins = <
+			0x408 0x60000	/* i2c2_sda */
+			0x40c 0x60000	/* i2c2_scl */
+		>;
+	};
+
+	i2c3_pins: pinmux_i2c3_pins {
+		pinctrl-single,pins = <
+			0x410 0x60000	/* i2c3_sda */
+			0x414 0x60000	/* i2c3_scl */
+		>;
+	};
+
+	mcspi1_pins: pinmux_mcspi1_pins {
+		pinctrl-single,pins = <
+			0x3a4 0x40000	/* spi2_clk */
+			0x3a8 0x40000	/* spi2_d1 */
+			0x3ac 0x40000	/* spi2_d0 */
+			0x3b0 0xc0000	/* spi2_cs0 */
+			0x3b4 0xc0000	/* spi2_cs1 */
+			0x3b8 0xe0006	/* spi2_cs2 */
+			0x3bc 0xe0006	/* spi2_cs3 */
+		>;
+	};
+
+	mcspi2_pins: pinmux_mcspi2_pins {
+		pinctrl-single,pins = <
+			0x3c0 0x40000	/* spi2_sclk */
+			0x3c4 0xc0000	/* spi2_d1 */
+			0x3c8 0xc0000	/* spi2_d1 */
+			0x3cc 0xe0000	/* spi2_cs0 */
+		>;
+	};
+
+	uart1_pins: pinmux_uart1_pins {
+		pinctrl-single,pins = <
+			0x3e0 0xe0000	/* uart1_rxd */
+			0x3e4 0xe0000	/* uart1_txd */
+			0x3e8 0x60003	/* uart1_ctsn */
+			0x3ec 0x60003	/* uart1_rtsn */
+		>;
+	};
+
+	uart2_pins: pinmux_uart2_pins {
+		pinctrl-single,pins = <
+			0x3f0 0x60000 /* uart2_rxd */
+			0x3f4 0x60000 /* uart2_txd */
+			0x3f8 0x60000 /* uart2_ctsn */
+			0x3fc 0x60000 /* uart2_rtsn */
+		>;
+	};
+
+	uart3_pins: pinmux_uart3_pins {
+		pinctrl-single,pins = <
+			0x248 0xc0000 /* uart3_rxd */
+			0x24c 0xc0000 /* uart3_txd */
+		>;
+	};
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c3_pins>;
+
+	clock-frequency = <3400000>;
+};
+
+&i2c4 {
+	status = "disabled";
+};
+
+&i2c5 {
+	status = "disabled";
+};
+
+&mcspi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcspi1_pins>;
+};
+
+&mcspi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcspi2_pins>;
+};
+
+&mcspi3 {
+	status = "disabled";
+};
+
+&mcspi4 {
+	status = "disabled";
+};
+
+&uart1 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart1_pins>;
+};
+
+&uart2 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart2_pins>;
+};
+
+&uart3 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart3_pins>;
+};
+
+&uart4 {
+	status = "disabled";
+};
+
+&uart5 {
+	status = "disabled";
+};
+
+&uart6 {
+	status = "disabled";
+};

arch/arm/boot/dts/dra7.dtsi new file +478 -0

new file mode 100644
index 0000000..8a0c08e
@@ -0,0 +1,488 @@
+/*
+ * Copyright (C) 2013 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.
+ * Based on "omap4.dtsi"
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "ti,dra7xx";
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		serial3 = &uart4;
+		serial4 = &uart5;
+		serial5 = &uart6;
+	};
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a15";
+			timer {
+				compatible = "arm,armv7-timer";
+				/*
+				 * PPI secure/nonsecure IRQ,
+				 * active low level-sensitive
+				 */
+				interrupts = <1 13 0x308>,
+					     <1 14 0x308>;
+				clock-frequency = <6144000>;
+			};
+		};
+		cpu at 1 {
+			compatible = "arm,cortex-a15";
+			timer {
+				compatible = "arm,armv7-timer";
+				/*
+				 * PPI secure/nonsecure IRQ,
+				 * active low level-sensitive
+				 */
+				interrupts = <1 13 0x308>,
+					     <1 14 0x308>;
+				clock-frequency = <6144000>;
+			};
+		};
+	};
+
+	gic: interrupt-controller at 48211000 {
+		compatible = "arm,cortex-a15-gic";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0x48211000 0x1000>,
+		      <0x48212000 0x1000>;
+	};
+
+	/*
+	 * 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,omap5-mpu";
+			ti,hwmods = "mpu";
+		};
+	};
+
+	/*
+	 * XXX: Use a flat representation of the SOC 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,omap4-l3-noc", "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		ti,hwmods = "l3_main_1", "l3_main_2";
+
+		counter32k: counter at 4ae04000 {
+			compatible = "ti,omap-counter32k";
+			reg = <0x4ae04000 0x40>;
+			ti,hwmods = "counter_32k";
+		};
+
+		dra7_pmx_core: pinmux at 4a003400 {
+			compatible = "pinctrl-single";
+			reg = <0x4a003400 0x0464>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			pinctrl-single,register-width = <32>;
+			pinctrl-single,function-mask = <0x3fffffff>;
+		};
+
+		sdma: dma-controller at 4a056000 {
+			compatible = "ti,omap4430-sdma";
+			reg = <0x4a056000 0x1000>;
+			interrupts = <0 12 0x4>,
+				     <0 13 0x4>,
+				     <0 14 0x4>,
+				     <0 15 0x4>;
+			#dma-cells = <1>;
+			#dma-channels = <32>;
+			#dma-requests = <127>;
+		};
+
+		gpio1: gpio at 4ae10000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4ae10000 0x200>;
+			interrupts = <0 29 0x4>;
+			ti,hwmods = "gpio1";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio2: gpio at 48055000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48055000 0x200>;
+			interrupts = <0 30 0x4>;
+			ti,hwmods = "gpio2";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio3: gpio at 48057000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48057000 0x200>;
+			interrupts = <0 31 0x4>;
+			ti,hwmods = "gpio3";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio4: gpio at 48059000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48059000 0x200>;
+			interrupts = <0 32 0x4>;
+			ti,hwmods = "gpio4";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio5: gpio at 4805b000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4805b000 0x200>;
+			interrupts = <0 33 0x4>;
+			ti,hwmods = "gpio5";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio6: gpio at 4805d000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4805d000 0x200>;
+			interrupts = <0 34 0x4>;
+			ti,hwmods = "gpio6";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio7: gpio at 48051000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48051000 0x200>;
+			interrupts = <0 35 0x4>;
+			ti,hwmods = "gpio7";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio8: gpio at 48053000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48053000 0x200>;
+			interrupts = <0 121 0x4>;
+			ti,hwmods = "gpio8";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		uart1: serial at 4806a000 {
+			compatible = "ti,omap4-uart";
+			reg = <0x4806a000 0x100>;
+			interrupts = <0 72 0x4>;
+			ti,hwmods = "uart1";
+			clock-frequency = <48000000>;
+		};
+
+		uart2: serial at 4806c000 {
+			compatible = "ti,omap4-uart";
+			reg = <0x4806c000 0x100>;
+			interrupts = <0 73 0x4>;
+			ti,hwmods = "uart2";
+			clock-frequency = <48000000>;
+		};
+
+		uart3: serial at 48020000 {
+			compatible = "ti,omap4-uart";
+			reg = <0x48020000 0x100>;
+			interrupts = <0 74 0x4>;
+			ti,hwmods = "uart3";
+			clock-frequency = <48000000>;
+		};
+
+		uart4: serial at 4806e000 {
+			compatible = "ti,omap4-uart";
+			reg = <0x4806e000 0x100>;
+			interrupts = <0 70 0x4>;
+			ti,hwmods = "uart4";
+			clock-frequency = <48000000>;
+		};
+
+		uart5: serial at 48066000 {
+			compatible = "ti,omap4-uart";
+			reg = <0x48066000 0x100>;
+			interrupts = <0 105 0x4>;
+			ti,hwmods = "uart5";
+			clock-frequency = <48000000>;
+		};
+
+		uart6: serial at 48068000 {
+			compatible = "ti,omap4-uart";
+			reg = <0x48068000 0x100>;
+			interrupts = <0 106 0x4>;
+			ti,hwmods = "uart6";
+			clock-frequency = <48000000>;
+		};
+
+		timer1: timer at 4ae18000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x4ae18000 0x80>;
+			interrupts = <0 37 0x4>;
+			ti,hwmods = "timer1";
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 48032000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48032000 0x80>;
+			interrupts = <0 38 0x4>;
+			ti,hwmods = "timer2";
+		};
+
+		timer3: timer at 48034000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48034000 0x80>;
+			interrupts = <0 39 0x4>;
+			ti,hwmods = "timer3";
+		};
+
+		timer4: timer at 48036000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48036000 0x80>;
+			interrupts = <0 40 0x4>;
+			ti,hwmods = "timer4";
+		};
+
+		timer5: timer at 48820000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48820000 0x80>;
+			interrupts = <0 41 0x4>;
+			ti,hwmods = "timer5";
+			ti,timer-dsp;
+		};
+
+		timer6: timer at 48822000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48822000 0x80>;
+			interrupts = <0 42 0x4>;
+			ti,hwmods = "timer6";
+			ti,timer-dsp;
+			ti,timer-pwm;
+		};
+
+		timer7: timer at 48824000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48824000 0x80>;
+			interrupts = <0 43 0x4>;
+			ti,hwmods = "timer7";
+			ti,timer-dsp;
+		};
+
+		timer8: timer at 48826000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48826000 0x80>;
+			interrupts = <0 44 0x4>;
+			ti,hwmods = "timer8";
+			ti,timer-dsp;
+			ti,timer-pwm;
+		};
+
+		timer9: timer at 4803e000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x4803e000 0x80>;
+			interrupts = <0 45 0x4>;
+			ti,hwmods = "timer9";
+		};
+
+		timer10: timer at 48086000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48086000 0x80>;
+			interrupts = <0 46 0x4>;
+			ti,hwmods = "timer10";
+		};
+
+		timer11: timer at 48088000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48088000 0x80>;
+			interrupts = <0 47 0x4>;
+			ti,hwmods = "timer11";
+			ti,timer-pwm;
+		};
+
+		wdt2: wdt at 4ae14000 {
+			compatible = "ti,omap4-wdt";
+			reg = <0x4ae14000 0x80>;
+			interrupts = <0 80 0x4>;
+			ti,hwmods = "wd_timer2";
+		};
+
+		i2c1: i2c at 48070000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48070000 0x100>;
+			interrupts = <0 56 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c1";
+		};
+
+		i2c2: i2c at 48072000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48072000 0x100>;
+			interrupts = <0 57 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c2";
+		};
+
+		i2c3: i2c at 48060000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48060000 0x100>;
+			interrupts = <0 61 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c3";
+		};
+
+		i2c4: i2c at 4807a000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x4807a000 0x100>;
+			interrupts = <0 62 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c4";
+		};
+
+		i2c5: i2c at 4807c000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x4807c000 0x100>;
+			interrupts = <0 60 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c5";
+		};
+
+		mmc1: mmc at 4809c000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x4809c000 0x400>;
+			interrupts = <0 83 0x4>;
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+			ti,needs-special-reset;
+			dmas = <&sdma 61>, <&sdma 62>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc2: mmc at 480b4000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480b4000 0x400>;
+			interrupts = <0 86 0x4>;
+			ti,hwmods = "mmc2";
+			ti,needs-special-reset;
+			dmas = <&sdma 47>, <&sdma 48>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc3: mmc at 480ad000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480ad000 0x400>;
+			interrupts = <0 94 0x4>;
+			ti,hwmods = "mmc3";
+			ti,needs-special-reset;
+			dmas = <&sdma 77>, <&sdma 78>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc4: mmc at 480d1000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480d1000 0x400>;
+			interrupts = <0 96 0x4>;
+			ti,hwmods = "mmc4";
+			ti,needs-special-reset;
+			dmas = <&sdma 57>, <&sdma 58>;
+			dma-names = "tx", "rx";
+		};
+
+		mcspi1: spi at 48098000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x48098000 0x200>;
+			interrupts = <0 65 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi1";
+			ti,spi-num-cs = <4>;
+			dmas = <&sdma 35>,
+			       <&sdma 36>,
+			       <&sdma 37>,
+			       <&sdma 38>,
+			       <&sdma 39>,
+			       <&sdma 40>,
+			       <&sdma 41>,
+			       <&sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
+		};
+
+		mcspi2: spi at 4809a000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x4809a000 0x200>;
+			interrupts = <0 66 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi2";
+			ti,spi-num-cs = <2>;
+			dmas = <&sdma 43>,
+			       <&sdma 44>,
+			       <&sdma 45>,
+			       <&sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		mcspi3: spi at 480b8000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x480b8000 0x200>;
+			interrupts = <0 91 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi3";
+			ti,spi-num-cs = <2>;
+			dmas = <&sdma 15>, <&sdma 16>;
+			dma-names = "tx0", "rx0";
+		};
+
+		mcspi4: spi at 480ba000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x480ba000 0x200>;

Quoted 690 lines · Rajendra Nayak

From: R Sricharan <[email protected]>

Add minimal device tree source needed for DRA7 based SoCs. Also add a board dts file for the dra7-evm (based on dra752) which contains 1.5G of memory with 1G interleaved and 512MB non-interleaved. Also added in the board file are pin configuration details for i2c, mcspi and uart devices on board.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Rajendra Nayak <[email protected]>

Signed-off-by Sourav Poddar <[email protected]>

---
  arch/arm/boot/dts/Makefile     |    3 +-
  arch/arm/boot/dts/dra7-evm.dts |  163 ++++++++++++++
  arch/arm/boot/dts/dra7.dtsi    |  488 ++++++++++++++++++++++++++++++++++++++++
  3 files changed, 653 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/boot/dts/dra7-evm.dts create mode 100644 arch/arm/boot/dts/dra7.dtsi

arch/arm/boot/dts/Makefile +2 -1

index 641b3c9..e2f8566 100644
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
      am335x-bone.dtb \
      am3517-evm.dtb \
      am3517_mt_ventoux.dtb \
-    am43x-epos-evm.dtb
+    am43x-epos-evm.dtb \
+    dra7-evm.dtb
  dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
  dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
  dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \

arch/arm/boot/dts/dra7-evm.dts new file +163 -0

new file mode 100644
index 0000000..7b0b563
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2013 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/ "dra7.dtsi"
+
+/ {
+    model = "TI DRA7";
+    compatible = "ti,dra7-evm", "ti,dra7";
+
+    memory {
+        device_type = "memory";
+        reg = <0x80000000 0x60000000>; /* 1536 MB */
+    };
+};
+
+&dra7_pmx_core {
+    i2c1_pins: pinmux_i2c1_pins {
+        pinctrl-single,pins = <
+            0x400 0x60000    /* i2c1_sda */
+            0x404 0x60000    /* i2c1_scl */
+        >;
+    };
+
+    i2c2_pins: pinmux_i2c2_pins {
+        pinctrl-single,pins = <
+            0x408 0x60000    /* i2c2_sda */
+            0x40c 0x60000    /* i2c2_scl */
+        >;
+    };
+
+    i2c3_pins: pinmux_i2c3_pins {
+        pinctrl-single,pins = <
+            0x410 0x60000    /* i2c3_sda */
+            0x414 0x60000    /* i2c3_scl */
+        >;
+    };
+
+    mcspi1_pins: pinmux_mcspi1_pins {
+        pinctrl-single,pins = <
+            0x3a4 0x40000    /* spi2_clk */
+            0x3a8 0x40000    /* spi2_d1 */
+            0x3ac 0x40000    /* spi2_d0 */
+            0x3b0 0xc0000    /* spi2_cs0 */
+            0x3b4 0xc0000    /* spi2_cs1 */
+            0x3b8 0xe0006    /* spi2_cs2 */
+            0x3bc 0xe0006    /* spi2_cs3 */
+        >;
+    };
+
+    mcspi2_pins: pinmux_mcspi2_pins {
+        pinctrl-single,pins = <
+            0x3c0 0x40000    /* spi2_sclk */
+            0x3c4 0xc0000    /* spi2_d1 */
+            0x3c8 0xc0000    /* spi2_d1 */
+            0x3cc 0xe0000    /* spi2_cs0 */
+        >;
+    };
+
+    uart1_pins: pinmux_uart1_pins {
+        pinctrl-single,pins = <
+            0x3e0 0xe0000    /* uart1_rxd */
+            0x3e4 0xe0000    /* uart1_txd */
+            0x3e8 0x60003    /* uart1_ctsn */
+            0x3ec 0x60003    /* uart1_rtsn */
+        >;
+    };
+
+    uart2_pins: pinmux_uart2_pins {
+        pinctrl-single,pins = <
+            0x3f0 0x60000 /* uart2_rxd */
+            0x3f4 0x60000 /* uart2_txd */
+            0x3f8 0x60000 /* uart2_ctsn */
+            0x3fc 0x60000 /* uart2_rtsn */
+        >;
+    };
+
+    uart3_pins: pinmux_uart3_pins {
+        pinctrl-single,pins = <
+            0x248 0xc0000 /* uart3_rxd */
+            0x24c 0xc0000 /* uart3_txd */
+        >;
+    };
+};
+
+&i2c1 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&i2c1_pins>;
+
+    clock-frequency = <400000>;
+};
+
+&i2c2 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&i2c2_pins>;
+
+    clock-frequency = <400000>;
+};
+
+&i2c3 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&i2c3_pins>;
+
+    clock-frequency = <3400000>;
+};
+
+&i2c4 {
+    status = "disabled";
+};
+
+&i2c5 {
+    status = "disabled";
+};
+
+&mcspi1 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&mcspi1_pins>;
+};
+
+&mcspi2 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&mcspi2_pins>;
+};
+
+&mcspi3 {
+    status = "disabled";
+};
+
+&mcspi4 {
+    status = "disabled";
+};
+
+&uart1 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart1_pins>;
+};
+
+&uart2 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart2_pins>;
+};
+
+&uart3 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart3_pins>;
+};
+
+&uart4 {
+    status = "disabled";
+};
+
+&uart5 {
+    status = "disabled";
+};
+
+&uart6 {
+    status = "disabled";
+};

arch/arm/boot/dts/dra7.dtsi new file +482 -0

new file mode 100644
index 0000000..8a0c08e
@@ -0,0 +1,488 @@
+/*
+ * Copyright (C) 2013 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.
+ * Based on "omap4.dtsi"
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+    compatible = "ti,dra7xx";
+    interrupt-parent = <&gic>;
+
+    aliases {
+        serial0 = &uart1;
+        serial1 = &uart2;
+        serial2 = &uart3;
+        serial3 = &uart4;
+        serial4 = &uart5;
+        serial5 = &uart6;
+    };
+
+    cpus {
+        cpu at 0 {
+            compatible = "arm,cortex-a15";
+            timer {
+                compatible = "arm,armv7-timer";
+                /*
+                 * PPI secure/nonsecure IRQ,
+                 * active low level-sensitive
+                 */
+                interrupts = <1 13 0x308>,
+                         <1 14 0x308>;
+                clock-frequency = <6144000>;
+            };
+        };
+        cpu at 1 {
+            compatible = "arm,cortex-a15";
+            timer {
+                compatible = "arm,armv7-timer";
+                /*
+                 * PPI secure/nonsecure IRQ,
+                 * active low level-sensitive
+                 */
+                interrupts = <1 13 0x308>,
+                         <1 14 0x308>;
+                clock-frequency = <6144000>;
+            };
+        };
+    };
+
+    gic: interrupt-controller at 48211000 {
+        compatible = "arm,cortex-a15-gic";
+        interrupt-controller;
+        #interrupt-cells = <3>;
+        reg = <0x48211000 0x1000>,
+              <0x48212000 0x1000>;
+    };
+
+    /*
+     * 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,omap5-mpu";
+            ti,hwmods = "mpu";
+        };
+    };
+
+    /*
+     * XXX: Use a flat representation of the SOC 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,omap4-l3-noc", "simple-bus";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+        ti,hwmods = "l3_main_1", "l3_main_2";
+
+        counter32k: counter at 4ae04000 {
+            compatible = "ti,omap-counter32k";
+            reg = <0x4ae04000 0x40>;
+            ti,hwmods = "counter_32k";
+        };
+
+        dra7_pmx_core: pinmux at 4a003400 {
+            compatible = "pinctrl-single";
+            reg = <0x4a003400 0x0464>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            pinctrl-single,register-width = <32>;
+            pinctrl-single,function-mask = <0x3fffffff>;
+        };
+
+        sdma: dma-controller at 4a056000 {
+            compatible = "ti,omap4430-sdma";
+            reg = <0x4a056000 0x1000>;
+            interrupts = <0 12 0x4>,
+                     <0 13 0x4>,
+                     <0 14 0x4>,
+                     <0 15 0x4>;
+            #dma-cells = <1>;
+            #dma-channels = <32>;
+            #dma-requests = <127>;
+        };
+
+        gpio1: gpio at 4ae10000 {
+            compatible = "ti,omap4-gpio";
+            reg = <0x4ae10000 0x200>;
+            interrupts = <0 29 0x4>;
+            ti,hwmods = "gpio1";
+            gpio-controller;
+            #gpio-cells = <2>;
+            interrupt-controller;
+            #interrupt-cells = <1>;
+        };
+
+        gpio2: gpio at 48055000 {
+            compatible = "ti,omap4-gpio";
+            reg = <0x48055000 0x200>;
+            interrupts = <0 30 0x4>;
+            ti,hwmods = "gpio2";
+            gpio-controller;
+            #gpio-cells = <2>;
+            interrupt-controller;
+            #interrupt-cells = <1>;
+        };
+
+        gpio3: gpio at 48057000 {
+            compatible = "ti,omap4-gpio";
+            reg = <0x48057000 0x200>;
+            interrupts = <0 31 0x4>;
+            ti,hwmods = "gpio3";
+            gpio-controller;
+            #gpio-cells = <2>;
+            interrupt-controller;
+            #interrupt-cells = <1>;
+        };
+
+        gpio4: gpio at 48059000 {
+            compatible = "ti,omap4-gpio";
+            reg = <0x48059000 0x200>;
+            interrupts = <0 32 0x4>;
+            ti,hwmods = "gpio4";
+            gpio-controller;
+            #gpio-cells = <2>;
+            interrupt-controller;
+            #interrupt-cells = <1>;
+        };
+
+        gpio5: gpio at 4805b000 {
+            compatible = "ti,omap4-gpio";
+            reg = <0x4805b000 0x200>;
+            interrupts = <0 33 0x4>;
+            ti,hwmods = "gpio5";
+            gpio-controller;
+            #gpio-cells = <2>;
+            interrupt-controller;
+            #interrupt-cells = <1>;
+        };
+
+        gpio6: gpio at 4805d000 {
+            compatible = "ti,omap4-gpio";
+            reg = <0x4805d000 0x200>;
+            interrupts = <0 34 0x4>;
+            ti,hwmods = "gpio6";
+            gpio-controller;
+            #gpio-cells = <2>;
+            interrupt-controller;
+            #interrupt-cells = <1>;
+        };
+
+        gpio7: gpio at 48051000 {
+            compatible = "ti,omap4-gpio";
+            reg = <0x48051000 0x200>;
+            interrupts = <0 35 0x4>;
+            ti,hwmods = "gpio7";
+            gpio-controller;
+            #gpio-cells = <2>;
+            interrupt-controller;
+            #interrupt-cells = <1>;
+        };
+
+        gpio8: gpio at 48053000 {
+            compatible = "ti,omap4-gpio";
+            reg = <0x48053000 0x200>;
+            interrupts = <0 121 0x4>;
+            ti,hwmods = "gpio8";
+            gpio-controller;
+            #gpio-cells = <2>;
+            interrupt-controller;
+            #interrupt-cells = <1>;
+        };
+
+        uart1: serial at 4806a000 {
+            compatible = "ti,omap4-uart";
+            reg = <0x4806a000 0x100>;
+            interrupts = <0 72 0x4>;
+            ti,hwmods = "uart1";
+            clock-frequency = <48000000>;
+        };
+
+        uart2: serial at 4806c000 {
+            compatible = "ti,omap4-uart";
+            reg = <0x4806c000 0x100>;
+            interrupts = <0 73 0x4>;
+            ti,hwmods = "uart2";
+            clock-frequency = <48000000>;
+        };
+
+        uart3: serial at 48020000 {
+            compatible = "ti,omap4-uart";
+            reg = <0x48020000 0x100>;
+            interrupts = <0 74 0x4>;
+            ti,hwmods = "uart3";
+            clock-frequency = <48000000>;
+        };
+
+        uart4: serial at 4806e000 {
+            compatible = "ti,omap4-uart";
+            reg = <0x4806e000 0x100>;
+            interrupts = <0 70 0x4>;
+            ti,hwmods = "uart4";
+            clock-frequency = <48000000>;
+        };
+
+        uart5: serial at 48066000 {
+            compatible = "ti,omap4-uart";
+            reg = <0x48066000 0x100>;
+            interrupts = <0 105 0x4>;
+            ti,hwmods = "uart5";
+            clock-frequency = <48000000>;
+        };
+
+        uart6: serial at 48068000 {
+            compatible = "ti,omap4-uart";
+            reg = <0x48068000 0x100>;
+            interrupts = <0 106 0x4>;
+            ti,hwmods = "uart6";
+            clock-frequency = <48000000>;
+        };
+
+        timer1: timer at 4ae18000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x4ae18000 0x80>;
+            interrupts = <0 37 0x4>;
+            ti,hwmods = "timer1";
+            ti,timer-alwon;
+        };
+
+        timer2: timer at 48032000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48032000 0x80>;
+            interrupts = <0 38 0x4>;
+            ti,hwmods = "timer2";
+        };
+
+        timer3: timer at 48034000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48034000 0x80>;
+            interrupts = <0 39 0x4>;
+            ti,hwmods = "timer3";
+        };
+
+        timer4: timer at 48036000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48036000 0x80>;
+            interrupts = <0 40 0x4>;
+            ti,hwmods = "timer4";
+        };
+
+        timer5: timer at 48820000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48820000 0x80>;
+            interrupts = <0 41 0x4>;
+            ti,hwmods = "timer5";
+            ti,timer-dsp;
+        };
+
+        timer6: timer at 48822000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48822000 0x80>;
+            interrupts = <0 42 0x4>;
+            ti,hwmods = "timer6";
+            ti,timer-dsp;
+            ti,timer-pwm;
+        };
+
+        timer7: timer at 48824000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48824000 0x80>;
+            interrupts = <0 43 0x4>;
+            ti,hwmods = "timer7";
+            ti,timer-dsp;
+        };
+
+        timer8: timer at 48826000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48826000 0x80>;
+            interrupts = <0 44 0x4>;
+            ti,hwmods = "timer8";
+            ti,timer-dsp;
+            ti,timer-pwm;
+        };
+
+        timer9: timer at 4803e000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x4803e000 0x80>;
+            interrupts = <0 45 0x4>;
+            ti,hwmods = "timer9";
+        };
+
+        timer10: timer at 48086000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48086000 0x80>;
+            interrupts = <0 46 0x4>;
+            ti,hwmods = "timer10";
+        };
+
+        timer11: timer at 48088000 {
+            compatible = "ti,omap5430-timer";
+            reg = <0x48088000 0x80>;
+            interrupts = <0 47 0x4>;
+            ti,hwmods = "timer11";
+            ti,timer-pwm;
+        };
+
+        wdt2: wdt at 4ae14000 {
+            compatible = "ti,omap4-wdt";
+            reg = <0x4ae14000 0x80>;
+            interrupts = <0 80 0x4>;
+            ti,hwmods = "wd_timer2";
+        };
+
+        i2c1: i2c at 48070000 {
+            compatible = "ti,omap4-i2c";
+            reg = <0x48070000 0x100>;
+            interrupts = <0 56 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "i2c1";
+        };
+
+        i2c2: i2c at 48072000 {
+            compatible = "ti,omap4-i2c";
+            reg = <0x48072000 0x100>;
+            interrupts = <0 57 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "i2c2";
+        };
+
+        i2c3: i2c at 48060000 {
+            compatible = "ti,omap4-i2c";
+            reg = <0x48060000 0x100>;
+            interrupts = <0 61 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "i2c3";
+        };
+
+        i2c4: i2c at 4807a000 {
+            compatible = "ti,omap4-i2c";
+            reg = <0x4807a000 0x100>;
+            interrupts = <0 62 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "i2c4";
+        };
+
+        i2c5: i2c at 4807c000 {
+            compatible = "ti,omap4-i2c";
+            reg = <0x4807c000 0x100>;
+            interrupts = <0 60 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "i2c5";
+        };
+
+        mmc1: mmc at 4809c000 {
+            compatible = "ti,omap4-hsmmc";
+            reg = <0x4809c000 0x400>;
+            interrupts = <0 83 0x4>;
+            ti,hwmods = "mmc1";
+            ti,dual-volt;
+            ti,needs-special-reset;
+            dmas = <&sdma 61>, <&sdma 62>;
+            dma-names = "tx", "rx";
+        };
+
+        mmc2: mmc at 480b4000 {
+            compatible = "ti,omap4-hsmmc";
+            reg = <0x480b4000 0x400>;
+            interrupts = <0 86 0x4>;
+            ti,hwmods = "mmc2";
+            ti,needs-special-reset;
+            dmas = <&sdma 47>, <&sdma 48>;
+            dma-names = "tx", "rx";
+        };
+
+        mmc3: mmc at 480ad000 {
+            compatible = "ti,omap4-hsmmc";
+            reg = <0x480ad000 0x400>;
+            interrupts = <0 94 0x4>;
+            ti,hwmods = "mmc3";
+            ti,needs-special-reset;
+            dmas = <&sdma 77>, <&sdma 78>;
+            dma-names = "tx", "rx";
+        };
+
+        mmc4: mmc at 480d1000 {
+            compatible = "ti,omap4-hsmmc";
+            reg = <0x480d1000 0x400>;
+            interrupts = <0 96 0x4>;
+            ti,hwmods = "mmc4";
+            ti,needs-special-reset;
+            dmas = <&sdma 57>, <&sdma 58>;
+            dma-names = "tx", "rx";
+        };
+
+        mcspi1: spi at 48098000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x48098000 0x200>;
+            interrupts = <0 65 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi1";
+            ti,spi-num-cs = <4>;
+            dmas = <&sdma 35>,
+                   <&sdma 36>,
+                   <&sdma 37>,
+                   <&sdma 38>,
+                   <&sdma 39>,
+                   <&sdma 40>,
+                   <&sdma 41>,
+                   <&sdma 42>;
+            dma-names = "tx0", "rx0", "tx1", "rx1",
+                    "tx2", "rx2", "tx3", "rx3";
+        };
+
+        mcspi2: spi at 4809a000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x4809a000 0x200>;
+            interrupts = <0 66 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi2";
+            ti,spi-num-cs = <2>;
+            dmas = <&sdma 43>,
+                   <&sdma 44>,
+                   <&sdma 45>,
+                   <&sdma 46>;
+            dma-names = "tx0", "rx0", "tx1", "rx1";
+        };
+
+        mcspi3: spi at 480b8000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x480b8000 0x200>;
+            interrupts = <0 91 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi3";
+            ti,spi-num-cs = <2>;
+            dmas = <&sdma 15>, <&sdma 16>;
+            dma-names = "tx0", "rx0";
+        };
+
+        mcspi4: spi at 480ba000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x480ba000 0x200>;
+            interrupts = <0 48 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi4";

arch/arm/boot/dts/dra7.dtsi line 488

Quoted 7 lines

arch/arm/boot/dts/dra7.dtsi new file +6 -0

+            ti,spi-num-cs = <1>;
+            dmas = <&sdma 70>, <&sdma 71>;
+            dma-names = "tx0", "rx0";
+        };
+    };
+};

ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]

would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?

[1] http://marc.info/?t=137416599400001&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=137510358229479&w=2

Quoted 2 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

Quoted 14 lines

Quoted 14 lines

arch/arm/boot/dts/dra7.dtsi new file +13 -0

+        mcspi4: spi at 480ba000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x480ba000 0x200>;
+            interrupts = <0 48 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi4";
+            ti,spi-num-cs = <1>;
+            dmas = <&sdma 70>, <&sdma 71>;
+            dma-names = "tx0", "rx0";
+        };
+    };
+};

Quoted 1 line

ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]

hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'

Quoted 2 lines

would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?

Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.

Quoted 5 lines

[1] http://marc.info/?t=137416599400001&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=137510358229479&w=2

[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html

Quoted 3 lines · Rajendra Nayak

Quoted 2 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

arch/arm/boot/dts/dra7.dtsi new file +13 -0

+        mcspi4: spi at 480ba000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x480ba000 0x200>;
+            interrupts = <0 48 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi4";
+            ti,spi-num-cs = <1>;
+            dmas = <&sdma 70>, <&sdma 71>;
+            dma-names = "tx0", "rx0";
+        };
+    };
+};

Quoted 3 lines

Quoted 1 line

ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]

hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'

I recommend reading the last few emails on the thread about how we could do this with pinctrl. unfortunately, this patch is not informative enough to indicate that not all instances of the potential IP blocks are listed here.

Quoted 4 lines

Quoted 2 lines

would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?

Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.

DRA7 case, I would not think it makes sense due to the number of product variants being done, not all will use the same set. Further, rationale for DRA7 and my suggestion for Grant's option (1) is mainly because the product variants will require more dtsis rather than board files using the product variants use just the necessary modules from a common dtsi. Makes support of variants like OMAP57xx etc trivial and constrainted to board file usage, rather than spinning off new dtsis.

Quoted 8 lines

Quoted 6 lines

[1] http://marc.info/?t=137416599400001&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=137510358229479&w=2

[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html

Quoted 26 lines · Nishanth Menon

Quoted 3 lines · Rajendra Nayak

Quoted 2 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

arch/arm/boot/dts/dra7.dtsi new file +13 -0

+        mcspi4: spi at 480ba000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x480ba000 0x200>;
+            interrupts = <0 48 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi4";
+            ti,spi-num-cs = <1>;
+            dmas = <&sdma 70>, <&sdma 71>;
+            dma-names = "tx0", "rx0";
+        };
+    };
+};

Quoted 3 lines

Quoted 1 line

ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]

hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'

I recommend reading the last few emails on the thread about how we could do this with pinctrl. unfortunately, this patch is not informative enough to indicate that not all instances of the potential IP blocks are listed here.

Quoted 1 line

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?

Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.

DRA7 case, I would not think it makes sense due to the number of product variants being done, not all will use the same set. Further, rationale for DRA7 and my suggestion for Grant's option (1) is mainly because the product variants will require more dtsis rather than board files using the product variants use just the necessary modules from a common dtsi. Makes support of variants like OMAP57xx etc trivial and constrainted to board file usage, rather than spinning off new dtsis.

Makes sense with the different product variants for DRA7, AM335x already does it this way, but the rest of OMAP3/4/5 are doing it the other way. I think its just too confusing to follow different conventions for different SoCs. We should stick to just one, either this way or that.

Quoted 10 lines

Quoted 8 lines

Quoted 6 lines

[1] http://marc.info/?t=137416599400001&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=137510358229479&w=2

[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html

Quoted 33 lines · Rajendra Nayak

Quoted 31 lines · Nishanth Menon

Quoted 3 lines · Rajendra Nayak

Quoted 2 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

arch/arm/boot/dts/dra7.dtsi new file +13 -0

+        mcspi4: spi at 480ba000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x480ba000 0x200>;
+            interrupts = <0 48 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi4";
+            ti,spi-num-cs = <1>;
+            dmas = <&sdma 70>, <&sdma 71>;
+            dma-names = "tx0", "rx0";
+        };
+    };
+};

Quoted 3 lines

Quoted 1 line

ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]

hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'

I recommend reading the last few emails on the thread about how we could do this with pinctrl. unfortunately, this patch is not informative enough to indicate that not all instances of the potential IP blocks are listed here.

Quoted 4 lines

Quoted 2 lines

would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?

Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.

DRA7 case, I would not think it makes sense due to the number of product variants being done, not all will use the same set. Further, rationale for DRA7 and my suggestion for Grant's option (1) is mainly because the product variants will require more dtsis rather than board files using the product variants use just the necessary modules from a common dtsi. Makes support of variants like OMAP57xx etc trivial and constrainted to board file usage, rather than spinning off new dtsis.

Quoted 3 lines

Makes sense with the different product variants for DRA7, AM335x already does it this way, but the rest of OMAP3/4/5 are doing it the other way. I think its just too confusing to follow different conventions for different SoCs. We should stick to just one, either this way or that.

I think bucketing DRA7(with multitude of SoC variants) with OMAP family(usually with <5 variants) will be a wrong approach. we should choose the approach appropriate for the SoC. hence, OMAPx having all default enabled makes sense (as the delta is usually trivial), but on DRA7, the variants are larger :(

just my 2 cents.

Quoted 12 lines

Quoted 11 lines

Quoted 9 lines

Quoted 7 lines

[1] http://marc.info/?t=137416599400001&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=137510358229479&w=2

[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html

Quoted 27 lines · Nishanth Menon

Quoted 26 lines · Rajendra Nayak

Quoted 25 lines · Nishanth Menon

Quoted 3 lines · Rajendra Nayak

Quoted 2 lines · Nishanth Menon

Quoted 1 line · Rajendra Nayak

From: R Sricharan <[email protected]>

[...]

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

(quoted diff) +13 -0

+        mcspi4: spi at 480ba000 {
+            compatible = "ti,omap4-mcspi";
+            reg = <0x480ba000 0x200>;
+            interrupts = <0 48 0x4>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+            ti,hwmods = "mcspi4";
+            ti,spi-num-cs = <1>;
+            dmas = <&sdma 70>, <&sdma 71>;
+            dma-names = "tx0", "rx0";
+        };
+    };
+};

Quoted 2 lines

Quoted 1 line

ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]

hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'

I recommend reading the last few emails on the thread about how we could do this with pinctrl. unfortunately, this patch is not informative enough to indicate that not all instances of the potential IP blocks are listed here.

Quoted 2 lines

Quoted 1 line

would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?

Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

DRA7 case, I would not think it makes sense due to the number of product variants being done, not all will use the same set. Further, rationale for DRA7 and my suggestion for Grant's option (1) is mainly because the product variants will require more dtsis rather than board files using the product variants use just the necessary modules from a common dtsi. Makes support of variants like OMAP57xx etc trivial and constrainted to board file usage, rather than spinning off new dtsis.

Makes sense with the different product variants for DRA7, AM335x already does it this way, but the rest of OMAP3/4/5 are doing it the other way. I think its just too confusing to follow different conventions for different SoCs. We should stick to just one, either this way or that.

I think bucketing DRA7(with multitude of SoC variants) with OMAP family(usually with <5 variants) will be a wrong approach. we should choose the approach appropriate for the SoC. hence, OMAPx having all default enabled makes sense (as the delta is usually trivial), but on DRA7, the variants are larger :(

just my 2 cents.

I can respin with the changes, but before I do so, Benoit do you agree with the rationale for these and fine with the approach?

From: R Sricharan <[email protected]>

Add minimal device tree source needed for DRA7 based SoCs. Also add a board dts file for the dra7-evm (based on dra752) which contains 1.5G of memory with 1G interleaved and 512MB non-interleaved. Also added in the board file are pin configuration details for i2c, mcspi and uart devices on board.

Signed-off-by R Sricharan <[email protected]>

Signed-off-by Rajendra Nayak <[email protected]>

Signed-off-by Sourav Poddar <[email protected]>

---
 arch/arm/boot/dts/Makefile     |    3 +-
 arch/arm/boot/dts/dra7-evm.dts |  163 ++++++++++++++
 arch/arm/boot/dts/dra7.dtsi    |  488 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 653 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/dra7-evm.dts
 create mode 100644 arch/arm/boot/dts/dra7.dtsi

arch/arm/boot/dts/dra7.dtsi new file +28 -0

new file mode 100644
index 0000000..8a0c08e
@@ -0,0 +1,488 @@
+/*
+ * Copyright (C) 2013 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.
+ * Based on "omap4.dtsi"
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+       compatible = "ti,dra7xx";
+       interrupt-parent = <&gic>;
+
+       aliases {
+               serial0 = &uart1;
+               serial1 = &uart2;
+               serial2 = &uart3;
+               serial3 = &uart4;
+               serial4 = &uart5;
+               serial5 = &uart6;
+       };
+
+       cpus {
+               cpu at 0 {
+                       compatible = "arm,cortex-a15";
+                       timer {

Quoted 5 lines

(quoted diff) +5 -0

+
+       cpus {
+               cpu at 0 {
+                       compatible = "arm,cortex-a15";
+                       timer {

Review

Quoted 10 lines

(quoted diff) +10 -0

+                               compatible = "arm,armv7-timer";
+                               /*
+                                * PPI secure/nonsecure IRQ,
+                                * active low level-sensitive
+                                */
+                               interrupts = <1 13 0x308>,
+                                            <1 14 0x308>;
+                               clock-frequency = <6144000>;
+                       };
+               };

The cpu nodes should have a reg matching their unit-address, and a device_type = "cpu".

The timer nodes should *not* be under the CPU nodes. They should be under under the root node. I realise that it makes intuitive sense to describe per-cpu resources this way, but that's not the way the bindings are intended to be used (does thei DT even work?).

No virtual/hypervisor interrupts?

Do you really need the clock-frequency property? It's far preferrable to have your bootloader do the right thing and program CNTFRQ with the correct value.

From 4d2e7cfe8a44448a37686a4af26f320ab0d66acb Mon Sep 17 00:00:00 2001

[]..

Quoted 24 lines

Quoted 5 lines

arch/arm/boot/dts/dra7.dtsi new file +5 -0

+
+       cpus {
+               cpu at 0 {
+                       compatible = "arm,cortex-a15";
+                       timer {

arch/arm/boot/dts/dra7.dtsi line 73

Quoted 10 lines

arch/arm/boot/dts/dra7.dtsi new file +10 -0

+                               compatible = "arm,armv7-timer";
+                               /*
+                                * PPI secure/nonsecure IRQ,
+                                * active low level-sensitive
+                                */
+                               interrupts = <1 13 0x308>,
+                                            <1 14 0x308>;
+                               clock-frequency = <6144000>;
+                       };
+               };

The cpu nodes should have a reg matching their unit-address, and a device_type = "cpu".

The timer nodes should *not* be under the CPU nodes. They should be under under the root node. I realise that it makes intuitive sense to describe per-cpu resources this way, but that's not the way the bindings are intended to be used (does thei DT even work?).

Quoted 1 line

No virtual/hypervisor interrupts?

Mark, all valid points. I just updated the patch to include all the missing interrupts and registers for timer and gic and moved the timer node out as its supposed to be.

Quoted 5 lines

Do you really need the clock-frequency property? It's far preferrable to have your bootloader do the right thing and program CNTFRQ with the correct value.

I kept the clock-frequency property since our bootloader does not handle this and I am not sure if its a good idea to have the dependency on bootloader to do this.

[Adding Marc to Cc]

Quoted 29 lines · Rajendra Nayak

[]..

Quoted 16 lines

Quoted 5 lines

arch/arm/boot/dts/dra7.dtsi new file +5 -0

+
+       cpus {
+               cpu at 0 {
+                       compatible = "arm,cortex-a15";
+                       timer {

arch/arm/boot/dts/dra7.dtsi line 73

Quoted 10 lines

arch/arm/boot/dts/dra7.dtsi new file +10 -0

+                               compatible = "arm,armv7-timer";
+                               /*
+                                * PPI secure/nonsecure IRQ,
+                                * active low level-sensitive
+                                */
+                               interrupts = <1 13 0x308>,
+                                            <1 14 0x308>;
+                               clock-frequency = <6144000>;
+                       };
+               };

Quoted 4 lines

The cpu nodes should have a reg matching their unit-address, and a device_type = "cpu".

The timer nodes should *not* be under the CPU nodes. They should

be

Quoted 1 line

under under the root node. I realise that it makes intuitive sense

to

Quoted 1 line

describe per-cpu resources this way, but that's not the way the

bindings

Quoted 2 lines

are intended to be used (does thei DT even work?).

Quoted 7 lines

Quoted 1 line

No virtual/hypervisor interrupts?

Mark, all valid points. I just updated the patch to include all the missing
interrupts and registers for timer and gic and moved the timer node out as
its supposed to be.

Great!

Quoted 5 lines

Quoted 3 lines

Do you really need the clock-frequency property? It's far

preferrable to

Quoted 1 line

have your bootloader do the right thing and program CNTFRQ with

Quoted 8 lines

the

Quoted 1 line

correct value.

I kept the clock-frequency property since our bootloader does not handle this
and I am not sure if its a good idea to have the dependency on bootloader
to do this.

There is precedent for handling it this way, but it would be far nicer
to fix the bootloader to set CNTFRQ. For one thing it's only writeable
from the secure side, so a host os can't fix it up for guests that might
depend on it rather than dt. I realise it's not necessarily as simple as
it sounds to fix that up, however.

Quoted 47 lines · Mark Rutland

[Adding Marc to Cc]

Quoted 26 lines · Rajendra Nayak

[]..

Quoted 24 lines

Quoted 5 lines

arch/arm/boot/dts/dra7.dtsi new file +5 -0

+
+       cpus {
+               cpu at 0 {
+                       compatible = "arm,cortex-a15";
+                       timer {

arch/arm/boot/dts/dra7.dtsi line 73

Quoted 10 lines

arch/arm/boot/dts/dra7.dtsi new file +10 -0

+                               compatible = "arm,armv7-timer";
+                               /*
+                                * PPI secure/nonsecure IRQ,
+                                * active low level-sensitive
+                                */
+                               interrupts = <1 13 0x308>,
+                                            <1 14 0x308>;
+                               clock-frequency = <6144000>;
+                       };
+               };

The cpu nodes should have a reg matching their unit-address, and a device_type = "cpu".

The timer nodes should *not* be under the CPU nodes. They should be under under the root node. I realise that it makes intuitive sense to describe per-cpu resources this way, but that's not the way the bindings are intended to be used (does thei DT even work?).

Quoted 5 lines

Quoted 1 line

No virtual/hypervisor interrupts?

Mark, all valid points. I just updated the patch to include all the missing interrupts and registers for timer and gic and moved the timer node out as its supposed to be.

Great!

Quoted 9 lines

Quoted 5 lines

Do you really need the clock-frequency property? It's far preferrable to have your bootloader do the right thing and program CNTFRQ with the correct value.

I kept the clock-frequency property since our bootloader does not handle this and I am not sure if its a good idea to have the dependency on bootloader to do this.

Quoted 5 lines

There is precedent for handling it this way, but it would be far nicer to fix the bootloader to set CNTFRQ. For one thing it's only writeable from the secure side, so a host os can't fix it up for guests that might depend on it rather than dt. I realise it's not necessarily as simple as it sounds to fix that up, however.

Indeed, having the wrong CNTFRQ in the host has the unfortunate effect of propagating the crap into the guests.

While this can be worked around for Linux guests (you have to hack the DT passed to the guests, which is very unpleasant at best and varies from one host to another), there is nothing you can do for non-DT guests.

So please, fix it in your firmware/boot-ROM while it is still time.

Thanks,

        M.

Changes in v2:
-1- Fixed minor changelog details
-2- Dropped the SRAM support patch since we need to move to drivers/misc/sram.c -3- Added DTS update patches to this series which were earlier posted as part of the data series (Since they don't have much objections as against the other in-kernel data files)
-4- Updated the EVM dts file with pin config details for uart/mcspi and i2c

DRA7xx based SoCs' are high-performance, infotainment application devices, based on enhanced OMAP architecture integrated on a 28nm technology.

The DRA7xx family is composed of DRA75x and DRA74x devices. The current device for which the patches add support is the DRA752 SoC.

Most of the core IPs are similar to those found on the OMAP5 devices, including the dual cortex-A15 based MPU subsystem, which has helped quite some reuse from existing OMAP5 support.

This series contains only core support patches and none of the PRCM and hwmod data needed for the device to boot.

The bootloader support for the platform is already available in mainline u-boot.

The patches posted in this series are available at:
git://github.com/rrnayak/linux.git for-3.12/dra-core-v2

The patches (including the ones for in-kernel data) which boot on dra7xx evm are available at:
t://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v2

R Sricharan (7):
ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
ARM: DRA7: Reuse io tables and add a new .init_early
ARM: DRA7: Resue the clocksource, clockevent support
ARM: DRA7: board-generic: Add basic DT support
ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512
ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board

Rajendra Nayak (1):
ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5

Quoted 42 lines · Rajendra Nayak

Changes in v2:
-1- Fixed minor changelog details
-2- Dropped the SRAM support patch since we need to move to drivers/misc/sram.c -3- Added DTS update patches to this series which were earlier posted as part of the data series (Since they don't have much objections as against the other in-kernel data files)
-4- Updated the EVM dts file with pin config details for uart/mcspi and i2c

DRA7xx based SoCs' are high-performance, infotainment application devices, based on enhanced OMAP architecture integrated on a 28nm technology.

The DRA7xx family is composed of DRA75x and DRA74x devices. The current device for which the patches add support is the DRA752 SoC.

Most of the core IPs are similar to those found on the OMAP5 devices, including the dual cortex-A15 based MPU subsystem, which has helped quite some reuse from existing OMAP5 support.

This series contains only core support patches and none of the PRCM and hwmod data needed for the device to boot.

The bootloader support for the platform is already available in mainline u-boot.

The patches posted in this series are available at:
git://github.com/rrnayak/linux.git for-3.12/dra-core-v2

The patches (including the ones for in-kernel data) which boot on dra7xx evm are available at:
t://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v2

R Sricharan (7):
ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
ARM: DRA7: Reuse io tables and add a new .init_early
ARM: DRA7: Resue the clocksource, clockevent support
ARM: DRA7: board-generic: Add basic DT support
ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512
ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board

Quoted 3 lines

Rajendra Nayak (1):
ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5

I quickly scanned the series and largely it looks good to me. The suggestion on dts and soc_id seems to be the valid ones and good to address them. Feel free to add my ack when you respin the series with those couple of issues addressed.

Regards,
Santosh