[PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[hvaibhav]

From: Afzal Mohammed <afzal@ti.com>

This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with device tree
developement we will get rid of board-*.c.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
---
 arch/arm/mach-omap2/Kconfig              |    5 +++++
 arch/arm/mach-omap2/Makefile             |    1 +
 arch/arm/mach-omap2/board-am3517evm.c    |   21 +++++++++++++++++++++
 arch/arm/mach-omap2/io.c                 |    7 +++++++
 arch/arm/mach-omap2/timer.c              |    2 ++
 arch/arm/plat-omap/include/plat/common.h |    2 ++
 6 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 09ea525..c0e4a70 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -326,6 +326,11 @@ config MACH_TI8168EVM
 	depends on SOC_OMAPTI816X
 	default y

+config MACH_AM335XEVM
+	bool "AM335X Evaluation Module"
+	depends on SOC_OMAPAM33XX
+	default y
+
 config MACH_OMAP_4430SDP
 	bool "OMAP 4430 SDP board"
 	default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a12a069..89099a3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -233,6 +233,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)		+= board-am3517crane.o

 obj-$(CONFIG_MACH_SBC3530)		+= board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)		+= board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM)		+= board-am3517evm.o

 # Platform specific device init code

diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index f7df8d3..090457f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -516,3 +516,24 @@ MACHINE_START(OMAP3517EVM, "OMAP3517/AM3517 EVM")
 	.init_machine	= am3517_evm_init,
 	.timer		= &omap3_timer,
 MACHINE_END
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_evm_init(void)
+{
+	omap_serial_init();
+	omap_sdrc_init(NULL, NULL);
+	omap_board_config = am335x_evm_config;
+	omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+}
+
+MACHINE_START(AM335XEVM, "am335xevm")
+	/* Maintainer: Texas Instruments */
+	.atag_offset	= 0x100,
+	.map_io		= am33xx_map_io,
+	.init_early	= am33xx_init_early,
+	.init_irq	= ti816x_init_irq,
+	.timer		= &omap3_am33xx_timer,
+	.init_machine	= am335x_evm_init,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 74e84c6..e958c04 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -460,6 +460,13 @@ void __init ti816x_init_early(void)
 	omap_hwmod_init_postsetup();
 	omap3xxx_clk_init();
 }
+
+void __init am33xx_init_early(void)
+{
+	omap2_set_globals_am33xx();
+	omap_common_init_early();
+	omap3xxx_clk_init();
+}
 #endif

 #ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 037b0d7..7b29197 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -333,6 +333,8 @@ OMAP_SYS_TIMER(3)
 OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
 			2, OMAP3_MPU_SOURCE)
 OMAP_SYS_TIMER(3_secure)
+OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER(3_am33xx)
 #endif

 #ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index bb8a6c1..9d7cc3c 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -39,6 +39,7 @@ extern struct sys_timer omap1_timer;
 extern struct sys_timer omap2_timer;
 extern struct sys_timer omap3_timer;
 extern struct sys_timer omap3_secure_timer;
+extern struct sys_timer omap3_am33xx_timer;
 extern struct sys_timer omap4_timer;
 extern bool omap_32k_timer_init(void);
 extern int __init omap_init_clocksource_32k(void);
@@ -55,6 +56,7 @@ void omap3_init_early(void);	/* Do not use this one */
 void am35xx_init_early(void);
 void ti816x_init_early(void);
 void omap4430_init_early(void);
+void am33xx_init_early(void);

 extern int omap_dss_reset(struct omap_hwmod *);

--
1.7.0.4

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Paul Walmsley]

Hi

On Fri, 2 Dec 2011, hvaibhav@ti.com wrote:

> From: Afzal Mohammed <afzal@ti.com>
> 
> This patch adds minimal support for AM335X EVM.
> The approach taken here is to add AM335X EVM support
> to AM3517EVM, considering the fact that with device tree
> developement we will get rid of board-*.c.
> 
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>

I realize people may not necessarily like this, but I think that the 
AM33xx EVM needs its own board file.  This is because it really has 
nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.

So the following modification of this patch opts for the former Kconfig 
option, CONFIG_ARCH_OMAPAM33XX.  It also adds a new, minimal board file 
for the AM33xx EVM.  

