linux/arch/arm/mach-omap2/Makefile

157 lines
4.8 KiB
Makefile
Raw Normal View History

#
# Makefile for the linux kernel.
#
# Common support
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
hwmod-common = omap_hwmod.o \
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24 19:05:58 +00:00
omap_hwmod_common_data.o
prcm-common = prcm.o powerdomain.o
clock-common = clock.o clock_common_data.o \
clockdomain.o clkt_dpll.o \
clkt_clksel.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o
AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a
# Functions loaded to SRAM
obj-$(CONFIG_ARCH_OMAP2420) += sram242x.o
obj-$(CONFIG_ARCH_OMAP2430) += sram243x.o
obj-$(CONFIG_ARCH_OMAP3) += sram34xx.o
AFLAGS_sram242x.o :=-Wa,-march=armv6
AFLAGS_sram243x.o :=-Wa,-march=armv6
AFLAGS_sram34xx.o :=-Wa,-march=armv7-a
# Pin multiplexing
obj-$(CONFIG_ARCH_OMAP3) += mux34xx.o
# SMS/SDRC
obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
# obj-$(CONFIG_ARCH_OMAP3) += sdrc3xxx.o
# Power Management
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
endif
# PRCM
obj-$(CONFIG_ARCH_OMAP2) += cm.o
obj-$(CONFIG_ARCH_OMAP3) += cm.o
obj-$(CONFIG_ARCH_OMAP4) += cm4xxx.o
# Clock framework
obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o \
OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files In preparation for multi-OMAP2 kernels, split mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and mach-omap2/clock2430_data.c. 2430 uses a different device space physical memory layout than past or future OMAPs, and we use a different virtual memory layout as well, which causes trouble for architecture-level code/data that tries to support both. We tried using offsets from the virtual base last year, but those patches never made it upstream; so after some discussion with Tony about the best all-around approach, we'll just grit our teeth and duplicate the structures. The maintenance advantages of a single kernel config that can compile and boot on OMAP2, 3, and 4 platforms are simply too compelling. This approach does have some nice benefits beyond multi-OMAP 2 kernel support. The runtime size of OMAP2420-specific and OMAP2430-specific kernels is smaller, since unused clocks for the other OMAP2 chip will no longer be compiled in. (At some point we will mark the clock data __initdata and allocate it during registration, which will eliminate the runtime memory advantage.) It also makes the clock trees slightly easier to read, since 2420-specific and 2430-specific clocks are no longer mixed together. This patch also splits 2430-specific clock code into its own file, mach-omap2/clock2430.c, which is only compiled in for 2430 builds - mostly for organizational clarity. While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was incorrectly marked as being 2420-only, when actually it is present on both OMAP2420 and OMAP2430. Thanks to Tony for some good discussions about how to approach this problem. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2010-02-23 05:09:22 +00:00
clkt2xxx_sys.o \
clkt2xxx_dpllcore.o \
clkt2xxx_virt_prcm_set.o \
clkt2xxx_apll.o clkt2xxx_osc.o
OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files In preparation for multi-OMAP2 kernels, split mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and mach-omap2/clock2430_data.c. 2430 uses a different device space physical memory layout than past or future OMAPs, and we use a different virtual memory layout as well, which causes trouble for architecture-level code/data that tries to support both. We tried using offsets from the virtual base last year, but those patches never made it upstream; so after some discussion with Tony about the best all-around approach, we'll just grit our teeth and duplicate the structures. The maintenance advantages of a single kernel config that can compile and boot on OMAP2, 3, and 4 platforms are simply too compelling. This approach does have some nice benefits beyond multi-OMAP 2 kernel support. The runtime size of OMAP2420-specific and OMAP2430-specific kernels is smaller, since unused clocks for the other OMAP2 chip will no longer be compiled in. (At some point we will mark the clock data __initdata and allocate it during registration, which will eliminate the runtime memory advantage.) It also makes the clock trees slightly easier to read, since 2420-specific and 2430-specific clocks are no longer mixed together. This patch also splits 2430-specific clock code into its own file, mach-omap2/clock2430.c, which is only compiled in for 2430 builds - mostly for organizational clarity. While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was incorrectly marked as being 2420-only, when actually it is present on both OMAP2420 and OMAP2430. Thanks to Tony for some good discussions about how to approach this problem. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2010-02-23 05:09:22 +00:00
obj-$(CONFIG_ARCH_OMAP2420) += clock2420_data.o
obj-$(CONFIG_ARCH_OMAP2430) += clock2430.o clock2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += $(clock-common) clock3xxx.o \
clock34xx.o clkt34xx_dpll3m2.o \
clock3517.o clock36xx.o \
dpll3xxx.o clock3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o \
dpll3xxx.o
# OMAP2 clock rate set data (old "OPP" data)
obj-$(CONFIG_ARCH_OMAP2420) += opp2420_data.o
obj-$(CONFIG_ARCH_OMAP2430) += opp2430_data.o
# hwmod data
obj-$(CONFIG_ARCH_OMAP2420) += omap_hwmod_2420_data.o
obj-$(CONFIG_ARCH_OMAP2430) += omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU) += emu.o
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o
mailbox_mach-objs := mailbox.o
obj-$(CONFIG_OMAP_IOMMU) := iommu2.o omap-iommu.o
i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
obj-y += $(i2c-omap-m) $(i2c-omap-y)
# Specific board support
obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \
hsmmc.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \
hsmmc.o \
board-sdp-flash.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
board-rx51-peripherals.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \
board-zoom-peripherals.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
# Platform specific device init code
obj-y += usb-musb.o
obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o
obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2) := gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
obj-y += $(nand-m) $(nand-y)
smc91x-$(CONFIG_SMC91X) := gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)