| Message ID | 20090422190456.GW25864@atomide.com (mailing list archive) |
|---|---|
| State | Awaiting Upstream, archived |
| Headers | show |
> > > 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. > > 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.-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > 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. > Yes it is initialised from common hw init. Regards Santosh-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From 60e0a0d9c74e2aaf4adcd1ab9f045fd8e62a3092 Mon Sep 17 00:00:00 2001 From: Tony Lindgren <tony@atomide.com> Date: Wed, 22 Apr 2009 11:59:58 -0700 Subject: [PATCH] ARM: OMAP2/3: Reorganize Makefile to add omap4 support We don't necessarily want to compile in irq.o and sdrc.o for omap4. Also, clock and prcm may not be implemented initially. Signed-off-by: Tony Lindgren <tony@atomide.com> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index c49d9bf..bf3827a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -3,9 +3,14 @@ # # Common support -obj-y := irq.o id.o io.o sdrc.o control.o prcm.o clock.o mux.o \ - devices.o serial.o gpmc.o timer-gp.o powerdomain.o \ - clockdomain.o +obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o + +omap-2-3-common = irq.o sdrc.o +prcm-common = prcm.o powerdomain.o +clock-common = clock.o clockdomain.o + +obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common) +obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o