If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for 
the AM33xx, then we could potentially add the new machine record into 
board-omap4panda.c.  Although even then, if political considerations were 
set aside, the best technical decision would probably be to create a 
separate board file, since the boards don't have much in common.


- Paul

From: Afzal Mohammed <afzal@ti.com>
Date: Fri, 2 Dec 2011 12:13:23 +0530
Subject: [PATCH] ARM: OMAP: AM33xx: Add AM335XEVM machine support

This patch adds minimal support for AM335X EVM.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: created new board file for AM33xx; moved am33xx_init_early()
 outside of CONFIG_ARCH_OMAP3; modified commit message]
---
 arch/arm/mach-omap2/Kconfig           |    5 ++++
 arch/arm/mach-omap2/Makefile          |    1 +
 arch/arm/mach-omap2/board-am335xevm.c |   46 +++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/common.h          |    2 ++
 arch/arm/mach-omap2/io.c              |    8 ++++++
 arch/arm/mach-omap2/timer.c           |    2 ++
 6 files changed, 64 insertions(+)
 create mode 100644 arch/arm/mach-omap2/board-am335xevm.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5ae756a..d5aa936 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -335,6 +335,11 @@ config MACH_TI8148EVM
 	depends on SOC_OMAPTI81XX
 	default y
 
+config MACH_AM335XEVM
+	bool "AM335X Evaluation Module"
+	depends on SOC_OMAPAM33XX
+	default y
+
 config MACH_OMAP_4430SDP
 	bool "OMAP 4430 SDP board"
 	default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c538b3e..d3c33df 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -241,6 +241,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)		+= board-am3517crane.o
 obj-$(CONFIG_MACH_SBC3530)		+= board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)		+= board-ti8168evm.o
 obj-$(CONFIG_MACH_TI8148EVM)		+= board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM)		+= board-am335xevm.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-am335xevm.c b/arch/arm/mach-omap2/board-am335xevm.c
new file mode 100644
index 0000000..324752e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -0,0 +1,46 @@
+/*
+ * board-am335xevm.c - support the TI AM335x EVM board
+ *
+ * Copyright (C) 2011-2012 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+
+#include <mach/hardware.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <plat/board.h>
+#include "common.h"
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_evm_init(void)
+{
+	omap_serial_init();
+	omap_sdrc_init(NULL, NULL);
+	omap_board_config = am335x_evm_config;
+	omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+}
+
+MACHINE_START(AM335XEVM, "am335xevm")
+	/* Maintainer: Texas Instruments */
+	.atag_offset	= 0x100,
+	.map_io		= am33xx_map_io,
+	.init_early	= am33xx_init_early,
+	.init_irq	= ti81xx_init_irq,
+	.timer		= &omap3_am33xx_timer,
+	.init_machine	= am335x_evm_init,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 57da7f4..dae39a3 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -83,6 +83,7 @@ extern void omap2_init_common_infrastructure(void);
 extern struct sys_timer omap2_timer;
 extern struct sys_timer omap3_timer;
 extern struct sys_timer omap3_secure_timer;
+extern struct sys_timer omap3_am33xx_timer;
 extern struct sys_timer omap4_timer;
 
 void omap2420_init_early(void);
@@ -94,6 +95,7 @@ void omap3_init_early(void);	/* Do not use this one */
 void am35xx_init_early(void);
 void ti81xx_init_early(void);
 void omap4430_init_early(void);
