When building for multi-omap, and OMAP4 is enabled, CONFIG_ARCH_OMAP4 will be true and prevent included code from building/running for OMAP2/3 as well.
This problem exists in io.c where some hwmod/PM/SDRC init code is prevented from running even on OMAP2/3 when OMAP4 is included in a multi-OMAP build. A quick glance suggests that this #ifndef is no longer needed. The called functions should work fine or fail gracefully in the OMAP4 case. Signed-off-by: Kevin Hilman <khil...@deeprootsystems.com> --- Needs testing on OMAP4 since still no OMAP4 here arch/arm/mach-omap2/io.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 81312b4..5d06b2a 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -339,11 +339,10 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0, pr_err("Could not init clock framework - unknown CPU\n"); omap_serial_early_init(); -#ifndef CONFIG_ARCH_OMAP4 omap_hwmod_late_init(); omap_pm_if_init(); omap2_sdrc_init(sdrc_cs0, sdrc_cs1); _omap2_init_reprogram_sdrc(); -#endif + gpmc_init(); } -- 1.7.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html