[PATCH v2 00/14] ARM: OMAP2+: AM43x initial support

[PATCH v2 00/14] ARM: OMAP2+: AM43x initial support

[Afzal Mohammed]

Hi,

This series adds initial support for AM43x based SoC's. To boot
AM43x, in addition to these patches, PRCM support is also needed,
which would be posted later as a separate series. DT sources doesn't
have "ti,hwmod" entry - this would be added along with PRCM support.

AM43x SoC's are based on ARM Cortex-A9 with one core. AM43x is similar
to AM335x in it's peripheral capabilities, except a few additional
ones, with many of the peripheral register mapping's similar. AM43x
has a sync timer, which is being used as clocksource. Clockevent used
is 1ms dmtimer.

SoC has PL310 L2 cache, support for it would be added later.

soc_is_am43xx() is introduced to handle AM43x specific details and
soc_is_am437x() is a subclass of it - first member of the class.

AM43x is currently in pre-silicon stage and currently there are no
public documents.

This has been tested on a pre-silicon platform that emulates AM43x SoC
with additional changes on top of this.

AM335x based board (AM335x EVM) has been verfied to boot as earlier
with this series.

Baseline: v3.10-rc3
Dependency: "ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature"
		by Vaibhav Hiremath <hvaibhav@ti.com>

Regards
Afzal

v2: Major change - use SoC timer's outside of ARM instead of depending
	on ARM SMP local timer for clockevent/source.

Afzal Mohammed (13):
  ARM: OMAP2+: separate out OMAP4 restart
  ARM: OMAP2+: AM43x: Kconfig
  ARM: OMAP2+: AM43x: kbuild
  ARM: OMAP2+: AM43x: soc_is support
  ARM: OMAP2+: AM437x: SoC revision detection
  ARM: OMAP2+: AM43x: static mapping
  ARM: OMAP2+: AM43x: early init
  ARM: OMAP2+: AM43x: GP or HS ?
  ARM: OMAP2+: AM43x: basic dt support
  Documentation: dt: binding: omap: am43x timer
  Documentation: dt: binding: omap: am43x counter
  Documentation: dt: binding: serial: omap: am43x
  ARM: dts: AM43x: initial support

Sanjeev Premi (1):
  ARM: OMAP2+: AM43x: SRAM base and size

 .../devicetree/bindings/arm/omap/counter.txt       |  1 +
 .../devicetree/bindings/arm/omap/timer.txt         |  2 +
 .../devicetree/bindings/serial/omap_serial.txt     |  1 +
 arch/arm/boot/dts/am4372.dtsi                      | 66 ++++++++++++++++++++++
 arch/arm/mach-omap2/Kconfig                        | 10 ++++
 arch/arm/mach-omap2/Makefile                       |  8 +++
 arch/arm/mach-omap2/am33xx.h                       |  1 +
 arch/arm/mach-omap2/board-generic.c                | 16 ++++++
 arch/arm/mach-omap2/cm33xx.h                       |  2 +-
 arch/arm/mach-omap2/common.h                       |  1 +
 arch/arm/mach-omap2/id.c                           |  8 ++-
 arch/arm/mach-omap2/io.c                           | 18 +++++-
 arch/arm/mach-omap2/omap4-common.c                 | 16 ------
 arch/arm/mach-omap2/omap4-restart.c                | 27 +++++++++
 arch/arm/mach-omap2/soc.h                          | 23 ++++++++
 arch/arm/mach-omap2/sram.c                         |  3 +
 arch/arm/mach-omap2/timer.c                        |  2 +-
 17 files changed, 184 insertions(+), 21 deletions(-)
 create mode 100644 arch/arm/boot/dts/am4372.dtsi
 create mode 100644 arch/arm/mach-omap2/omap4-restart.c

-- 
1.7.12

[PATCH v2 01/14] ARM: OMAP2+: separate out OMAP4 restart

[Afzal Mohammed]

Separate out OMAP4 restart and have it similar to other platforms, in
a different file. Main motive is to reuse omap4-common on platforms
other than OMAP4, like AM43x, even if OMAP4 is deselected (otherwise
would have caused build breakage).

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/Makefile        |  2 ++
 arch/arm/mach-omap2/omap4-common.c  | 16 ----------------
 arch/arm/mach-omap2/omap4-restart.c | 27 +++++++++++++++++++++++++++
 3 files changed, 29 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap4-restart.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 55a9d67..0fac8f4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -58,6 +58,8 @@ obj-$(CONFIG_SOC_OMAP2420)		+= omap2-restart.o
 obj-$(CONFIG_SOC_OMAP2430)		+= omap2-restart.o
 obj-$(CONFIG_SOC_AM33XX)		+= am33xx-restart.o
 obj-$(CONFIG_ARCH_OMAP3)		+= omap3-restart.o
+obj-$(CONFIG_ARCH_OMAP4)		+= omap4-restart.o
+obj-$(CONFIG_SOC_OMAP5)			+= omap4-restart.o
 
 # Pin multiplexing
 obj-$(CONFIG_SOC_OMAP2420)		+= mux2420.o
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 13b27ff..38cd3a6 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -339,19 +339,3 @@ int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
 	return 0;
 }
 #endif
-
-/**
- * omap44xx_restart - trigger a software restart of the SoC
- * @mode: the "reboot mode", see arch/arm/kernel/{setup,process}.c
- * @cmd: passed from the userspace program rebooting the system (if provided)
- *
- * Resets the SoC.  For @cmd, see the 'reboot' syscall in
- * kernel/sys.c.  No return value.
- */
-void omap44xx_restart(char mode, const char *cmd)
-{
-	/* XXX Should save 'cmd' into scratchpad for use after reboot */
-	omap4_prminst_global_warm_sw_reset(); /* never returns */
-	while (1);
-}
-
diff --git a/arch/arm/mach-omap2/omap4-restart.c b/arch/arm/mach-omap2/omap4-restart.c
new file mode 100644
index 0000000..f90e02e
--- /dev/null
+++ b/arch/arm/mach-omap2/omap4-restart.c
@@ -0,0 +1,27 @@
+/*
+ * omap4-restart.c - Common to OMAP4 and OMAP5
+ *
+ *
+ * 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/types.h>
+#include "prminst44xx.h"
+
+/**
+ * omap44xx_restart - trigger a software restart of the SoC
+ * @mode: the "reboot mode", see arch/arm/kernel/{setup,process}.c
+ * @cmd: passed from the userspace program rebooting the system (if provided)
+ *
+ * Resets the SoC.  For @cmd, see the 'reboot' syscall in
+ * kernel/sys.c.  No return value.
+ */
+void omap44xx_restart(char mode, const char *cmd)
+{
+	/* XXX Should save 'cmd' into scratchpad for use after reboot */
+	omap4_prminst_global_warm_sw_reset(); /* never returns */
+	while (1)
+		;
+}
-- 
1.7.12

[PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig

[Afzal Mohammed]

Kconfig for AM43x (Cortex A9) family of SoC's.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---

v2: Remove reliance on SMP, TWD, select MACH_OMAP_GENERIC

 arch/arm/mach-omap2/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f49cd51..8f555f8 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -149,6 +149,16 @@ config SOC_AM33XX
 	select MULTI_IRQ_HANDLER
 	select COMMON_CLK
 
+config SOC_AM43XX
+	bool "TI AM43x"
+	depends on ARCH_OMAP2PLUS
+	default y
+	select CPU_V7
+	select MULTI_IRQ_HANDLER
+	select ARM_GIC
+	select COMMON_CLK
+	select MACH_OMAP_GENERIC
+
 config OMAP_PACKAGE_ZAF
        bool
 
-- 
1.7.12

[PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig

[Tony Lindgren]

* Afzal Mohammed <afzal@ti.com> [130527 07:41]:
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -149,6 +149,16 @@ config SOC_AM33XX
>  	select MULTI_IRQ_HANDLER
>  	select COMMON_CLK
>  
> +config SOC_AM43XX
> +	bool "TI AM43x"
> +	depends on ARCH_OMAP2PLUS
> +	default y
> +	select CPU_V7
> +	select MULTI_IRQ_HANDLER
> +	select ARM_GIC
> +	select COMMON_CLK
> +	select MACH_OMAP_GENERIC
> +
>  config OMAP_PACKAGE_ZAF
>         bool

I've updated this patch to remove the "default y" and
"depends on ARCH_OMAP2PLUS" entries for the usual reasons
and applied the first ten patches into omap-for-v3.11/soc.

Regards,

Tony

[PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig

[Mohammed, Afzal]

Hi Tony,

On Wed, Jun 12, 2013 at 22:42:00, Tony Lindgren wrote:

> I've updated this patch to remove the "default y" and
> "depends on ARCH_OMAP2PLUS" entries for the usual reasons
> and applied the first ten patches into omap-for-v3.11/soc.

Thanks.

Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
omap-for-v3.11/soc branch and omap soc pull request, can you
please help patch 10 also to go upstream.

Regards
Afzal

[PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig

[Tony Lindgren]

* Mohammed, Afzal <afzal@ti.com> [130613 00:04]:
> Hi Tony,
> 
> On Wed, Jun 12, 2013 at 22:42:00, Tony Lindgren wrote:
> 
> > I've updated this patch to remove the "default y" and
> > "depends on ARCH_OMAP2PLUS" entries for the usual reasons
> > and applied the first ten patches into omap-for-v3.11/soc.
> 
> Thanks.
> 
> Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
> omap-for-v3.11/soc branch and omap soc pull request, can you
> please help patch 10 also to go upstream.

Hmm if that's .dts changes, Benoit needs to queue that.

Regards,

Tony

[PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig

[Mohammed, Afzal]

Hi Tony,

On Thu, Jun 13, 2013 at 15:24:54, Tony Lindgren wrote:
> * Mohammed, Afzal <afzal@ti.com> [130613 00:04]:

> > Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
> > omap-for-v3.11/soc branch and omap soc pull request, can you
> > please help patch 10 also to go upstream.
> 
> Hmm if that's .dts changes, Benoit needs to queue that.

It is not dts change.

Patch 10 patches board-generic.c for DT boot (Benoit has already
picked up dts, that is patch 14).

Regards
Afzal

[PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig

[Tony Lindgren]

* Mohammed, Afzal <afzal@ti.com> [130613 03:08]:
> Hi Tony,
> 
> On Thu, Jun 13, 2013 at 15:24:54, Tony Lindgren wrote:
> > * Mohammed, Afzal <afzal@ti.com> [130613 00:04]:
> 
> > > Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
> > > omap-for-v3.11/soc branch and omap soc pull request, can you
> > > please help patch 10 also to go upstream.
> > 
> > Hmm if that's .dts changes, Benoit needs to queue that.
> 
> It is not dts change.
> 
> Patch 10 patches board-generic.c for DT boot (Benoit has already
> picked up dts, that is patch 14).

Oops OK sorry I must have miscounted the patches that looked
ready to apply. Will apply.

Regards,

Tony

[PATCH v2 03/14] ARM: OMAP2+: AM43x: kbuild

[Afzal Mohammed]

Build pieces that could be reused for AM43x - GIC related, secure
related and common PRCM.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/Makefile | 6 ++++++
 arch/arm/mach-omap2/cm33xx.h | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0fac8f4..955b643 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common)
 obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
 obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common)
 obj-$(CONFIG_SOC_OMAP5)	 += prm44xx.o $(hwmod-common) $(secure-common)
+obj-$(CONFIG_SOC_AM43XX) += $(hwmod-common) $(secure-common)
 
 ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
 obj-y += mcbsp.o
@@ -38,6 +39,7 @@ omap-4-5-common				=  omap4-common.o omap-wakeupgen.o \
 					   sleep44xx.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common) $(smp-y)
 obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common) $(smp-y)
+obj-$(CONFIG_SOC_AM43XX)		+= $(omap-4-5-common)
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
@@ -112,6 +114,7 @@ obj-$(CONFIG_ARCH_OMAP2)		+= prm2xxx_3xxx.o prm2xxx.o cm2xxx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= prm2xxx_3xxx.o prm3xxx.o cm3xxx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= vc3xxx_data.o vp3xxx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= prm33xx.o cm33xx.o
+obj-$(CONFIG_SOC_AM43XX)		+= prm33xx.o cm33xx.o
 omap-prcm-4-5-common			=  cminst44xx.o cm44xx.o prm44xx.o \
 					   prcm_mpu44xx.o prminst44xx.o \
 					   vc44xx_data.o vp44xx_data.o
@@ -128,6 +131,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= $(voltagedomain-common)
 obj-$(CONFIG_ARCH_OMAP4)		+= voltagedomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(voltagedomain-common)
 obj-$(CONFIG_SOC_AM33XX)                += voltagedomains33xx_data.o
+obj-$(CONFIG_SOC_AM43XX)		+= $(voltagedomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(voltagedomain-common)
 
 # OMAP powerdomain framework
@@ -142,6 +146,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= $(powerdomain-common)
 obj-$(CONFIG_ARCH_OMAP4)		+= powerdomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(powerdomain-common)
 obj-$(CONFIG_SOC_AM33XX)		+= powerdomains33xx_data.o
+obj-$(CONFIG_SOC_AM43XX)		+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(powerdomain-common)
 
 # PRCM clockdomain control
@@ -157,6 +162,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= $(clockdomain-common)
 obj-$(CONFIG_ARCH_OMAP4)		+= clockdomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(clockdomain-common)
 obj-$(CONFIG_SOC_AM33XX)		+= clockdomains33xx_data.o
+obj-$(CONFIG_SOC_AM43XX)		+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(clockdomain-common)
 
 # Clock framework
diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h
index 64f4baf..9d1f4fc 100644
--- a/arch/arm/mach-omap2/cm33xx.h
+++ b/arch/arm/mach-omap2/cm33xx.h
@@ -383,7 +383,7 @@ extern void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs);
 extern void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs);
 extern void am33xx_cm_clkdm_force_wakeup(s16 inst, u16 cdoffs);
 
-#ifdef CONFIG_SOC_AM33XX
+#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
 extern int am33xx_cm_wait_module_idle(u16 inst, s16 cdoffs,
 					u16 clkctrl_offs);
 extern void am33xx_cm_module_enable(u8 mode, u16 inst, s16 cdoffs,
-- 
1.7.12

[PATCH v2 04/14] ARM: OMAP2+: AM43x: soc_is support

[Afzal Mohammed]

soc_is support for AM43x family of SoC's. Only variant now is AM437x,
it is made as a subclass of AM43x.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/soc.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index fd4507b..f59fdcd 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -96,6 +96,15 @@
 # endif
 #endif
 
+#ifdef CONFIG_SOC_AM43XX
+# ifdef OMAP_NAME
+#  undef  MULTI_OMAP2
+#  define MULTI_OMAP2
+# else
+#  define OMAP_NAME am43xx
+# endif
+#endif
+
 /*
  * Omap device type i.e. EMU/HS/TST/GP/BAD
  */
@@ -187,6 +196,7 @@ 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)
 
 IS_TI_CLASS(81xx, 0x81)
 
@@ -202,6 +212,7 @@ IS_OMAP_SUBCLASS(543x, 0x543)
 IS_TI_SUBCLASS(816x, 0x816)
 IS_TI_SUBCLASS(814x, 0x814)
 IS_AM_SUBCLASS(335x, 0x335)
+IS_AM_SUBCLASS(437x, 0x437)
 
 #define cpu_is_omap24xx()		0
 #define cpu_is_omap242x()		0
@@ -214,6 +225,8 @@ IS_AM_SUBCLASS(335x, 0x335)
 #define soc_is_am35xx()			0
 #define soc_is_am33xx()			0
 #define soc_is_am335x()			0
+#define soc_is_am43xx()			0
+#define soc_is_am437x()			0
 #define cpu_is_omap44xx()		0
 #define cpu_is_omap443x()		0
 #define cpu_is_omap446x()		0
@@ -341,6 +354,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_am335x()		is_am335x()
 #endif
 
+#ifdef	CONFIG_SOC_AM43XX
+# undef soc_is_am43xx
+# undef soc_is_am437x
+# define soc_is_am43xx()		is_am43xx()
+# define soc_is_am437x()		is_am437x()
+#endif
+
 # if defined(CONFIG_ARCH_OMAP4)
 # undef cpu_is_omap44xx
 # undef cpu_is_omap443x
@@ -398,6 +418,9 @@ IS_OMAP_TYPE(3430, 0x3430)
 #define AM335X_REV_ES2_0	(AM335X_CLASS | (0x1 << 8))
 #define AM335X_REV_ES2_1	(AM335X_CLASS | (0x2 << 8))
 
+#define AM437X_CLASS		0x43700000
+#define AM437X_REV_ES1_0	AM437X_CLASS
+
 #define OMAP443X_CLASS		0x44300044
 #define OMAP4430_REV_ES1_0	(OMAP443X_CLASS | (0x10 << 8))
 #define OMAP4430_REV_ES2_0	(OMAP443X_CLASS | (0x20 << 8))
-- 
1.7.12

[PATCH v2 05/14] ARM: OMAP2+: AM437x: SoC revision detection

[Afzal Mohammed]

Detect 437x SoC revision.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/id.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 44be835..c9c3f7d 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -209,6 +209,8 @@ static void __init omap3_cpuinfo(void)
 		cpu_name = "TI816X";
 	} else if (soc_is_am335x()) {
 		cpu_name =  "AM335X";
+	} else if (soc_is_am437x()) {
+		cpu_name =  "AM437x";
 	} else if (cpu_is_ti814x()) {
 		cpu_name = "TI814X";
 	} else if (omap3_has_iva() && omap3_has_sgx()) {
@@ -443,6 +445,10 @@ void __init omap3xxx_check_revision(void)
 			break;
 		}
 		break;