+void am33xx_init_early(void);
 void omap_prcm_restart(char, const char *);
 
 /*
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 065bd76..056db56 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -466,6 +466,14 @@ void __init ti81xx_init_early(void)
 	omap_hwmod_init_postsetup();
 	omap3xxx_clk_init();
 }
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#ifdef CONFIG_SOC_OMAPAM33XX
+void __init am33xx_init_early(void)
+{
+	omap2_set_globals_am33xx();
+	omap_common_init_early();
+}
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c512bac..b2f747b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -321,6 +321,8 @@ OMAP_SYS_TIMER(3)
 OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
 			2, OMAP3_MPU_SOURCE)
 OMAP_SYS_TIMER(3_secure)
+OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER(3_am33xx)
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
-- 
1.7.10

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> Hi
> 
> On Fri, 2 Dec 2011, hvaibhav@ti.com wrote:
> 
> > From: Afzal Mohammed <afzal@ti.com>
> > 
> > This patch adds minimal support for AM335X EVM.
> > The approach taken here is to add AM335X EVM support
> > to AM3517EVM, considering the fact that with device tree
> > developement we will get rid of board-*.c.
> > 
> > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Reviewed-by: Kevin Hilman <khilman@ti.com>
> 
> I realize people may not necessarily like this, but I think that the 
> AM33xx EVM needs its own board file.  This is because it really has 
> nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> 
> So the following modification of this patch opts for the former Kconfig 
> option, CONFIG_ARCH_OMAPAM33XX.  It also adds a new, minimal board file 
> for the AM33xx EVM.  
> 
> If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for 
> the AM33xx, then we could potentially add the new machine record into 
> board-omap4panda.c.  Although even then, if political considerations were 
> set aside, the best technical decision would probably be to create a 
> separate board file, since the boards don't have much in common.
> 
> 
Paul,
I completely agree with all of your comments, let Tony comment and conform 
on this. 
If you go back to history, that was our initial proposal, to create
separate Kconfig option for AM33XX.

Tony,

Can you please comment on this discussion? This is very important, since 
lots of patches (accepted or about to accept) are dependent on this. The 
early we can conclude on this, early I can rework on the patches and 
resubmit them.

Thanks,
Vaibhav

> - Paul
> 
> From: Afzal Mohammed <afzal@ti.com>
> Date: Fri, 2 Dec 2011 12:13:23 +0530
> Subject: [PATCH] ARM: OMAP: AM33xx: Add AM335XEVM machine support
> 
> This patch adds minimal support for AM335X EVM.
> 
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> [paul@pwsan.com: created new board file for AM33xx; moved am33xx_init_early()
>  outside of CONFIG_ARCH_OMAP3; modified commit message]
> ---
>  arch/arm/mach-omap2/Kconfig           |    5 ++++
>  arch/arm/mach-omap2/Makefile          |    1 +
>  arch/arm/mach-omap2/board-am335xevm.c |   46 +++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/common.h          |    2 ++
>  arch/arm/mach-omap2/io.c              |    8 ++++++
>  arch/arm/mach-omap2/timer.c           |    2 ++
>  6 files changed, 64 insertions(+)
>  create mode 100644 arch/arm/mach-omap2/board-am335xevm.c
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 5ae756a..d5aa936 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -335,6 +335,11 @@ config MACH_TI8148EVM
>  	depends on SOC_OMAPTI81XX
>  	default y
>  
> +config MACH_AM335XEVM
> +	bool "AM335X Evaluation Module"
> +	depends on SOC_OMAPAM33XX
> +	default y
> +
>  config MACH_OMAP_4430SDP
>  	bool "OMAP 4430 SDP board"
>  	default y
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index c538b3e..d3c33df 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -241,6 +241,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)		+= board-am3517crane.o
>  obj-$(CONFIG_MACH_SBC3530)		+= board-omap3stalker.o
>  obj-$(CONFIG_MACH_TI8168EVM)		+= board-ti8168evm.o
>  obj-$(CONFIG_MACH_TI8148EVM)		+= board-ti8168evm.o
> +obj-$(CONFIG_MACH_AM335XEVM)		+= board-am335xevm.o
>  
>  # Platform specific device init code
>  
> diff --git a/arch/arm/mach-omap2/board-am335xevm.c b/arch/arm/mach-omap2/board-am335xevm.c
> new file mode 100644
> index 0000000..324752e
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-am335xevm.c
> @@ -0,0 +1,46 @@
> +/*
> + * board-am335xevm.c - support the TI AM335x EVM board
> + *
> + * Copyright (C) 2011-2012 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +
> +#include <mach/hardware.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +
> +#include <plat/board.h>
> +#include "common.h"
> +
> +static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
> +};
> +
> +static void __init am335x_evm_init(void)
> +{
> +	omap_serial_init();
> +	omap_sdrc_init(NULL, NULL);
> +	omap_board_config = am335x_evm_config;
> +	omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
> +}
> +
> +MACHINE_START(AM335XEVM, "am335xevm")
> +	/* Maintainer: Texas Instruments */
> +	.atag_offset	= 0x100,
> +	.map_io		= am33xx_map_io,
> +	.init_early	= am33xx_init_early,
> +	.init_irq	= ti81xx_init_irq,
> +	.timer		= &omap3_am33xx_timer,
> +	.init_machine	= am335x_evm_init,
> +MACHINE_END
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 57da7f4..dae39a3 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -83,6 +83,7 @@ extern void omap2_init_common_infrastructure(void);
>  extern struct sys_timer omap2_timer;
>  extern struct sys_timer omap3_timer;
>  extern struct sys_timer omap3_secure_timer;
> +extern struct sys_timer omap3_am33xx_timer;
>  extern struct sys_timer omap4_timer;
>  
>  void omap2420_init_early(void);
> @@ -94,6 +95,7 @@ void omap3_init_early(void);	/* Do not use this one */
>  void am35xx_init_early(void);
>  void ti81xx_init_early(void);
>  void omap4430_init_early(void);
> +void am33xx_init_early(void);
>  void omap_prcm_restart(char, const char *);
>  
>  /*
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 065bd76..056db56 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -466,6 +466,14 @@ void __init ti81xx_init_early(void)
>  	omap_hwmod_init_postsetup();
>  	omap3xxx_clk_init();
>  }
> +#endif /* CONFIG_ARCH_OMAP3 */
> +
> +#ifdef CONFIG_SOC_OMAPAM33XX
> +void __init am33xx_init_early(void)
> +{
> +	omap2_set_globals_am33xx();
> +	omap_common_init_early();
> +}
>  #endif
>  
>  #ifdef CONFIG_ARCH_OMAP4
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index c512bac..b2f747b 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -321,6 +321,8 @@ OMAP_SYS_TIMER(3)
>  OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
>  			2, OMAP3_MPU_SOURCE)
>  OMAP_SYS_TIMER(3_secure)
> +OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
> +OMAP_SYS_TIMER(3_am33xx)
>  #endif
>  
>  #ifdef CONFIG_ARCH_OMAP4
> -- 
> 1.7.10
> 
> 

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Tony Lindgren]

