2009-12-09 07:21:29 +08:00
|
|
|
/*
|
|
|
|
|
* OMAP2 clock function prototypes and macros
|
|
|
|
|
*
|
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
|
|
|
* Copyright (C) 2005-2010 Texas Instruments, Inc.
|
|
|
|
|
* Copyright (C) 2004-2010 Nokia Corporation
|
2009-12-09 07:21:29 +08:00
|
|
|
*/
|
|
|
|
|
|
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
|
|
|
#ifndef __ARCH_ARM_MACH_OMAP2_CLOCK2XXX_H
|
|
|
|
|
#define __ARCH_ARM_MACH_OMAP2_CLOCK2XXX_H
|
2009-12-09 07:21:29 +08:00
|
|
|
|
2012-04-27 18:29:32 +08:00
|
|
|
#include <linux/clk-provider.h>
|
|
|
|
|
#include "clock.h"
|
|
|
|
|
|
|
|
|
|
unsigned long omap2_table_mpu_recalc(struct clk_hw *clk,
|
|
|
|
|
unsigned long parent_rate);
|
|
|
|
|
int omap2_select_table_rate(struct clk_hw *hw, unsigned long rate,
|
|
|
|
|
unsigned long parent_rate);
|
|
|
|
|
long omap2_round_to_table_rate(struct clk_hw *hw, unsigned long rate,
|
|
|
|
|
unsigned long *parent_rate);
|
|
|
|
|
unsigned long omap2xxx_sys_clk_recalc(struct clk_hw *clk,
|
|
|
|
|
unsigned long parent_rate);
|
|
|
|
|
unsigned long omap2_osc_clk_recalc(struct clk_hw *clk,
|
|
|
|
|
unsigned long parent_rate);
|
|
|
|
|
void omap2xxx_clkt_dpllcore_init(struct clk_hw *hw);
|
2012-09-15 13:18:20 +08:00
|
|
|
unsigned long omap2_clk_apll54_recalc(struct clk_hw *hw,
|
|
|
|
|
unsigned long parent_rate);
|
|
|
|
|
unsigned long omap2_clk_apll96_recalc(struct clk_hw *hw,
|
|
|
|
|
unsigned long parent_rate);
|
2012-10-30 10:55:53 +08:00
|
|
|
unsigned long omap2xxx_clk_get_core_rate(void);
|
2010-01-27 11:13:06 +08:00
|
|
|
u32 omap2xxx_get_apll_clkin(void);
|
2010-01-27 11:13:07 +08:00
|
|
|
u32 omap2xxx_get_sysclkdiv(void);
|
2010-01-27 11:13:11 +08:00
|
|
|
void omap2xxx_clk_prepare_for_reboot(void);
|
2012-10-30 10:56:00 +08:00
|
|
|
void omap2xxx_clkt_vps_check_bootloader_rates(void);
|
|
|
|
|
void omap2xxx_clkt_vps_late_init(void);
|
2009-12-09 07:21:29 +08:00
|
|
|
|
2011-01-28 08:39:40 +08:00
|
|
|
#ifdef CONFIG_SOC_OMAP2420
|
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
|
|
|
int omap2420_clk_init(void);
|
2009-12-09 07:21:29 +08:00
|
|
|
#else
|
2011-03-10 09:44:28 +08:00
|
|
|
#define omap2420_clk_init() do { } while(0)
|
2009-12-09 07:21:29 +08:00
|
|
|
#endif
|
|
|
|
|
|
2011-01-28 08:39:40 +08:00
|
|
|
#ifdef CONFIG_SOC_OMAP2430
|
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
|
|
|
int omap2430_clk_init(void);
|
|
|
|
|
#else
|
2011-03-10 09:44:28 +08:00
|
|
|
#define omap2430_clk_init() do { } while(0)
|
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
|
|
|
#endif
|
|
|
|
|
|
2012-04-27 18:29:32 +08:00
|
|
|
extern struct clk_hw *dclk_hw;
|
|
|
|
|
int omap2_enable_osc_ck(struct clk_hw *hw);
|
|
|
|
|
void omap2_disable_osc_ck(struct clk_hw *hw);
|
|
|
|
|
int omap2_clk_apll96_enable(struct clk_hw *hw);
|
|
|
|
|
int omap2_clk_apll54_enable(struct clk_hw *hw);
|
|
|
|
|
void omap2_clk_apll96_disable(struct clk_hw *hw);
|
|
|
|
|
void omap2_clk_apll54_disable(struct clk_hw *hw);
|
2009-12-09 07:21:29 +08:00
|
|
|
|
|
|
|
|
#endif
|