+	case 0xb98c:
+		omap_revision = AM437X_REV_ES1_0;
+		cpu_rev = "1.0";
+		break;
 	case 0xb8f2:
 		switch (rev) {
 		case 0:
-- 
1.7.12

[PATCH v2 06/14] ARM: OMAP2+: AM43x: static mapping

[Afzal Mohammed]

AM43x L4 WKUP/PER mappings are similar to AM335x, reuse.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/io.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 06a8946..3a81221 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -202,7 +202,7 @@ static struct map_desc omapti81xx_io_desc[] __initdata = {
 };
 #endif
 
-#ifdef CONFIG_SOC_AM33XX
+#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
 static struct map_desc omapam33xx_io_desc[] __initdata = {
 	{
 		.virtual	= L4_34XX_VIRT,
@@ -318,7 +318,7 @@ void __init ti81xx_map_io(void)
 }
 #endif
 
-#ifdef CONFIG_SOC_AM33XX
+#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
 void __init am33xx_map_io(void)
 {
 	iotable_init(omapam33xx_io_desc, ARRAY_SIZE(omapam33xx_io_desc));
-- 
1.7.12

[PATCH v2 07/14] ARM: OMAP2+: AM43x: early init

[Afzal Mohammed]

Minimal early init - PRCM initialization not yet taken care.

Control module is similar (base address, feature register etc.) as
that of AM335x, while PRCM base address is different. Instead of
adding a new header file for AM43x, PRCM base address is added in
AM335x header file as it is similar to it to a large extent.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/am33xx.h |  1 +
 arch/arm/mach-omap2/common.h |  1 +
 arch/arm/mach-omap2/io.c     | 14 ++++++++++++++
 3 files changed, 16 insertions(+)

diff --git a/arch/arm/mach-omap2/am33xx.h b/arch/arm/mach-omap2/am33xx.h
index 43296c1..5eef093 100644
--- a/arch/arm/mach-omap2/am33xx.h
+++ b/arch/arm/mach-omap2/am33xx.h
@@ -21,6 +21,7 @@
 #define AM33XX_SCM_BASE		0x44E10000
 #define AM33XX_CTRL_BASE	AM33XX_SCM_BASE
 #define AM33XX_PRCM_BASE	0x44E00000
+#define AM43XX_PRCM_BASE	0x44DF0000
 #define AM33XX_TAP_BASE		(AM33XX_CTRL_BASE + 0x3FC)
 
 #endif /* __ASM_ARCH_AM33XX_H */
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index d555cf2..00f890e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -96,6 +96,7 @@ void am33xx_init_early(void);
 void am35xx_init_early(void);
 void ti81xx_init_early(void);
 void am33xx_init_early(void);
+void am43xx_init_early(void);
 void omap4430_init_early(void);
 void omap5_init_early(void);
 void omap3_init_late(void);	/* Do not use this one */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3a81221..f933f7f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -586,6 +586,20 @@ void __init am33xx_init_early(void)
 }
 #endif
 
+#ifdef CONFIG_SOC_AM43XX
+void __init am43xx_init_early(void)
+{
+	omap2_set_globals_tap(AM335X_CLASS,
+			      AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE));
+	omap2_set_globals_control(AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
+				  NULL);
+	omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE));
+	omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE), NULL);
+	omap3xxx_check_revision();
+	am33xx_check_features();
+}
+#endif
+
 #ifdef CONFIG_ARCH_OMAP4
 void __init omap4430_init_early(void)
 {
-- 
1.7.12

[PATCH v2 07/14] ARM: OMAP2+: AM43x: early init

[Tony Lindgren]

* Afzal Mohammed <afzal@ti.com> [130527 07:42]:
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -586,6 +586,20 @@ void __init am33xx_init_early(void)
>  }
>  #endif
>  
> +#ifdef CONFIG_SOC_AM43XX
> +void __init am43xx_init_early(void)
> +{
> +	omap2_set_globals_tap(AM335X_CLASS,
> +			      AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE));
> +	omap2_set_globals_control(AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
> +				  NULL);
> +	omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE));
> +	omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE), NULL);
> +	omap3xxx_check_revision();
> +	am33xx_check_features();
> +}
> +#endif
> +
>  #ifdef CONFIG_ARCH_OMAP4
>  void __init omap4430_init_early(void)
>  {

I've updated this to remove am33xx_check_features() that we don't
seem to have in the mainline yet.

Tony

[PATCH v2 08/14] ARM: OMAP2+: AM43x: GP or HS ?

[Afzal Mohammed]

Detect whether GP or HS, similar to the AM335x way.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/id.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index c9c3f7d..0c28ef6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -55,7 +55,7 @@ int omap_type(void)
 
 	if (cpu_is_omap24xx()) {
 		val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
-	} else if (soc_is_am33xx()) {
+	} else if (soc_is_am33xx() || soc_is_am43xx()) {
 		val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
 	} else if (cpu_is_omap34xx()) {
 		val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
-- 
1.7.12

[PATCH v2 09/14] ARM: OMAP2+: AM43x: SRAM base and size

[Afzal Mohammed]

From: Sanjeev Premi <premi@ti.com>

This definition corresponds to the L3_OCMC0,
as in case of AM33XX.

Signed-off-by: Sanjeev Premi <premi@ti.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/sram.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 0ff0f06..4bd0968 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -119,6 +119,9 @@ static void __init omap_detect_sram(void)
 		if (soc_is_am33xx()) {
 			omap_sram_start = AM33XX_SRAM_PA;
 			omap_sram_size = 0x10000; /* 64K */
+		} else if (soc_is_am43xx()) {
+			omap_sram_start = AM33XX_SRAM_PA;
+			omap_sram_size = SZ_256K;
 		} else if (cpu_is_omap34xx()) {
 			omap_sram_start = OMAP3_SRAM_PA;
 			omap_sram_size = 0x10000; /* 64K */
-- 
1.7.12

[PATCH v2 10/14] ARM: OMAP2+: AM43x: basic dt support

[Afzal Mohammed]

Describe minimal DT boot machine details for AM43x based SoC's. AM43x
SoC's are ARM Cortex-A9 based with one core. AM43x is similar to
AM335x w.r.t L4 PER/WKUP memory map. AM43x has a sync timer, here that
is being used as clocksource, while 1ms dmtimer as clockevent.

Signed-off-by: Ankur Kishore <a-kishore@ti.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---

v2: Rely on dmtimer & synctimer for clockevent/source, map peripheral
	memory as in AM335x

 arch/arm/mach-omap2/board-generic.c | 16 ++++++++++++++++
 arch/arm/mach-omap2/timer.c         |  2 +-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 88aa6b1..e5fbfed 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -185,3 +185,19 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)")
 	.restart	= omap44xx_restart,
 MACHINE_END
 #endif
+
+#ifdef CONFIG_SOC_AM43XX
+static const char *am43_boards_compat[] __initdata = {
+	"ti,am43",
+	NULL,
+};
+
+DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device Tree)")
+	.map_io		= am33xx_map_io,
+	.init_early	= am43xx_init_early,
+	.init_irq	= omap_gic_of_init,
+	.init_machine	= omap_generic_init,
+	.init_time	= omap3_sync32k_timer_init,
+	.dt_compat	= am43_boards_compat,
+MACHINE_END
+#endif
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8e0c390..5f148e7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -582,7 +582,7 @@ OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon",
 			2, "timer_sys_ck", NULL);
 #endif /* CONFIG_ARCH_OMAP2 */
 
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
 OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon",
 			2, "timer_sys_ck", NULL);
 OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