Hi,

* Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > Hi
> > 
> > On Fri, 2 Dec 2011, hvaibhav@ti.com wrote:
> > 
> > > From: Afzal Mohammed <afzal@ti.com>
> > > 
> > > This patch adds minimal support for AM335X EVM.
> > > The approach taken here is to add AM335X EVM support
> > > to AM3517EVM, considering the fact that with device tree
> > > developement we will get rid of board-*.c.
> > > 
> > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> > 
> > I realize people may not necessarily like this, but I think that the 
> > AM33xx EVM needs its own board file.  This is because it really has 
> > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.

I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
except core with omap3. And the SOC is independent of the core selected,
there is no dependency between SoC and the core.

Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
compile with different flags either.
 
> > So the following modification of this patch opts for the former Kconfig 
> > option, CONFIG_ARCH_OMAPAM33XX.  It also adds a new, minimal board file 
> > for the AM33xx EVM.  

Sorry, no more new board files. Please make it device tree only then.

> > If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for 
> > the AM33xx, then we could potentially add the new machine record into 
> > board-omap4panda.c.  Although even then, if political considerations were 
> > set aside, the best technical decision would probably be to create a 
> > separate board file, since the boards don't have much in common.
> > 
> > 
> Paul,
> I completely agree with all of your comments, let Tony comment and conform 
> on this. 
> If you go back to history, that was our initial proposal, to create
> separate Kconfig option for AM33XX.
> 
> Tony,
> 
> Can you please comment on this discussion? This is very important, since 
> lots of patches (accepted or about to accept) are dependent on this. The 
> early we can conclude on this, early I can rework on the patches and 
> resubmit them.

Yes, please do. Also note that if this means sprinkling tons of cpu_is_omapxxx
all over the code, we need to find a cleaner solution.

Regards,

