* Shilimkar, Santosh <[email protected]> [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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