-- 
1.7.12

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Afzal Mohammed]

AM43x timer bindings.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
index d02e27c..70cb398 100644
--- a/Documentation/devicetree/bindings/arm/omap/timer.txt
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -14,6 +14,8 @@ Required properties:
 			ti,omap5430-timer (applicable to OMAP543x devices)
 			ti,am335x-timer	(applicable to AM335x devices)
 			ti,am335x-timer-1ms (applicable to AM335x devices)
+			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
+			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
 
 - reg:			Contains timer register address range (base address and
 			length).
-- 
1.7.12

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Jon Hunter]

On 27/05/13 15:37, Afzal Mohammed wrote:
> AM43x timer bindings.
> 
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>  Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
> index d02e27c..70cb398 100644
> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -14,6 +14,8 @@ Required properties:
>  			ti,omap5430-timer (applicable to OMAP543x devices)
>  			ti,am335x-timer	(applicable to AM335x devices)
>  			ti,am335x-timer-1ms (applicable to AM335x devices)
> +			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
> +			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
>  
>  - reg:			Contains timer register address range (base address and
>  			length).

If you are adding more compatibility strings, then this implies that the
AM43x timers are not 100% compatible with any other device listed (such
as am335x or any omap device). That's fine but you should state that in
the changelog. If the AM43x timer registers are 100% compatible with
existing devices you should not add these.

Jon

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Stephen Warren]

On 05/28/2013 03:25 PM, Jon Hunter wrote:
> 
> On 27/05/13 15:37, Afzal Mohammed wrote:
>> AM43x timer bindings.
>>
>> Signed-off-by: Afzal Mohammed <afzal@ti.com>
>> ---
>>  Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
>> index d02e27c..70cb398 100644
>> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
>> @@ -14,6 +14,8 @@ Required properties:
>>  			ti,omap5430-timer (applicable to OMAP543x devices)
>>  			ti,am335x-timer	(applicable to AM335x devices)
>>  			ti,am335x-timer-1ms (applicable to AM335x devices)
>> +			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
>> +			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
>>  
>>  - reg:			Contains timer register address range (base address and
>>  			length).
> 
> If you are adding more compatibility strings, then this implies that the
> AM43x timers are not 100% compatible with any other device listed (such
> as am335x or any omap device). That's fine but you should state that in
> the changelog. If the AM43x timer registers are 100% compatible with
> existing devices you should not add these.

I'm not sure that's true; .dts files should always include a compatible
value that describes the most specific model of the HW, plus any
baseline compatible value that the HW is compatible with. This allows
any required quirks/fixes/... to be applied for the specific HW model
later even if nobody knows right now they'll be needed. Hence, defining
new compatible values doesn't necessarily mean incompatible HW.

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Mohammed, Afzal]

Hi Jon,

On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
> On 05/28/2013 03:25 PM, Jon Hunter wrote:

> >>  			ti,am335x-timer	(applicable to AM335x devices)
> >>  			ti,am335x-timer-1ms (applicable to AM335x devices)
> >> +			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
> >> +			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one

> > If you are adding more compatibility strings, then this implies that the
> > AM43x timers are not 100% compatible with any other device listed (such
> > as am335x or any omap device). That's fine but you should state that in
> > the changelog. If the AM43x timer registers are 100% compatible with
> > existing devices you should not add these.
> 
> I'm not sure that's true; .dts files should always include a compatible
> value that describes the most specific model of the HW, plus any
> baseline compatible value that the HW is compatible with. This allows
> any required quirks/fixes/... to be applied for the specific HW model
> later even if nobody knows right now they'll be needed. Hence, defining
> new compatible values doesn't necessarily mean incompatible HW.

Stephen took words out of my finger ;)
 
Some explanations,

1. first compatible should be exact device [A], followed by compatible
model (if one)
2. Minor effort in getting DT right the first time may help prevent
difficult effort later modifying it (if a necessity comes), considering
the fact that DT sources has  to move out of Kernel at some point of
time. And DT is not supposed to be modified, which may cause difficulty
for the users (I had been a minor victim of this during rebase).

As we both were in GPMC land earlier, an example,

If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip
select, but one is not pinned out. Now assume that same IP is integrated
in another SoC (probably OMAP4 has rev 6). Here if we use same compatible
for both, driver cannot handle it properly (w/o knowledge about platform).
But if exact compatible is mentioned, without modifying DT (which should
be considered as a firmware) just by modifying Kernel, deciding based on
compatible would help achieve what is required.

Regards
Afzal

[A] http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Benoit Cousson]

Hi Afzal,

On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
> Hi Jon,
> 
> On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
>> On 05/28/2013 03:25 PM, Jon Hunter wrote:
> 
>>>>  			ti,am335x-timer	(applicable to AM335x devices)
>>>>  			ti,am335x-timer-1ms (applicable to AM335x devices)
>>>> +			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
>>>> +			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
> 
>>> If you are adding more compatibility strings, then this implies that the
>>> AM43x timers are not 100% compatible with any other device listed (such
>>> as am335x or any omap device). That's fine but you should state that in
>>> the changelog. If the AM43x timer registers are 100% compatible with
>>> existing devices you should not add these.
>>
>> I'm not sure that's true; .dts files should always include a compatible
>> value that describes the most specific model of the HW, plus any
>> baseline compatible value that the HW is compatible with. This allows
>> any required quirks/fixes/... to be applied for the specific HW model
>> later even if nobody knows right now they'll be needed. Hence, defining
>> new compatible values doesn't necessarily mean incompatible HW.
> 
> Stephen took words out of my finger ;)
>  
> Some explanations,I don;t 
> 
> 1. first compatible should be exact device [A], followed by compatible
> model (if one)
> 2. Minor effort in getting DT right the first time may help prevent
> difficult effort later modifying it (if a necessity comes), considering
> the fact that DT sources has  to move out of Kernel at some point of
> time. And DT is not supposed to be modified, which may cause difficulty
> for the users (I had been a minor victim of this during rebase).
> 
> As we both were in GPMC land earlier, an example,
> 
> If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip
> select, but one is not pinned out. Now assume that same IP is integrated
> in another SoC (probably OMAP4 has rev 6). Here if we use same compatible
> for both, driver cannot handle it properly (w/o knowledge about platform).
> But if exact compatible is mentioned, without modifying DT (which should
> be considered as a firmware) just by modifying Kernel, deciding based on
> compatible would help achieve what is required.