Tony

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> Hi,
> 
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > > Hi
> > > 
> > > On Fri, 2 Dec 2011, hvaibhav@ti.com wrote:
> > > 
> > > > From: Afzal Mohammed <afzal@ti.com>
> > > > 
> > > > This patch adds minimal support for AM335X EVM.
> > > > The approach taken here is to add AM335X EVM support
> > > > to AM3517EVM, considering the fact that with device tree
> > > > developement we will get rid of board-*.c.
> > > > 
> > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> > > 
> > > I realize people may not necessarily like this, but I think that the 
> > > AM33xx EVM needs its own board file.  This is because it really has 
> > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> 
> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> except core with omap3. And the SOC is independent of the core selected,
> there is no dependency between SoC and the core.
> 
> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> compile with different flags either.
>  

What about cpu_is_omap34xx() true for am33xx? Should we follow it?


Thanks,
Vaibhav

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav@ti.com> [120503 09:45]:
> 
> What about cpu_is_omap34xx() true for am33xx? Should we follow it?

Well are there components that could be used as is with that?
If not, then it probably does not make sense.

BTW, you should post your patches on top of the clean-up patches
Santosh posted as that already leaves out some cpu_is_omapxxxx
checks. That's the "ARM: OMAP2+: Misc cleanup" thread.

Regards,

Tony

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Kevin Hilman]

"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:

> On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
>> Hi,
>> 
>> * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
>> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
>> > > Hi
>> > > 
>> > > On Fri, 2 Dec 2011, hvaibhav@ti.com wrote:
>> > > 
>> > > > From: Afzal Mohammed <afzal@ti.com>
>> > > > 
>> > > > This patch adds minimal support for AM335X EVM.
>> > > > The approach taken here is to add AM335X EVM support
>> > > > to AM3517EVM, considering the fact that with device tree
>> > > > developement we will get rid of board-*.c.
>> > > > 
>> > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
>> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
>> > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
>> > > 
>> > > I realize people may not necessarily like this, but I think that the 
>> > > AM33xx EVM needs its own board file.  This is because it really has 
>> > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
>> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
>> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
>> 
>> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
>> except core with omap3. And the SOC is independent of the core selected,
>> there is no dependency between SoC and the core.
>> 
>> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
>> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
>> compile with different flags either.
>>  
>
> What about cpu_is_omap34xx() true for am33xx? Should we follow it?

Please, no.

I've already demonstrated that that is not necessary and only leads to
confusion and maintenance headaches.

Kevin

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Fri, May 04, 2012 at 02:47:34, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
> 
> > On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> >> Hi,
> >> 
> >> * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> >> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> >> > > Hi
> >> > > 
> >> > > On Fri, 2 Dec 2011, hvaibhav@ti.com wrote:
> >> > > 
> >> > > > From: Afzal Mohammed <afzal@ti.com>
> >> > > > 
> >> > > > This patch adds minimal support for AM335X EVM.
> >> > > > The approach taken here is to add AM335X EVM support
> >> > > > to AM3517EVM, considering the fact that with device tree
> >> > > > developement we will get rid of board-*.c.
> >> > > > 
> >> > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> >> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> >> > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> >> > > 
> >> > > I realize people may not necessarily like this, but I think that the 
> >> > > AM33xx EVM needs its own board file.  This is because it really has 
> >> > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> >> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> >> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> >> 
> >> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> >> except core with omap3. And the SOC is independent of the core selected,
> >> there is no dependency between SoC and the core.
> >> 
> >> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> >> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> >> compile with different flags either.
> >>  
> >
> > What about cpu_is_omap34xx() true for am33xx? Should we follow it?
> 
> Please, no.
> 
> I've already demonstrated that that is not necessary and only leads to
> confusion and maintenance headaches.
> 

That's what I was expecting...

Probably last question where I have confusion,

Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we need to follow for AM33XX?
I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose 
here?

Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
OR
Should we create ARCH_AMXXXX, assuming that all AM devices have similar 
memory map layout, interrupt mapping, etc...
OR
Should I just add SOC_OMAPAM33XX, wherever required?


Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option, which is required for AM33XX, how should we handle this?

For example,

"arch/arm/plat-omap/include/plat/clock.h"
struct dpll_data {
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
	<dpll related variables>
#endif
};

"arch/arm/mach-omap2/clock.c"

#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)

const struct clkops clkops_omap3_noncore_dpll_ops = {
};
const struct clkops clkops_omap3_core_dpll_ops = {
}

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Fri, May 04, 2012 at 01:07:32, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120503 09:45]:
> > 
> > What about cpu_is_omap34xx() true for am33xx? Should we follow it?
> 
> Well are there components that could be used as is with that?
> If not, then it probably does not make sense.
> 

