* Shilimkar, Santosh <santosh.shilimkar@xxxxxx> [090422 22:07]: > > > > This ifeq else we don't want to do as it breaks things > > for multi-omap. > > > > > > How do we handle this. For OMAP4, those files are not > > common and needed at this point of time. More so if we agree > > that OMAP4 won't support multi-omap, then this should be ok. > > > > No way we're dropping multi-omap for a few ifdefs. > > > > We need to have code where we can compile in all the selected things. > > In this case we should be able to select any combination of > > CONFIG_ARCH_OMAP2, > > CONFIG_ARCH_OMAP3, CONFIG_ARCH_OMAP4. And the code already > > gets optimized if > > only one is selected. > > > > The recent omap2 clock breakage with trivial clock patches is > > already a > > good enough reason to support the multi-omap. So basically > > all the developers > > should do their builds with the multi-omap selected. > > > > Also the distros want multi-omap. Only the product specific kernels > > should be built with only one option selected to optimize for > > speed and size. > I think most of the things are in place for multi-omap for OMAP4 as well if all the comments are taken care. Yeah cool. Looks like the gic interrupt code can also be initialized from the init_common_hw or so. Of course the entry-macro.S still needs a separate non-optimized handler for things to boot, I'll update an earlier patch for that at some point. > > > Some thing like this can be done but then Makefile will be > > completely rewamped. > > > > > > # Common support > > > obj-y := id.o io.o control.o mux.o devices.o serial.o > > gpmc.o timer-gp.o > > > > > > obj-$(CONFIG_ARCH_OMAP2) += display.o sdrc.o prcm.o clock.o > > powerdomain.o clockdomain.o > > > obj-$(CONFIG_ARCH_OMAP3) += display.o sdrc.o prcm.o clock.o > > powerdomain.o clockdomain.o > > > > > > Is this OK ? > > > > How about the attached patch? > Looks good. After adding clock support stubs we need to compile almost all files except 'clock.c' so we may not need this completely. But any case, the patch looks cleaner. OK 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