That's true for the DTS itself, but here your are changing the binding
documentation which is supposed to reflect the driver "interface" in the
Device Tree model description.

Since the driver does not support any new compatible string, you should
not update the binding.

The driver and the binding will have to be changed the day you will have
to update the driver to handle a bug / feature specific to that revision
(ti,am4372-timer).

Since this series does not seems to update the driver, you should not
update the bindings.

Regards,
Benoit

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Mohammed, Afzal]

Hi Benoit,

On Wed, May 29, 2013 at 14:09:18, Cousson, Benoit wrote:
> On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
> > On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
> >> On 05/28/2013 03:25 PM, Jon Hunter wrote:

> >>> If you are adding more compatibility strings, then this implies that the
> >>> AM43x timers are not 100% compatible with any other device listed (such
> >>> as am335x or any omap device). That's fine but you should state that in
> >>> the changelog. If the AM43x timer registers are 100% compatible with
> >>> existing devices you should not add these.
> >>
> >> I'm not sure that's true; .dts files should always include a compatible
> >> value that describes the most specific model of the HW, plus any
> >> baseline compatible value that the HW is compatible with. This allows
> >> any required quirks/fixes/... to be applied for the specific HW model
> >> later even if nobody knows right now they'll be needed. Hence, defining
> >> new compatible values doesn't necessarily mean incompatible HW.
> > 
> > Stephen took words out of my finger ;)
> >  
> > Some explanations,I don;t 
> > 
> > 1. first compatible should be exact device [A], followed by compatible
> > model (if one)
> > 2. Minor effort in getting DT right the first time may help prevent
> > difficult effort later modifying it (if a necessity comes), considering
> > the fact that DT sources has  to move out of Kernel at some point of
> > time. And DT is not supposed to be modified, which may cause difficulty
> > for the users (I had been a minor victim of this during rebase).
> > 
> > As we both were in GPMC land earlier, an example,
> > 
> > If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip
> > select, but one is not pinned out. Now assume that same IP is integrated
> > in another SoC (probably OMAP4 has rev 6). Here if we use same compatible
> > for both, driver cannot handle it properly (w/o knowledge about platform).
> > But if exact compatible is mentioned, without modifying DT (which should
> > be considered as a firmware) just by modifying Kernel, deciding based on
> > compatible would help achieve what is required.
> 
> That's true for the DTS itself, but here your are changing the binding
> documentation which is supposed to reflect the driver "interface" in the
> Device Tree model description.
> 
> Since the driver does not support any new compatible string, you should
> not update the binding.

I have a different opinion: Binding documentation is to be considered an
entity that is not a part of the Kernel, but currently is a part of the
Kernel for want of a better place. And binding is to be considered OS
agnostic being ignorant of any piece of software (driver here). Binding has
the authority to allow its usage in DT sources.

> The driver and the binding will have to be changed the day you will have
> to update the driver to handle a bug / feature specific to that revision
> (ti,am4372-timer).
> 
> Since this series does not seems to update the driver, you should not
> update the bindings.

I believe that updating binding is a prerequisite for making a new
DTS change, hence binding was updated first, then DTS. 

Regards
Afzal

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Benoit Cousson]

On 05/29/2013 11:58 AM, Mohammed, Afzal wrote:
> Hi Benoit,
> 
> On Wed, May 29, 2013 at 14:09:18, Cousson, Benoit wrote:
>> On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
>>> On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
>>>> On 05/28/2013 03:25 PM, Jon Hunter wrote:
> 
>>>>> If you are adding more compatibility strings, then this implies that the
>>>>> AM43x timers are not 100% compatible with any other device listed (such
>>>>> as am335x or any omap device). That's fine but you should state that in
>>>>> the changelog. If the AM43x timer registers are 100% compatible with
>>>>> existing devices you should not add these.
>>>>
>>>> I'm not sure that's true; .dts files should always include a compatible
>>>> value that describes the most specific model of the HW, plus any
>>>> baseline compatible value that the HW is compatible with. This allows
>>>> any required quirks/fixes/... to be applied for the specific HW model
>>>> later even if nobody knows right now they'll be needed. Hence, defining
>>>> new compatible values doesn't necessarily mean incompatible HW.
>>>
>>> Stephen took words out of my finger ;)
>>>  
>>> Some explanations,I don;t 
>>>
>>> 1. first compatible should be exact device [A], followed by compatible
>>> model (if one)
>>> 2. Minor effort in getting DT right the first time may help prevent
>>> difficult effort later modifying it (if a necessity comes), considering
>>> the fact that DT sources has  to move out of Kernel at some point of
>>> time. And DT is not supposed to be modified, which may cause difficulty
>>> for the users (I had been a minor victim of this during rebase).
>>>
>>> As we both were in GPMC land earlier, an example,
>>>
>>> If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip
>>> select, but one is not pinned out. Now assume that same IP is integrated
>>> in another SoC (probably OMAP4 has rev 6). Here if we use same compatible
>>> for both, driver cannot handle it properly (w/o knowledge about platform).
>>> But if exact compatible is mentioned, without modifying DT (which should
>>> be considered as a firmware) just by modifying Kernel, deciding based on
>>> compatible would help achieve what is required.
>>
>> That's true for the DTS itself, but here your are changing the binding
>> documentation which is supposed to reflect the driver "interface" in the
>> Device Tree model description.
>>
>> Since the driver does not support any new compatible string, you should
>> not update the binding.
> 
> I have a different opinion: Binding documentation is to be considered an
> entity that is not a part of the Kernel, but currently is a part of the
> Kernel for want of a better place. And binding is to be considered OS
> agnostic being ignorant of any piece of software (driver here).

OK, that part is correct, but instead of driver I should have said HW
device. The binding is supposed to identify a specific HW device
revision or family if some HW registers are there to identify the version.

> Binding has the authority to allow its usage in DT sources.

And in this case, you do not introduce any new revision.

There is no point to update the binding each time we add a new SoC
variant that will contain the exact same IP.

I think it will mainly confuse the user that will wonder what is
different in that version compare to the previous one, moreover we can
end up with hundred of entries for the exact same IP for nothing.

The real problem is due to the introduction of the SoC name in the
device compatible name. That does introduced a SoC level information
that is mostly irrelevant at device level. I can understand why it was
done for practical aspect when the IP version is not well identified,
but that can lead to this proliferation of new pointless bindings.

>> The driver and the binding will have to be changed the day you will have
>> to update the driver to handle a bug / feature specific to that revision
>> (ti,am4372-timer).
>>
>> Since this series does not seems to update the driver, you should not
>> update the bindings.
> 
> I believe that updating binding is a prerequisite for making a new
> DTS change, hence binding was updated first, then DTS.

I don't think so, as soon as you still use at least one documented
compatible binding in the DTS description.

It is not anyway really armless, it just adds much more confusion that
real useful information for my point of view.

Regards,
Benoit

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Mohammed, Afzal]

Hi Benoit,

On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote:

> And in this case, you do not introduce any new revision.
> 
> There is no point to update the binding each time we add a new SoC
> variant that will contain the exact same IP.
> 
> I think it will mainly confuse the user that will wonder what is
> different in that version compare to the previous one, moreover we can
> end up with hundred of entries for the exact same IP for nothing.
> 
> The real problem is due to the introduction of the SoC name in the
> device compatible name. That does introduced a SoC level information
> that is mostly irrelevant at device level. I can understand why it was
> done for practical aspect when the IP version is not well identified,
> but that can lead to this proliferation of new pointless bindings.

As opinions on $subject seems not yet to be conclusive, I plan to
rebase DTS patch (14/14) over your 'for_3.11/dts' branch (that makes
use of C preprocessor on OMAP DTS) and post separately dropping
11-14 patches, is that okay ?

Regards
Afzal

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Benoit Cousson]

Hi Afzal,

