* Pedanekar, Hemant <hemantp@xxxxxx> [110210 09:37]: > cvTony Lindgren wrote on Thursday, February 10, 2011 7:09 AM: > > I will take care of this using separate map_io as you mentioned on > the other mail on patch 2 comment. OK great. > Do you think the 2nd case restriction mentioned in this patch comment is OK? > > " 2) OMAP3 only build with CONFIG_SOC_OMAPTI816X: This will build TI816X > optimized kernel. May not boot on other OMAP3 SoCs." > > As I had mentioned on follow up on Paul's comment on v4, some OMAP3 specific > code may get skipped on non-multi-omap builds with CONFIG_SOC_OMAPTI816X > (cpu_is_ti816x() is true) such as: > > - if (omap_rev() >= OMAP3430_REV_ES2_0) > + if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0)) > omap3_clk_lock_dpll5(); I suggest that if CONFIG_ARCH_OMAP3 is selected, we do dynamic checks for cpu_is omap macros for 34xx/36xx/ti816x. We can use CONFIG_SOC_OMAP to optimize the size a bit if some features are not needed, like clock data etc. But in general the cpu_is checks should be only done during the init for most part, so at this point doing performance optimizations with the cpu_is macros should not really be needed. Regards, Tony -- 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
