OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files
authorPaul Walmsley <paul@pwsan.com>
Tue, 23 Feb 2010 05:09:22 +0000 (22:09 -0700)
committerPaul Walmsley <paul@pwsan.com>
Wed, 24 Feb 2010 19:29:42 +0000 (12:29 -0700)
commit81b34fbecbfbf24ed95c2d80d5cb14149652408f
treeb29a0d117a7dda644e6d37931a7999095aeeaf69
parent657ebfadc19c5a14f709dee1645082828330d5d4
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>
arch/arm/mach-omap2/Makefile
arch/arm/mach-omap2/clkt2xxx_apll.c
arch/arm/mach-omap2/clock2420_data.c [copied from arch/arm/mach-omap2/clock2xxx_data.c with 75% similarity]
arch/arm/mach-omap2/clock2430.c [new file with mode: 0644]
arch/arm/mach-omap2/clock2430_data.c [moved from arch/arm/mach-omap2/clock2xxx_data.c with 79% similarity]
arch/arm/mach-omap2/clock2xxx.c
arch/arm/mach-omap2/clock2xxx.h
arch/arm/mach-omap2/io.c