On 06/03/2013 09:49 AM, Mohammed, Afzal wrote:
> Hi Benoit,
> 
> On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote:
> 
>> And in this case, you do not introduce any new revision.
>>
>> There is no point to update the binding each time we add a new SoC
>> variant that will contain the exact same IP.
>>
>> I think it will mainly confuse the user that will wonder what is
>> different in that version compare to the previous one, moreover we can
>> end up with hundred of entries for the exact same IP for nothing.
>>
>> The real problem is due to the introduction of the SoC name in the
>> device compatible name. That does introduced a SoC level information
>> that is mostly irrelevant at device level. I can understand why it was
>> done for practical aspect when the IP version is not well identified,
>> but that can lead to this proliferation of new pointless bindings.
> 
> As opinions on $subject seems not yet to be conclusive, I plan to
> rebase DTS patch (14/14) over your 'for_3.11/dts' branch (that makes
> use of C preprocessor on OMAP DTS) and post separately dropping
> 11-14 patches, is that okay ?

Yes, that sounds good to me.

Thanks,
Benoit

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Stephen Warren]

On 05/29/2013 02:39 AM, Benoit Cousson wrote:
> Hi Afzal,
> 
> On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
>> Hi Jon,
>>
>> On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
>>> On 05/28/2013 03:25 PM, Jon Hunter wrote:
>>
>>>>>  			ti,am335x-timer	(applicable to AM335x devices)
>>>>>  			ti,am335x-timer-1ms (applicable to AM335x devices)
>>>>> +			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
>>>>> +			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
>>
>>>> If you are adding more compatibility strings, then this implies that the
>>>> AM43x timers are not 100% compatible with any other device listed (such
>>>> as am335x or any omap device). That's fine but you should state that in
>>>> the changelog. If the AM43x timer registers are 100% compatible with
>>>> existing devices you should not add these.
>>>
>>> I'm not sure that's true; .dts files should always include a compatible
>>> value that describes the most specific model of the HW, plus any
>>> baseline compatible value that the HW is compatible with. This allows
>>> any required quirks/fixes/... to be applied for the specific HW model
>>> later even if nobody knows right now they'll be needed. Hence, defining
>>> new compatible values doesn't necessarily mean incompatible HW.
>>
>> Stephen took words out of my finger ;)
>>  
>> Some explanations,I don;t 
>>
>> 1. first compatible should be exact device [A], followed by compatible
>> model (if one)
>> 2. Minor effort in getting DT right the first time may help prevent
>> difficult effort later modifying it (if a necessity comes), considering
>> the fact that DT sources has  to move out of Kernel at some point of
>> time. And DT is not supposed to be modified, which may cause difficulty
>> for the users (I had been a minor victim of this during rebase).
>>
>> As we both were in GPMC land earlier, an example,
>>
>> If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip
>> select, but one is not pinned out. Now assume that same IP is integrated
>> in another SoC (probably OMAP4 has rev 6). Here if we use same compatible
>> for both, driver cannot handle it properly (w/o knowledge about platform).
>> But if exact compatible is mentioned, without modifying DT (which should
>> be considered as a firmware) just by modifying Kernel, deciding based on
>> compatible would help achieve what is required.
> 
> That's true for the DTS itself, but here your are changing the binding
> documentation which is supposed to reflect the driver "interface" in the
> Device Tree model description.
> 
> Since the driver does not support any new compatible string, you should
> not update the binding.

I don't agree here; the DT binding should define all the required and/or
allowed values that must/should/can be present in the DT - the entire
legal schema. The set of all compatible values is included in that,
irrespective of whether a particular value actually (currently) defines
a different HW interface or not.

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Benoit Cousson]

Hi Stephen,

On 05/29/2013 05:27 PM, Stephen Warren wrote:
> On 05/29/2013 02:39 AM, Benoit Cousson wrote:
>> Hi Afzal,
>>
>> On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
>>> Hi Jon,
>>>
>>> On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
>>>> On 05/28/2013 03:25 PM, Jon Hunter wrote:
>>>
>>>>>>  			ti,am335x-timer	(applicable to AM335x devices)
>>>>>>  			ti,am335x-timer-1ms (applicable to AM335x devices)
>>>>>> +			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
>>>>>> +			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
>>>
>>>>> If you are adding more compatibility strings, then this implies that the
>>>>> AM43x timers are not 100% compatible with any other device listed (such
>>>>> as am335x or any omap device). That's fine but you should state that in
>>>>> the changelog. If the AM43x timer registers are 100% compatible with
>>>>> existing devices you should not add these.
>>>>
>>>> I'm not sure that's true; .dts files should always include a compatible
>>>> value that describes the most specific model of the HW, plus any
>>>> baseline compatible value that the HW is compatible with. This allows
>>>> any required quirks/fixes/... to be applied for the specific HW model
>>>> later even if nobody knows right now they'll be needed. Hence, defining
>>>> new compatible values doesn't necessarily mean incompatible HW.
>>>
>>> Stephen took words out of my finger ;)
>>>  
>>> Some explanations,I don;t 
>>>
>>> 1. first compatible should be exact device [A], followed by compatible
>>> model (if one)
>>> 2. Minor effort in getting DT right the first time may help prevent
>>> difficult effort later modifying it (if a necessity comes), considering
>>> the fact that DT sources has  to move out of Kernel at some point of
>>> time. And DT is not supposed to be modified, which may cause difficulty
>>> for the users (I had been a minor victim of this during rebase).
>>>
>>> As we both were in GPMC land earlier, an example,
>>>
>>> If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip
>>> select, but one is not pinned out. Now assume that same IP is integrated
>>> in another SoC (probably OMAP4 has rev 6). Here if we use same compatible
>>> for both, driver cannot handle it properly (w/o knowledge about platform).
>>> But if exact compatible is mentioned, without modifying DT (which should
>>> be considered as a firmware) just by modifying Kernel, deciding based on
>>> compatible would help achieve what is required.
>>
>> That's true for the DTS itself, but here your are changing the binding
>> documentation which is supposed to reflect the driver "interface" in the
>> Device Tree model description.
>>
>> Since the driver does not support any new compatible string, you should
>> not update the binding.
> 
> I don't agree here; the DT binding should define all the required and/or
> allowed values that must/should/can be present in the DT - the entire
> legal schema. The set of all compatible values is included in that,
> irrespective of whether a particular value actually (currently) defines
> a different HW interface or not.

Well, I tend to agree on the principle, but so far it was never really
done like that. That's not necessarily a good excuse, but if we start
adding new bindings for the huge number of OMAP|AM variants TI has been
introduced for 10 years, I'd rather use a wildcard than a exhaustive
list of all the devices.
Something like ti,[omap|am]*-timer for example .

Regards,
Benoit

[PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer

[Jon Hunter]

On 28/05/13 23:05, Stephen Warren wrote:
> On 05/28/2013 03:25 PM, Jon Hunter wrote:
>>
>> On 27/05/13 15:37, Afzal Mohammed wrote:
>>> AM43x timer bindings.
>>>
>>> Signed-off-by: Afzal Mohammed <afzal@ti.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
>>> index d02e27c..70cb398 100644
>>> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
>>> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
>>> @@ -14,6 +14,8 @@ Required properties:
>>>  			ti,omap5430-timer (applicable to OMAP543x devices)
>>>  			ti,am335x-timer	(applicable to AM335x devices)
>>>  			ti,am335x-timer-1ms (applicable to AM335x devices)
>>> +			"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
>>> +			"ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
>>>  
>>>  - reg:			Contains timer register address range (base address and
>>>  			length).
>>
>> If you are adding more compatibility strings, then this implies that the
>> AM43x timers are not 100% compatible with any other device listed (such
>> as am335x or any omap device). That's fine but you should state that in
>> the changelog. If the AM43x timer registers are 100% compatible with
>> existing devices you should not add these.
> 
> I'm not sure that's true; .dts files should always include a compatible
> value that describes the most specific model of the HW, plus any
> baseline compatible value that the HW is compatible with. This allows
> any required quirks/fixes/... to be applied for the specific HW model
> later even if nobody knows right now they'll be needed. Hence, defining
> new compatible values doesn't necessarily mean incompatible HW.

Yes that does seem to agree with what Grant had told me in the past [1].
So this is ok then. However, I still think that the changelog needs to
be vastly improved and more explicit about the changes.

Cheers
Jon

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/90551/focus=26447

[PATCH v2 12/14] Documentation: dt: binding: omap: am43x counter

[Afzal Mohammed]

AM43x 32K counter binding.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 Documentation/devicetree/bindings/arm/omap/counter.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt b/Documentation/devicetree/bindings/arm/omap/counter.txt
index 5bd8aa0..9c48dca 100644
--- a/Documentation/devicetree/bindings/arm/omap/counter.txt
+++ b/Documentation/devicetree/bindings/arm/omap/counter.txt
@@ -2,6 +2,7 @@ OMAP Counter-32K bindings
 
 Required properties:
 - compatible:	Must be "ti,omap-counter32k" for OMAP controllers
+		"ti,am4372-counter32k","ti,omap-counter32k" for AM43x counter
 - reg:		Contains timer register address range (base address and length)
 - ti,hwmods:	Name of the hwmod associated to the counter, which is typically
 		"counter_32k"
-- 
1.7.12

[PATCH v2 12/14] Documentation: dt: binding: omap: am43x counter

[Jon Hunter]

On 27/05/13 15:37, Afzal Mohammed wrote:
> AM43x 32K counter binding.
> 
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>  Documentation/devicetree/bindings/arm/omap/counter.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt b/Documentation/devicetree/bindings/arm/omap/counter.txt
> index 5bd8aa0..9c48dca 100644
> --- a/Documentation/devicetree/bindings/arm/omap/counter.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/counter.txt
> @@ -2,6 +2,7 @@ OMAP Counter-32K bindings
>  
>  Required properties:
>  - compatible:	Must be "ti,omap-counter32k" for OMAP controllers
> +		"ti,am4372-counter32k","ti,omap-counter32k" for AM43x counter
>  - reg:		Contains timer register address range (base address and length)
>  - ti,hwmods:	Name of the hwmod associated to the counter, which is typically
>  		"counter_32k"

Changelog should state why this is needed.

Jon

[PATCH v2 12/14] Documentation: dt: binding: omap: am43x counter

[Mohammed, Afzal]

Hi Jon,

On Wed, May 29, 2013 at 02:56:05, Jon Hunter wrote:

> Changelog should state why this is needed.

Please see my reply on 11/14 thread.

Regards
Afzal

[PATCH v2 13/14] Documentation: dt: binding: serial: omap: am43x

[Afzal Mohammed]

AM43x uart binding.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..f37fdda 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible : should be "ti,omap2-uart" for OMAP2 controllers
 - compatible : should be "ti,omap3-uart" for OMAP3 controllers
 - compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- compatible : "ti,am4372-uart","ti,omap2-uart" for AM43x controller
 - ti,hwmods : Must be "uart<n>", n being the instance number (1-based)
 
 Optional properties:
-- 
1.7.12

[PATCH v2 14/14] ARM: dts: AM43x: initial support

[Afzal Mohammed]

DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
represented here are the minimal DT nodes necessary to get kernel
booting.

In DT nodes, "ti,hwmod" property has not been added, this would be
added along with PRCM support for AM43x.

Signed-off-by: Ankur Kishore <a-kishore@ti.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---

v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer

 arch/arm/boot/dts/am4372.dtsi | 66 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)
 create mode 100644 arch/arm/boot/dts/am4372.dtsi

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
new file mode 100644
index 0000000..1d58298
--- /dev/null
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -0,0 +1,66 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 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,am4372", "ti,am43";
+	interrupt-parent = <&gic>;
+
+
+	aliases {
+		serial0 = &uart1;
+	};
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a9";
+		};
+	};
+
+	gic: interrupt-controller at 48241000 {
+		compatible = "arm,cortex-a9-gic";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0x48241000 0x1000>,
+		      <0x48240100 0x0100>;
+	};
+
+	ocp {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		uart1: serial at 44e09000 {
+			compatible = "ti,am4372-uart","ti,omap2-uart";
+			reg = <0x44e09000 0x2000>;
+			interrupts = <0 72 0x4>;
+		};
+
+		timer1: timer at 44e31000 {
+			compatible = "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
+			reg = <0x44e31000 0x400>;
+			interrupts = <0 67 0x4>;
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 48040000  {
+			compatible = "ti,am4372-timer","ti,am335x-timer";
+			reg = <0x48040000  0x400>;
+			interrupts = <0 68 0x4>;
+		};
+
+		counter32k: counter at 44e86000 {
+			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
+			reg = <0x44e86000 0x40>;
+		};
+	};
+};
-- 
1.7.12

[PATCH v2 14/14] ARM: dts: AM43x: initial support

[Benoit Cousson]

+ Florian

Hi Afzal,

