On Fri, May 04, 2012 at 02:47:34, Hilman, Kevin wrote: > "Hiremath, Vaibhav" <hvaibhav@xxxxxx> writes: > > > On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote: > >> Hi, > >> > >> * Hiremath, Vaibhav <hvaibhav@xxxxxx> [120502 02:37]: > >> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote: > >> > > Hi > >> > > > >> > > On Fri, 2 Dec 2011, hvaibhav@xxxxxx wrote: > >> > > > >> > > > From: Afzal Mohammed <afzal@xxxxxx> > >> > > > > >> > > > 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@xxxxxx> > >> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@xxxxxx> > >> > > > Reviewed-by: Kevin Hilman <khilman@xxxxxx> > >> > > > >> > > 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 = { } -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html