I am also in favor of not following cpu_is_omap34xx() for am33xx, but what about ARCH_OMAP?
I don't see that you are in agreement in creating ARCH_OMAPAM33XX. 
Does it make sense to say that, for am33xx, cpu_is_omap34xx() is false, but still it is under ARCH_OMAP3?


> BTW, you should post your patches on top of the clean-up patches
> Santosh posted as that already leaves out some cpu_is_omapxxxx
> checks. That's the "ARM: OMAP2+: Misc cleanup" thread.
> 

Ok. I will do that.

Thanks,
Vaibhav

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> Hi,
> 
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > > Hi
> > > 
> > > On Fri, 2 Dec 2011, hvaibhav@ti.com wrote:
> > > 
> > > > From: Afzal Mohammed <afzal@ti.com>
> > > > 
> > > > This patch adds minimal support for AM335X EVM.
> > > > The approach taken here is to add AM335X EVM support
> > > > to AM3517EVM, considering the fact that with device tree
> > > > developement we will get rid of board-*.c.
> > > > 
> > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> > > 
> > > I realize people may not necessarily like this, but I think that the 
> > > AM33xx EVM needs its own board file.  This is because it really has 
> > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> 
> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> except core with omap3. And the SOC is independent of the core selected,
> there is no dependency between SoC and the core.
> 
> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> compile with different flags either.
>  

But still we do have ARCH_OMAP2, ARCH_OMAP3 and ARCH_OMAP4? And that's where, 
we have issues for adding new devices like AM33xx and TI81xx.

Thanks,
Vaibhav

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav@ti.com> [120503 23:31]:
> On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> > Hi,
> > 
> > * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> > > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > > > Hi
> > > > 
> > > > On Fri, 2 Dec 2011, hvaibhav@ti.com wrote:
> > > > 
> > > > > From: Afzal Mohammed <afzal@ti.com>
> > > > > 
> > > > > This patch adds minimal support for AM335X EVM.
> > > > > The approach taken here is to add AM335X EVM support
> > > > > to AM3517EVM, considering the fact that with device tree
> > > > > developement we will get rid of board-*.c.
> > > > > 
> > > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> > > > 
> > > > I realize people may not necessarily like this, but I think that the 
> > > > AM33xx EVM needs its own board file.  This is because it really has 
> > > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> > > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> > > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> > 
> > I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> > except core with omap3. And the SOC is independent of the core selected,
> > there is no dependency between SoC and the core.
> > 
> > Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> > CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> > compile with different flags either.
> >  
> 
> But still we do have ARCH_OMAP2, ARCH_OMAP3 and ARCH_OMAP4? And that's where, 
> we have issues for adding new devices like AM33xx and TI81xx.

Those will be going away, but doing it has not been done because of the amount
of churn it creates. But if we add #define CONFIG_ARCH_OMAP3 CONFIG_SOC_OMAP3
we can do it piecemeal along with other cleanups.

Tony

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav@ti.com> [120503 23:04]:
> 
> Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we need to follow for AM33XX?
> I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose 
> here?

I think you're getting confused now :) I'm against ARCH_XXX but I'm OK with
adding SOC_XXX.

We should only need ARCH_OMAP2PLUS + SOC_XXX, there should not be any need
to add new ARCH_XXX under mach-omap2. Whatever we have left for ARCH_OMAP
in mach-omap2 will be eventually converted to SOC_OMAP.
 
> Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
> OR

No

> Should we create ARCH_AMXXXX, assuming that all AM devices have similar 

No

> memory map layout, interrupt mapping, etc...
> OR
> Should I just add SOC_OMAPAM33XX, wherever required?

Yes, but how about just use SOC_AM33XX? 
 
> Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option, which is required for AM33XX, how should we handle this?
> 
> For example,
> 
> "arch/arm/plat-omap/include/plat/clock.h"
> struct dpll_data {
> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> 	<dpll related variables>
> #endif
> };
> 
> "arch/arm/mach-omap2/clock.c"
> 
> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> 
> const struct clkops clkops_omap3_noncore_dpll_ops = {
> };
> const struct clkops clkops_omap3_core_dpll_ops = {
> }

