2005-11-10 07:26:51 -07:00
|
|
|
#
|
|
|
|
# Makefile for the linux kernel.
|
|
|
|
#
|
|
|
|
|
|
|
|
# Common support
|
2010-10-08 10:40:19 -07:00
|
|
|
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \
|
2010-12-21 19:56:17 -07:00
|
|
|
common.o gpio.o dma.o wd_timer.o
|
2009-05-25 11:26:47 -07:00
|
|
|
|
2010-12-21 15:30:55 -07:00
|
|
|
omap-2-3-common = irq.o sdrc.o
|
2010-02-22 22:09:34 -07:00
|
|
|
hwmod-common = omap_hwmod.o \
|
2010-02-24 12:05:58 -07:00
|
|
|
omap_hwmod_common_data.o
|
2010-01-26 20:13:03 -07:00
|
|
|
clock-common = clock.o clock_common_data.o \
|
2010-12-21 20:01:20 -07:00
|
|
|
clkt_dpll.o clkt_clksel.o
|
OMAP3/4 clock: split into per-chip family files
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
superset.
The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family. To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.
OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
clkops structure. The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it. (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2010-02-22 22:09:20 -07:00
|
|
|
|
2010-12-21 20:01:17 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common)
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common)
|
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
|
2005-11-10 07:26:51 -07:00
|
|
|
|
2008-07-03 02:24:40 -07:00
|
|
|
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
|
|
|
|
|
2009-04-28 08:22:05 -07:00
|
|
|
# SMP support ONLY available for OMAP4
|
|
|
|
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
|
|
|
|
obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
|
2010-08-02 03:18:19 -07:00
|
|
|
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
|
2010-05-14 12:05:26 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o
|
2010-03-11 00:33:46 -07:00
|
|
|
|
2010-11-30 22:57:51 -07:00
|
|
|
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)
|
2009-04-28 08:22:05 -07:00
|
|
|
|
2008-07-03 02:24:38 -07:00
|
|
|
# Functions loaded to SRAM
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2420) += sram242x.o
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2430) += sram243x.o
|
2008-10-09 07:51:41 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += sram34xx.o
|
2008-07-03 02:24:38 -07:00
|
|
|
|
2010-02-12 13:26:46 -07:00
|
|
|
AFLAGS_sram242x.o :=-Wa,-march=armv6
|
|
|
|
AFLAGS_sram243x.o :=-Wa,-march=armv6
|
|
|
|
AFLAGS_sram34xx.o :=-Wa,-march=armv7-a
|
|
|
|
|
2009-12-11 17:16:32 -07:00
|
|
|
# Pin multiplexing
|
2010-07-05 06:31:36 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2420) += mux2420.o
|
2010-07-05 06:31:36 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2430) += mux2430.o
|
2009-12-11 17:16:32 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += mux34xx.o
|
2010-08-10 08:27:48 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += mux44xx.o
|
2009-12-11 17:16:32 -07:00
|
|
|
|
2009-01-28 12:27:37 -07:00
|
|
|
# SMS/SDRC
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
|
|
|
|
# obj-$(CONFIG_ARCH_OMAP3) += sdrc3xxx.o
|
|
|
|
|
2010-12-09 08:13:46 -07:00
|
|
|
# OPP table initialization
|
|
|
|
ifeq ($(CONFIG_PM_OPP),y)
|
|
|
|
obj-y += opp.o
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += opp3xxx_data.o
|
2010-12-09 08:13:47 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += opp4xxx_data.o
|
2010-12-09 08:13:46 -07:00
|
|
|
endif
|
|
|
|
|
2006-04-02 09:46:27 -07:00
|
|
|
# Power Management
|
2008-10-06 05:49:15 -07:00
|
|
|
ifeq ($(CONFIG_PM),y)
|
2009-05-28 10:56:16 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
|
2009-11-05 20:06:01 -07:00
|
|
|
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
|
2009-05-28 10:56:16 -07:00
|
|
|
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
|
2010-02-12 13:26:46 -07:00
|
|
|
|
|
|
|
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
|
|
|
|
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
|
|
|
|
|
2009-11-05 20:06:01 -07:00
|
|
|
ifeq ($(CONFIG_PM_VERBOSE),y)
|
|
|
|
CFLAGS_pm_bus.o += -DDEBUG
|
|
|
|
endif
|
|
|
|
|
2008-10-06 05:49:15 -07:00
|
|
|
endif
|
2006-04-02 09:46:27 -07:00
|
|
|
|
2009-09-03 10:14:02 -07:00
|
|
|
# PRCM
|
2010-12-21 15:30:55 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
|
|
|
|
# XXX The presence of cm2xxx_3xxx.o on the line below is temporary and
|
|
|
|
# will be removed once the OMAP4 part of the codebase is converted to
|
|
|
|
# use OMAP4-specific PRCM functions.
|
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-21 21:05:14 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
|
|
|
|
cm44xx.o prcm_mpu44xx.o \
|
|
|
|
prminst44xx.o
|
2010-12-21 20:01:17 -07:00
|
|
|
|
|
|
|
# OMAP powerdomain framework
|
2010-12-21 20:01:20 -07:00
|
|
|
powerdomain-common += powerdomain.o powerdomain-common.o
|
2010-12-21 20:01:18 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common) \
|
2010-12-21 20:01:20 -07:00
|
|
|
powerdomain2xxx_3xxx.o \
|
|
|
|
powerdomains2xxx_data.o \
|
|
|
|
powerdomains2xxx_3xxx_data.o
|
2010-12-21 20:01:18 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common) \
|
2010-12-21 20:01:20 -07:00
|
|
|
powerdomain2xxx_3xxx.o \
|
|
|
|
powerdomains3xxx_data.o \
|
|
|
|
powerdomains2xxx_3xxx_data.o
|
2010-12-21 20:01:18 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \
|
2010-12-21 20:01:20 -07:00
|
|
|
powerdomain44xx.o \
|
|
|
|
powerdomains44xx_data.o
|
2009-09-03 10:14:02 -07:00
|
|
|
|
2010-12-21 20:01:20 -07:00
|
|
|
# PRCM clockdomain control
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += clockdomain.o \
|
|
|
|
clockdomains2xxx_3xxx_data.o
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += clockdomain.o \
|
|
|
|
clockdomains2xxx_3xxx_data.o
|
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o \
|
|
|
|
clockdomains44xx_data.o
|
2008-03-18 05:41:40 -07:00
|
|
|
# Clock framework
|
OMAP3/4 clock: split into per-chip family files
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
superset.
The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family. To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.
OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
clkops structure. The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it. (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2010-02-22 22:09:20 -07:00
|
|
|
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-22 22:09:22 -07:00
|
|
|
clkt2xxx_sys.o \
|
OMAP3/4 clock: split into per-chip family files
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
superset.
The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family. To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.
OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
clkops structure. The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it. (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2010-02-22 22:09:20 -07:00
|
|
|
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-22 22:09:22 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2420) += clock2420_data.o
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2430) += clock2430.o clock2430_data.o
|
OMAP3/4 clock: split into per-chip family files
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
superset.
The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family. To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.
OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
clkops structure. The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it. (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2010-02-22 22:09:20 -07:00
|
|
|
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)
|
2009-12-08 16:21:29 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2420) += opp2420_data.o
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2430) += opp2430_data.o
|
2008-03-18 05:41:40 -07:00
|
|
|
|
2010-02-22 22:09:32 -07:00
|
|
|
# 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
|
2010-05-12 08:54:36 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
|
2008-03-18 05:41:40 -07:00
|
|
|
|
2009-12-01 06:03:31 -07:00
|
|
|
# EMU peripherals
|
OMAP3/4 clock: split into per-chip family files
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
superset.
The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family. To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.
OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
clkops structure. The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it. (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2010-02-22 22:09:20 -07:00
|
|
|
obj-$(CONFIG_OMAP3_EMU) += emu.o
|
2009-12-01 06:03:31 -07:00
|
|
|
|
2009-11-22 11:11:17 -07:00
|
|
|
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o
|
|
|
|
mailbox_mach-objs := mailbox.o
|
|
|
|
|
2010-05-23 23:35:11 -07:00
|
|
|
obj-$(CONFIG_OMAP_IOMMU) += iommu2.o
|
|
|
|
|
|
|
|
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
|
|
|
|
obj-y += $(iommu-m) $(iommu-y)
|
2009-01-28 12:32:09 -07:00
|
|
|
|
2009-12-11 17:16:32 -07:00
|
|
|
i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
|
|
|
|
obj-y += $(i2c-omap-m) $(i2c-omap-y)
|
|
|
|
|
2010-10-04 09:09:14 -07:00
|
|
|
ifneq ($(CONFIG_TIDSPBRIDGE),)
|
|
|
|
obj-y += dsp.o
|
|
|
|
endif
|
|
|
|
|
2005-11-10 07:26:51 -07:00
|
|
|
# Specific board support
|
|
|
|
obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o
|
|
|
|
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
|
2008-12-10 18:37:17 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2006-04-02 09:46:27 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o
|
2008-12-10 18:37:17 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
Add minimal support for DevKit8000
These patches add board support for the Timll DevKit8000.
The DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.
Signed-off-by: Thomas Weber <weber@corscience.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-02-17 15:09:28 -07:00
|
|
|
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
|
|
|
|
hsmmc.o
|
2008-12-10 18:37:17 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \
|
2010-07-09 07:27:51 -07:00
|
|
|
board-flash.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2010-09-27 09:05:47 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \
|
|
|
|
hsmmc.o
|
|
|
|
obj-$(CONFIG_MACH_OMAP3_TORPEDO) += board-omap3logic.o \
|
|
|
|
hsmmc.o
|
2008-12-10 18:37:17 -07:00
|
|
|
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2009-05-28 14:13:28 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2008-12-10 18:37:17 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2009-03-23 18:38:16 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o \
|
2010-07-09 07:27:47 -07:00
|
|
|
board-flash.o
|
2009-08-28 10:51:38 -07:00
|
|
|
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
|
2010-12-17 16:13:47 -07:00
|
|
|
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
|
|
|
|
sdram-nokia.o \
|
|
|
|
hsmmc.o
|
2009-03-23 18:38:17 -07:00
|
|
|
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
|
2010-12-17 16:13:44 -07:00
|
|
|
sdram-nokia.o \
|
2009-03-23 18:38:17 -07:00
|
|
|
board-rx51-peripherals.o \
|
2010-05-10 01:35:17 -07:00
|
|
|
board-rx51-video.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2010-11-07 23:56:14 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o \
|
2009-11-22 11:11:30 -07:00
|
|
|
board-zoom-peripherals.o \
|
2010-07-09 07:27:48 -07:00
|
|
|
board-flash.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o \
|
2009-05-28 14:04:04 -07:00
|
|
|
board-zoom-debugboard.o
|
2010-11-07 23:56:14 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o \
|
2009-11-22 11:11:32 -07:00
|
|
|
board-zoom-peripherals.o \
|
2010-07-09 07:27:49 -07:00
|
|
|
board-flash.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o \
|
2009-05-28 14:04:04 -07:00
|
|
|
board-zoom-debugboard.o
|
2009-11-18 19:41:08 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \
|
|
|
|
board-zoom-peripherals.o \
|
2010-07-09 07:27:50 -07:00
|
|
|
board-flash.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2009-11-18 19:41:07 -07:00
|
|
|
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2010-09-21 09:03:09 -07:00
|
|
|
obj-$(CONFIG_MACH_CM_T3517) += board-cm-t3517.o
|
2009-11-18 19:41:07 -07:00
|
|
|
obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2010-10-08 10:22:11 -07:00
|
|
|
obj-$(CONFIG_MACH_IGEP0030) += board-igep0030.o \
|
|
|
|
hsmmc.o
|
2009-12-11 17:16:34 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
|
2010-02-15 11:03:34 -07:00
|
|
|
hsmmc.o
|
2010-05-15 11:21:06 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o \
|
|
|
|
hsmmc.o
|
2010-08-02 03:18:05 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o \
|
|
|
|
hsmmc.o
|
2009-03-30 14:58:31 -07:00
|
|
|
|
OMAP3/4 clock: split into per-chip family files
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
superset.
The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family. To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.
OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
clkops structure. The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it. (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2010-02-22 22:09:20 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
|
2009-11-18 19:41:09 -07:00
|
|
|
|
2010-11-16 15:26:58 -07:00
|
|
|
obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
|
|
|
|
|
2010-05-16 23:39:09 -07:00
|
|
|
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
|
|
|
|
hsmmc.o
|
2009-03-23 18:34:06 -07:00
|
|
|
# Platform specific device init code
|
2010-07-05 06:31:29 -07:00
|
|
|
usbfs-$(CONFIG_ARCH_OMAP_OTG) := usb-fs.o
|
|
|
|
obj-y += $(usbfs-m) $(usbfs-y)
|
2009-03-23 18:34:06 -07:00
|
|
|
obj-y += usb-musb.o
|
2009-08-28 10:51:37 -07:00
|
|
|
obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o
|
2009-11-22 11:11:01 -07:00
|
|
|
obj-y += usb-ehci.o
|
2009-05-28 13:23:52 -07:00
|
|
|
|
|
|
|
onenand-$(CONFIG_MTD_ONENAND_OMAP2) := gpmc-onenand.o
|
|
|
|
obj-y += $(onenand-m) $(onenand-y)
|
2009-05-28 13:23:52 -07:00
|
|
|
|
2010-02-15 11:03:33 -07:00
|
|
|
nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
|
|
|
|
obj-y += $(nand-m) $(nand-y)
|
|
|
|
|
2009-05-28 13:23:52 -07:00
|
|
|
smc91x-$(CONFIG_SMC91X) := gpmc-smc91x.o
|
|
|
|
obj-y += $(smc91x-m) $(smc91x-y)
|
2010-09-27 09:05:49 -07:00
|
|
|
|
|
|
|
smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o
|
|
|
|
obj-y += $(smsc911x-m) $(smsc911x-y)
|