OpenCloudOS-Kernel/arch/arm/mach-omap2/Makefile

210 lines
6.4 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 pm.o \
OMAP: GPIO: Implement GPIO as a platform device Implement GPIO as a platform device. GPIO APIs are used in machine_init functions. Hence it is required to complete GPIO probe before board_init. Therefore GPIO device register and driver register are implemented as postcore_initcalls. omap_gpio_init() does nothing now and this function would be removed in the next patch as it's usage is spread across most of the board files. Inorder to convert GPIO as platform device, modifications are required in clockxxxx_data.c file for OMAP1 so that device names can be used to obtain clock instead of getting clocks by name/NULL ptr. Use runtime pm APIs (pm_runtime_put*/pm_runtime_get*) for enabling or disabling the clocks, modify sysconfig settings and remove usage of clock FW APIs. Note 1: Converting GPIO driver to use runtime PM APIs is not done as a separate patch because GPIO clock names are different for various OMAPs and are different for some of the banks in the same CPU. This would need usage of cpu_is checks and bank id checks while using clock FW APIs in the gpio driver. Hence while making GPIO a platform driver framework, PM runtime APIs are used directly. Note 2: While implementing GPIO as a platform device, pm runtime APIs are used as mentioned above and modification is not done in gpio's prepare for idle/ resume after idle functions. This would be done in the next patch series and GPIO driver would be made to use dev_pm_ops instead of sysdev_class in that series only. Due to the above, the GPIO driver implicitly relies on CM_AUTOIDLE = 1 on its iclk for power management to work, since the driver never disables its iclk. This would be taken care in the next patch series (see Note 3 below). Refer to http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39112.html for more details. Note 3: only pm_runtime_get_sync is called in gpio's probe() and pm_runtime_put* is never called. This is to make the implementation similar to the existing GPIO code. Another patch series would be sent to correct this. In OMAP3 and OMAP4 gpio's debounce clocks are optional clocks. They are enabled/ disabled whenever required using clock framework APIs TODO: 1. Cleanup the GPIO driver. Use function pointers and register offest pointers instead of using hardcoded values 2. Remove all cpu_is_ checks and OMAP specific macros 3. Remove usage of gpio_bank array so that only instance specific information is used in driver code 4. Rename 'method'/ avoid it's usage 5. Fix the non-wakeup gpios handling for OMAP2430, OMAP3 & OMAP4 6. Modify gpio's prepare for idle/ resume after idle functions to use runtime pm implentation. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Basak, Partha <p-basak2@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> [tony@atomide.com: updated for bank specific revision and updated boards] Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-08 08:26:57 +08:00
common.o gpio.o
omap-2-3-common = irq.o sdrc.o prm2xxx_3xxx.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
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) prm44xx.o $(hwmod-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_HOTPLUG_CPU) += omap-hotplug.o
obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a$(plus_sec)
# 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_OMAP2420) += mux2420.o
obj-$(CONFIG_ARCH_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
endif
# Power Management
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o pm_bus.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
ifeq ($(CONFIG_PM_VERBOSE),y)
CFLAGS_pm_bus.o += -DDEBUG
endif
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 13:09:22 +08: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 13:09:22 +08: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
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_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
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
obj-y += $(i2c-omap-m) $(i2c-omap-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 \
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 \
board-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO) += board-omap3logic.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-flash.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
sdram-nokia.o \
hsmmc.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
sdram-nokia.o \
board-rx51-peripherals.o \
board-rx51-video.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o \
board-zoom-peripherals.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o \
board-zoom-peripherals.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \
board-zoom-peripherals.o \
board-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T3517) += board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \
hsmmc.o
obj-$(CONFIG_MACH_IGEP0030) += board-igep0030.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
hsmmc.o
# Platform specific device init code
usbfs-$(CONFIG_ARCH_OMAP_OTG) := usb-fs.o
obj-y += $(usbfs-m) $(usbfs-y)
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)
smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)