I suggest doing some clean-up patches before adding SOC_AM33XX where
you just convert those to be

#if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)

or something similar depending if they already are inside mach-omap2
directory. This will make them future proof for adding new SoCs
without having to patch all over the place.

Regards,

Tony

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120503 23:04]:
> > 
> > Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we need to follow for AM33XX?
> > I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose 
> > here?
> 
> I think you're getting confused now :) I'm against ARCH_XXX but I'm OK with
> adding SOC_XXX.
> 
> We should only need ARCH_OMAP2PLUS + SOC_XXX, there should not be any need
> to add new ARCH_XXX under mach-omap2. Whatever we have left for ARCH_OMAP
> in mach-omap2 will be eventually converted to SOC_OMAP.
>  
> > Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
> > OR
> 
> No
> 
> > Should we create ARCH_AMXXXX, assuming that all AM devices have similar 
> 
> No
> 
> > memory map layout, interrupt mapping, etc...
> > OR
> > Should I just add SOC_OMAPAM33XX, wherever required?
> 
> Yes, but how about just use SOC_AM33XX? 
>  

I will submit patches shortly (in the last cleanup now), where for am33xx

 - cpu_is_omap34xx() will be false.

 - Only cpu_is_am33xx() will be true here.

 - Neither be under ARCH_OMAP3 nor ARCH_OMAP4, instead will be an 
   independent device under SOC_OMAPAM33XX.

This brings-in, some cleanup in existing code, which I will also submit 
shortly.


> > Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option, which is required for AM33XX, how should we handle this?
> > 
> > For example,
> > 
> > "arch/arm/plat-omap/include/plat/clock.h"
> > struct dpll_data {
> > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> > 	<dpll related variables>
> > #endif
> > };
> > 
> > "arch/arm/mach-omap2/clock.c"
> > 
> > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> > 
> > const struct clkops clkops_omap3_noncore_dpll_ops = {
> > };
> > const struct clkops clkops_omap3_core_dpll_ops = {
> > }
> 
> I suggest doing some clean-up patches before adding SOC_AM33XX where
> you just convert those to be
> 
> #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> 
> or something similar depending if they already are inside mach-omap2
> directory. This will make them future proof for adding new SoCs
> without having to patch all over the place.
> 

Tony,

Cool, I also thought exactly same solution on this, but next thought came to 
my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2 
option. However, it will be a good temporary solution for our problem, lets 
review them first (I will submit shortly).

Thanks,
Vaibhav

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav@ti.com> [120507 07:41]:
> On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> > 
> > I suggest doing some clean-up patches before adding SOC_AM33XX where
> > you just convert those to be
> > 
> > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> > 
> > or something similar depending if they already are inside mach-omap2
> > directory. This will make them future proof for adding new SoCs
> > without having to patch all over the place.

BTW, just noticied that the above won't work the right way in the
multi-omap case when all of them are compiled in..

> Cool, I also thought exactly same solution on this, but next thought came to 
> my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2 
> option. However, it will be a good temporary solution for our problem, lets 
> review them first (I will submit shortly).

..so probably the best way to deal with that is with the additional
CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted
at:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html

Can you please take a look and see how that works for am33xx?

Regards,

Tony

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Mon, May 07, 2012 at 23:02:29, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120507 07:41]:
> > On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> > > 
> > > I suggest doing some clean-up patches before adding SOC_AM33XX where
> > > you just convert those to be
> > > 
> > > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> > > 
> > > or something similar depending if they already are inside mach-omap2
> > > directory. This will make them future proof for adding new SoCs
> > > without having to patch all over the place.
> 
> BTW, just noticied that the above won't work the right way in the
> multi-omap case when all of them are compiled in..
> 
> > Cool, I also thought exactly same solution on this, but next thought came to 
> > my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2 
> > option. However, it will be a good temporary solution for our problem, lets 
> > review them first (I will submit shortly).
> 
> ..so probably the best way to deal with that is with the additional
> CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted
> at:
> 
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html
> 
> Can you please take a look and see how that works for am33xx?
> 

