History log of /arch/arm/mach-omap2/clock2xxx.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
b481cea34bb41f3731567c8c1be0625bf80d20b7 10-Mar-2011 Felipe Balbi <balbi@ti.com> OMAP: clock: fix compile warning

if building kernels without OMAP2 support, we
will see a warning such as:

arch/arm/mach-omap2/io.c: In function 'omap2_init_common_infrastructure':
arch/arm/mach-omap2/io.c:389:3: warning: statement with no effect
arch/arm/mach-omap2/io.c:391:3: warning: statement with no effect

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/clock2xxx.h
59b479e0985f0b795d68331d6443a7f89c47768d 28-Jan-2011 Tony Lindgren <tony@atomide.com> omap: Start using CONFIG_SOC_OMAP

We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest
are nowadays just subcategories of these.

Search and replace the following:

ARCH_OMAP2420 SOC_OMAP2420
ARCH_OMAP2430 SOC_OMAP2430
ARCH_OMAP3430 SOC_OMAP3430

No functional changes.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Thomas Weber <weber@corscience.de>
Acked-by: Sourav Poddar <sourav.poddar@ti.com>
/arch/arm/mach-omap2/clock2xxx.h
81b34fbecbfbf24ed95c2d80d5cb14149652408f 23-Feb-2010 Paul Walmsley <paul@pwsan.com> 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/clock2xxx.h
e80a9729b15f4c2c00ed51d61aa543fb4269d5ca 27-Jan-2010 Paul Walmsley <paul@pwsan.com> OMAP2/3/4 clock: rename and clean the omap2_clk_init() functions

Rename the omap2_clk_init() in the OMAP2, 3, and 4 clock code to be
omap2xxx_clk_init(), omap3xxx_clk_init(), etc. Remove all traces of
the (commented) old virt_prcm_set code from omap3xxx_clk_init() and
omap4xxx_clk_init(), since this will be handled with the OPP code that
is cooking in the PM branch.

After this patch, there should be very little else in the clock code
that blocks a multi-OMAP 2+3 kernel. (OMAP2420+OMAP2430 still has some
outstanding issues that need to be resolved; this is pending on some
additions to the hwmod data.)

Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/clock2xxx.h
feec1277a5c599ebca6217bc6bb9f6410e84793b 27-Jan-2010 Paul Walmsley <paul@pwsan.com> OMAP2/3/4 clock: omap2_clk_prepare_for_reboot() is OMAP2xxx-only

omap2_clk_prepare_for_reboot() is only applicable to OMAP2xxx chips,
so rename it to omap2xxx_clk_prepare_for_reboot() and only call it when
running on OMAP2xxx chips. Remove the old stub in the OMAP3 clock code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
/arch/arm/mach-omap2/clock2xxx.h
44da0a51032f3d90a441bd80c2efe68532104980 27-Jan-2010 Paul Walmsley <paul@pwsan.com> OMAP2xxx clock: move sys_clk code into mach-omap2/clkt2xxx_sys.c

Move the sys_clk clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_sys.c. This is intended to make the clock code
easier to understand, since all of the functions needed to manage the
sys_clk are now located in their own file, rather than being mixed
with other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG
macro can now be defined for the sys_clk clock alone. This
should reduce unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split into
OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
directory, rather than shared with other chip types that don't use
this clock type.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
/arch/arm/mach-omap2/clock2xxx.h
87a1b26c2d31dce62758b78c077ff5a1b5a52ab8 27-Jan-2010 Paul Walmsley <paul@pwsan.com> OMAP2xxx clock: move osc_clk code into mach-omap2/clkt2xxx_osc.c

Move the osc_clk clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_osc. This is intended to make the clock code
easier to understand, since all of the functions needed to manage the
osc_clk are now located in their own file, rather than being mixed
with other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG
macro can now be defined for osc_clk clocks alone. This
should reduce unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split
into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
directory, rather than shared with other chip types that don't use this
clock type.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
/arch/arm/mach-omap2/clock2xxx.h
49214640f52506fbba00eb998fc39f10653a840a 27-Jan-2010 Paul Walmsley <paul@pwsan.com> OMAP2xxx clock: move the APLL clock code into mach-omap2/clkt2xxx_apll.c

Move the APLL-related clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_apll.c. This is intended to make the clock code
easier to understand, since all of the functions needed to manage APLLs
are now located in their own file, rather than being mixed with other,
unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG
macro can now be defined for APLL clocks alone. This
should reduce unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split
into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
directory, rather than shared with other chip types that don't use this
clock type.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
/arch/arm/mach-omap2/clock2xxx.h
d8a944582da1a4d29a1487ff7f435643505a12a0 09-Dec-2009 Paul Walmsley <paul@pwsan.com> OMAP2 clock: convert clock24xx.h to clock2xxx_data.c, opp2xxx*

The OMAP2 clock code currently #includes a large .h file full of static
data structures. Instead, define the data in a .c file.

Russell King <linux@arm.linux.org.uk> proposed this new arrangement:

http://marc.info/?l=linux-omap&m=125967425908895&w=2

This patch also deals with most of the flagrant checkpatch violations.

While here, separate the prcm_config data structures out into their own
files, opp2xxx.h and opp24{2,3}0_data.c, and only build in the OPP tables
for the target device. This should save some memory. In the long run,
these prcm_config tables should be replaced with OPP code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Nishanth Menon <nm@ti.com>
/arch/arm/mach-omap2/clock2xxx.h