On 05/27/2013 04:37 PM, Afzal Mohammed wrote:
> DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
> represented here are the minimal DT nodes necessary to get kernel
> booting.
> 
> In DT nodes, "ti,hwmod" property has not been added, this would be
> added along with PRCM support for AM43x.
> 
> Signed-off-by: Ankur Kishore <a-kishore@ti.com>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
> 
> v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer
> 
>  arch/arm/boot/dts/am4372.dtsi | 66 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am4372.dtsi
> 
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> new file mode 100644
> index 0000000..1d58298
> --- /dev/null
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -0,0 +1,66 @@
> +/*
> + * Device Tree Source for AM4372 SoC
> + *
> + * Copyright (C) 2013 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"

You can now use the C preprocessor statement instead of this one.
Florian already started doing the change [1].

Beside that detail, that patch looks good to me.
I'll pull it separately of the series.

Regards,
Benoit

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/98320

> +
> +/ {
> +	compatible = "ti,am4372", "ti,am43";
> +	interrupt-parent = <&gic>;
> +
> +
> +	aliases {
> +		serial0 = &uart1;
> +	};
> +
> +	cpus {
> +		cpu at 0 {
> +			compatible = "arm,cortex-a9";
> +		};
> +	};
> +
> +	gic: interrupt-controller at 48241000 {
> +		compatible = "arm,cortex-a9-gic";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		reg = <0x48241000 0x1000>,
> +		      <0x48240100 0x0100>;
> +	};
> +
> +	ocp {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		uart1: serial at 44e09000 {
> +			compatible = "ti,am4372-uart","ti,omap2-uart";
> +			reg = <0x44e09000 0x2000>;
> +			interrupts = <0 72 0x4>;
> +		};
> +
> +		timer1: timer at 44e31000 {
> +			compatible = "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
> +			reg = <0x44e31000 0x400>;
> +			interrupts = <0 67 0x4>;
> +			ti,timer-alwon;
> +		};
> +
> +		timer2: timer at 48040000  {
> +			compatible = "ti,am4372-timer","ti,am335x-timer";
> +			reg = <0x48040000  0x400>;
> +			interrupts = <0 68 0x4>;
> +		};
> +
> +		counter32k: counter at 44e86000 {
> +			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
> +			reg = <0x44e86000 0x40>;
> +		};
> +	};
> +};
> 

[PATCH v2 14/14] ARM: dts: AM43x: initial support

[Florian Vaussard]

Hello,

On 05/29/2013 10:53 AM, Benoit Cousson wrote:
> + Florian
>
> Hi Afzal,
>
> On 05/27/2013 04:37 PM, Afzal Mohammed wrote:
>> DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
>> represented here are the minimal DT nodes necessary to get kernel
>> booting.
>>
>> In DT nodes, "ti,hwmod" property has not been added, this would be
>> added along with PRCM support for AM43x.
>>
>> Signed-off-by: Ankur Kishore <a-kishore@ti.com>
>> Signed-off-by: Afzal Mohammed <afzal@ti.com>
>> ---
>>
>> v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer
>>
>>   arch/arm/boot/dts/am4372.dtsi | 66 +++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 66 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/am4372.dtsi
>>
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> new file mode 100644
>> index 0000000..1d58298
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -0,0 +1,66 @@
>> +/*
>> + * Device Tree Source for AM4372 SoC
>> + *
>> + * Copyright (C) 2013 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"
>
> You can now use the C preprocessor statement instead of this one.
> Florian already started doing the change [1].
>
> Beside that detail, that patch looks good to me.
> I'll pull it separately of the series.
>

If you pull the patch in your branch, I can take care of the changes 
when I rebase
my series. This will allow me to clean the 'interrupts' statements below 
as well.

Regards,

Florian

> Regards,
> Benoit
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/98320
>
>> +
>> +/ {
>> +	compatible = "ti,am4372", "ti,am43";
>> +	interrupt-parent = <&gic>;
>> +
>> +
>> +	aliases {
>> +		serial0 = &uart1;
>> +	};
>> +
>> +	cpus {
>> +		cpu at 0 {
>> +			compatible = "arm,cortex-a9";
>> +		};
>> +	};
>> +
>> +	gic: interrupt-controller at 48241000 {
>> +		compatible = "arm,cortex-a9-gic";
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		reg = <0x48241000 0x1000>,
>> +		      <0x48240100 0x0100>;
>> +	};
>> +
>> +	ocp {
>> +		compatible = "simple-bus";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		uart1: serial at 44e09000 {
>> +			compatible = "ti,am4372-uart","ti,omap2-uart";
>> +			reg = <0x44e09000 0x2000>;
>> +			interrupts = <0 72 0x4>;
>> +		};
>> +
>> +		timer1: timer at 44e31000 {
>> +			compatible = "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
>> +			reg = <0x44e31000 0x400>;
>> +			interrupts = <0 67 0x4>;
>> +			ti,timer-alwon;
>> +		};
>> +
>> +		timer2: timer at 48040000  {
>> +			compatible = "ti,am4372-timer","ti,am335x-timer";
>> +			reg = <0x48040000  0x400>;
>> +			interrupts = <0 68 0x4>;
>> +		};
>> +
>> +		counter32k: counter at 44e86000 {
>> +			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
>> +			reg = <0x44e86000 0x40>;
>> +		};
>> +	};
>> +};
>>
>

[PATCH v2 14/14] ARM: dts: AM43x: initial support

[Benoit Cousson]

On 05/29/2013 10:57 AM, Florian Vaussard wrote:
> Hello,
> 
> On 05/29/2013 10:53 AM, Benoit Cousson wrote:
>> + Florian
>>
>> Hi Afzal,
>>
>> On 05/27/2013 04:37 PM, Afzal Mohammed wrote:
>>> DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
>>> represented here are the minimal DT nodes necessary to get kernel
>>> booting.
>>>
>>> In DT nodes, "ti,hwmod" property has not been added, this would be
>>> added along with PRCM support for AM43x.
>>>
>>> Signed-off-by: Ankur Kishore <a-kishore@ti.com>
>>> Signed-off-by: Afzal Mohammed <afzal@ti.com>
>>> ---
>>>
>>> v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer
>>>
>>>   arch/arm/boot/dts/am4372.dtsi | 66
>>> +++++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 66 insertions(+)
>>>   create mode 100644 arch/arm/boot/dts/am4372.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/am4372.dtsi
>>> b/arch/arm/boot/dts/am4372.dtsi
>>> new file mode 100644
>>> index 0000000..1d58298
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/am4372.dtsi
>>> @@ -0,0 +1,66 @@
>>> +/*
>>> + * Device Tree Source for AM4372 SoC
>>> + *
>>> + * Copyright (C) 2013 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"
>>
>> You can now use the C preprocessor statement instead of this one.
>> Florian already started doing the change [1].
>>
>> Beside that detail, that patch looks good to me.
>> I'll pull it separately of the series.
>>
> 
> If you pull the patch in your branch, I can take care of the changes
> when I rebase
> my series. This will allow me to clean the 'interrupts' statements below
> as well.

Ooops, thanks, I missed that one.

Thanks,
Benoit

> 
> Regards,
> 
> Florian
> 
>> Regards,
>> Benoit
>>
>> [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/98320
>>
>>> +
>>> +/ {
>>> +    compatible = "ti,am4372", "ti,am43";
>>> +    interrupt-parent = <&gic>;
>>> +
>>> +
>>> +    aliases {
>>> +        serial0 = &uart1;
>>> +    };
>>> +
>>> +    cpus {
>>> +        cpu at 0 {
>>> +            compatible = "arm,cortex-a9";
>>> +        };
>>> +    };
>>> +
>>> +    gic: interrupt-controller at 48241000 {
>>> +        compatible = "arm,cortex-a9-gic";
>>> +        interrupt-controller;
>>> +        #interrupt-cells = <3>;
>>> +        reg = <0x48241000 0x1000>,
>>> +              <0x48240100 0x0100>;
>>> +    };
>>> +
>>> +    ocp {
>>> +        compatible = "simple-bus";
>>> +        #address-cells = <1>;
>>> +        #size-cells = <1>;
>>> +        ranges;
>>> +
>>> +        uart1: serial at 44e09000 {
>>> +            compatible = "ti,am4372-uart","ti,omap2-uart";
>>> +            reg = <0x44e09000 0x2000>;
>>> +            interrupts = <0 72 0x4>;
>>> +        };
>>> +
>>> +        timer1: timer at 44e31000 {
>>> +            compatible = "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
>>> +            reg = <0x44e31000 0x400>;
>>> +            interrupts = <0 67 0x4>;
>>> +            ti,timer-alwon;
>>> +        };
>>> +
>>> +        timer2: timer at 48040000  {
>>> +            compatible = "ti,am4372-timer","ti,am335x-timer";
>>> +            reg = <0x48040000  0x400>;
>>> +            interrupts = <0 68 0x4>;
>>> +        };
>>> +
>>> +        counter32k: counter at 44e86000 {
>>> +            compatible = "ti,am4372-counter32k","ti,omap-counter32k";
>>> +            reg = <0x44e86000 0x40>;
>>> +        };
>>> +    };
>>> +};
>>>
>>

[PATCH v2 00/14] ARM: OMAP2+: AM43x initial support

[Mohammed, Afzal]

Hi Tony,

On Mon, May 27, 2013 at 20:03:27, Mohammed, Afzal wrote:

> This series adds initial support for AM43x based SoC's. To boot
> AM43x, in addition to these patches, PRCM support is also needed,
> which would be posted later as a separate series. DT sources doesn't
> have "ti,hwmod" entry - this would be added along with PRCM support.
> 
> AM43x SoC's are based on ARM Cortex-A9 with one core. AM43x is similar
> to AM335x in it's peripheral capabilities, except a few additional
> ones, with many of the peripheral register mapping's similar. AM43x
> has a sync timer, which is being used as clocksource. Clockevent used
> is 1ms dmtimer.
> 
> SoC has PL310 L2 cache, support for it would be added later.
> 
> soc_is_am43xx() is introduced to handle AM43x specific details and
> soc_is_am437x() is a subclass of it - first member of the class.
> 
> AM43x is currently in pre-silicon stage and currently there are no
> public documents.
> 
> This has been tested on a pre-silicon platform that emulates AM43x SoC
> with additional changes on top of this.
> 
> AM335x based board (AM335x EVM) has been verfied to boot as earlier
> with this series.
> 
> Baseline: v3.10-rc3
> Dependency: "ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature"
> 		by Vaibhav Hiremath <hvaibhav@ti.com>

If you have any comments on this series please let me know, else if
you are okay with this, please consider patches 1-10 for inclusion
in the coming merge window.

Patch 14/14 has been taken by Benoit and patches 11-13 are to be
dropped (as per discussion in 11/14 thread)

Regards
Afzal