I still don't understand, how this will help am33xx, and for that matter any 
new future devices based on cortex-a8 or a9 core, but not omap exactly 
families? 
As I said earlier, am33xx doesn't fall under either omap3 or omap4; we have 
again same question in front of us, which to follow, either omap3 or omap4??

What is the thought process of creating these config options? Isn't it same 
as just replacing ARCH_OMAP3/4 with SOC_OMAP3PLUS and SOC_OMAP4PLUS? What is 
the criteria for the device to get into this umbrella?

Thanks,
Vaibhav

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav@ti.com> [120507 11:59]:
> On Mon, May 07, 2012 at 23:02:29, Tony Lindgren wrote:
> > * Hiremath, Vaibhav <hvaibhav@ti.com> [120507 07:41]:
> > > On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> > > > 
> > > > I suggest doing some clean-up patches before adding SOC_AM33XX where
> > > > you just convert those to be
> > > > 
> > > > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> > > > 
> > > > or something similar depending if they already are inside mach-omap2
> > > > directory. This will make them future proof for adding new SoCs
> > > > without having to patch all over the place.
> > 
> > BTW, just noticied that the above won't work the right way in the
> > multi-omap case when all of them are compiled in..
> > 
> > > Cool, I also thought exactly same solution on this, but next thought came to 
> > > my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2 
> > > option. However, it will be a good temporary solution for our problem, lets 
> > > review them first (I will submit shortly).
> > 
> > ..so probably the best way to deal with that is with the additional
> > CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted
> > at:
> > 
> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html
> > 
> > Can you please take a look and see how that works for am33xx?
> > 
> 
> I still don't understand, how this will help am33xx, and for that matter any 
> new future devices based on cortex-a8 or a9 core, but not omap exactly 
> families? 
> As I said earlier, am33xx doesn't fall under either omap3 or omap4; we have 
> again same question in front of us, which to follow, either omap3 or omap4??
> 
> What is the thought process of creating these config options? Isn't it same 
> as just replacing ARCH_OMAP3/4 with SOC_OMAP3PLUS and SOC_OMAP4PLUS? What is 
> the criteria for the device to get into this umbrella?

Just to recap: As we've discussed elsewhere, these new options need to be finer
grained SOC_HAS_OMAPXYZ_ABC type options like you've already posted.

Tony

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Wed, May 09, 2012 at 00:36:51, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120507 11:59]:
> > On Mon, May 07, 2012 at 23:02:29, Tony Lindgren wrote:
> > > * Hiremath, Vaibhav <hvaibhav@ti.com> [120507 07:41]:
> > > > On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> > > > > 
> > > > > I suggest doing some clean-up patches before adding SOC_AM33XX where
> > > > > you just convert those to be
> > > > > 
> > > > > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> > > > > 
> > > > > or something similar depending if they already are inside mach-omap2
> > > > > directory. This will make them future proof for adding new SoCs
> > > > > without having to patch all over the place.
> > > 
> > > BTW, just noticied that the above won't work the right way in the
> > > multi-omap case when all of them are compiled in..
> > > 
> > > > Cool, I also thought exactly same solution on this, but next thought came to 
> > > > my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2 
> > > > option. However, it will be a good temporary solution for our problem, lets 
> > > > review them first (I will submit shortly).
> > > 
> > > ..so probably the best way to deal with that is with the additional
> > > CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted
> > > at:
> > > 
> > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html
> > > 
> > > Can you please take a look and see how that works for am33xx?
> > > 
> > 
> > I still don't understand, how this will help am33xx, and for that matter any 
> > new future devices based on cortex-a8 or a9 core, but not omap exactly 
> > families? 
> > As I said earlier, am33xx doesn't fall under either omap3 or omap4; we have 
> > again same question in front of us, which to follow, either omap3 or omap4??
> > 
> > What is the thought process of creating these config options? Isn't it same 
> > as just replacing ARCH_OMAP3/4 with SOC_OMAP3PLUS and SOC_OMAP4PLUS? What is 
> > the criteria for the device to get into this umbrella?
> 
> Just to recap: As we've discussed elsewhere, these new options need to be finer
> grained SOC_HAS_OMAPXYZ_ABC type options like you've already posted.
> 

Absolutely... I will be submitting machine and low-level early printk patch
Based on this only.

Thanks,
Vaibhav