linux-sg2042/arch/arm/mach-omap2/Makefile

274 lines
9.0 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.o pm.o \
common.o gpio.o dma.o wd_timer.o display.o i2c.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-25 03:05:58 +08:00
omap_hwmod_common_data.o
clock-common = clock.o clock_common_data.o \
clkt_dpll.o clkt_clksel.o
secure-common = omap-smc.o omap-secure.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common)
obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
obj-y += mcbsp.o
endif
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \
sleep44xx.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec)
AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
obj-$(CONFIG_SOC_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_SOC_OMAP2420) += mux2420.o
obj-$(CONFIG_SOC_OMAP2430) += mux2430.o
obj-$(CONFIG_ARCH_OMAP3) += mux34xx.o
obj-$(CONFIG_ARCH_OMAP4) += mux44xx.o
# SMS/SDRC
obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
# obj-$(CONFIG_ARCH_OMAP3) += sdrc3xxx.o
# OPP table initialization
ifeq ($(CONFIG_PM_OPP),y)
obj-y += opp.o
obj-$(CONFIG_ARCH_OMAP3) += opp3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += opp4xxx_data.o
endif
# Power Management
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 13:17:45 +08:00
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
cpuidle34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
cpuidle44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
ifeq ($(CONFIG_PM_VERBOSE),y)
CFLAGS_pm_bus.o += -DDEBUG
endif
endif
# PRCM
obj-y += prm_common.o
obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 13:17:45 +08:00
obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o \
vc3xxx_data.o vp3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o \
OMAP4: PRCM: add OMAP4-specific accessor/mutator functions In some ways, the OMAP4 PRCM register layout is quite different than the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a register layout point of view, all CM instances were located in the CM subsystem, and all PRM instances were located in the PRM subsystem. OMAP4 changes this. Now, for example, some CM instances, such as WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a "local PRCM" exists for the MPU - this PRCM combines registers that would normally appear in both CM and PRM instances, but uses its own register layout which matches neither the OMAP2/3 PRCM layout nor the OMAP4 PRCM layout. To try to deal with this, introduce some new functions, omap4_cminst* and omap4_prminst*. The former is to be used when writing to a CM instance register (no matter what subsystem or hardware module it exists in), and the latter, similarly, with PRM instance registers. To determine which "PRCM partition" to write to, the functions take a PRCM instance ID argument. Subsequent patches add these partition IDs to the OMAP4 powerdomain and clockdomain definitions. As far as I can see, there's really no good way to handle these types of register access inconsistencies. This patch seemed like the least bad approach. Moving forward, the long-term goal is to remove all direct PRCM register access from the PM code. PRCM register access should go through layers such as the powerdomain and clockdomain code that can hide the details of how to interact with the specific hardware variant. While here, rename cm4xxx.c to cm44xx.c to match the naming convention of the other OMAP4 PRCM files. Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak <rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-22 12:05:14 +08:00
cm44xx.o prcm_mpu44xx.o \
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 13:17:45 +08:00
prminst44xx.o vc44xx_data.o \
vp44xx_data.o prm44xx.o
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 13:17:45 +08:00
# OMAP voltage domains
voltagedomain-common := voltage.o vc.o vp.o
obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) \
voltagedomains2xxx_data.o
OMAP2+: voltage: reorganize, split code from data This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>
2011-03-11 13:17:45 +08:00
obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \
voltagedomains3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \
voltagedomains44xx_data.o
# OMAP powerdomain framework
powerdomain-common += powerdomain.o powerdomain-common.o
obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common) \
powerdomain2xxx_3xxx.o \
powerdomains2xxx_data.o \
powerdomains2xxx_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common) \
powerdomain2xxx_3xxx.o \
powerdomains3xxx_data.o \
powerdomains2xxx_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \
powerdomain44xx.o \
powerdomains44xx_data.o
# PRCM clockdomain control
obj-$(CONFIG_ARCH_OMAP2) += clockdomain.o \
clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_SOC_OMAP2420) += clockdomains2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += clockdomains2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += clockdomain.o \
clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o \
clockdomains3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o \
clockdomain44xx.o \
clockdomains44xx_data.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 13:09:22 +08:00
clkt2xxx_sys.o \
clkt2xxx_dpllcore.o \
clkt2xxx_virt_prcm_set.o \
clkt2xxx_apll.o clkt2xxx_osc.o \
clkt2xxx_dpll.o clkt_iclk.o
obj-$(CONFIG_SOC_OMAP2420) += clock2420_data.o
obj-$(CONFIG_SOC_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 \
clkt_iclk.o
obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o \
dpll3xxx.o dpll44xx.o
# OMAP2 clock rate set data (old "OPP" data)
obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += opp2430_data.o
# hwmod data
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_ipblock_data.o \
omap_hwmod_2xxx_3xxx_ipblock_data.o \
omap_hwmod_2xxx_interconnect_data.o \
omap_hwmod_2xxx_3xxx_interconnect_data.o \
omap_hwmod_2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2xxx_ipblock_data.o \
omap_hwmod_2xxx_3xxx_ipblock_data.o \
omap_hwmod_2xxx_interconnect_data.o \
omap_hwmod_2xxx_3xxx_interconnect_data.o \
omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_2xxx_3xxx_ipblock_data.o \
omap_hwmod_2xxx_3xxx_interconnect_data.o \
omap_hwmod_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU) += emu.o
# L3 interconnect
obj-$(CONFIG_ARCH_OMAP3) += omap_l3_smx.o
obj-$(CONFIG_ARCH_OMAP4) += omap_l3_noc.o
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o
mailbox_mach-objs := mailbox.o
obj-$(CONFIG_OMAP_IOMMU) += iommu2.o
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
ifneq ($(CONFIG_TIDSPBRIDGE),)
obj-y += dsp.o
endif
# 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
obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o
obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o
obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO) += board-omap3logic.o
obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
sdram-nokia.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
sdram-nokia.o \
board-rx51-peripherals.o \
board-rx51-video.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o \
board-zoom-peripherals.o \
board-zoom-display.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o \
board-zoom-peripherals.o \
board-zoom-display.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \
board-zoom-peripherals.o \
board-zoom-display.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o
obj-$(CONFIG_MACH_CM_T3517) += board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o
obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o
obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o
obj-$(CONFIG_MACH_PCM049) += board-omap4pcm049.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
obj-$(CONFIG_MACH_TI8148EVM) += board-ti8168evm.o
# Platform specific device init code
omap-flash-$(CONFIG_MTD_NAND_OMAP2) := board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
obj-y += $(omap-flash-y) $(omap-flash-m)
omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o
obj-y += $(omap-hsmmc-m) $(omap-hsmmc-y)
usbfs-$(CONFIG_ARCH_OMAP_OTG) := usb-fs.o
obj-y += $(usbfs-m) $(usbfs-y)
obj-y += usb-musb.o
obj-y += omap_phy_internal.o
obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o
obj-y += usb-host.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)
smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
obj-y += hwspinlock.o
endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
obj-y += common-board-devices.o twl-common.o