UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/arch/arm/mach-omap2/clock2xxx.h

45 lines
1.3 KiB
C
Raw Normal View History

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>
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
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>
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
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>
2009-12-09 07:21:29 +08:00
unsigned long omap2_table_mpu_recalc(struct clk *clk);
int omap2_select_table_rate(struct clk *clk, unsigned long rate);
long omap2_round_to_table_rate(struct clk *clk, unsigned long rate);
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>
2010-01-27 11:13:08 +08:00
unsigned long omap2xxx_sys_clk_recalc(struct clk *clk);
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>
2009-12-09 07:21:29 +08:00
unsigned long omap2_osc_clk_recalc(struct clk *clk);
unsigned long omap2_dpllcore_recalc(struct clk *clk);
int omap2_reprogram_dpllcore(struct clk *clk, unsigned long rate);
unsigned long omap2xxx_clk_get_core_rate(struct clk *clk);
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>
2010-01-27 11:13:06 +08:00
u32 omap2xxx_get_apll_clkin(void);
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>
2010-01-27 11:13:07 +08:00
u32 omap2xxx_get_sysclkdiv(void);
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>
2010-01-27 11:13:11 +08:00
void omap2xxx_clk_prepare_for_reboot(void);
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>
2009-12-09 07:21:29 +08:00
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>
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);
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>
2009-12-09 07:21:29 +08:00
#else
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
#define omap2420_clk_init() 0
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>
2009-12-09 07:21:29 +08:00
#endif
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>
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
#define omap2430_clk_init() 0
#endif
extern void __iomem *prcm_clksrc_ctrl, *cm_idlest_pll;
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>
2009-12-09 07:21:29 +08:00
extern struct clk *dclk;
extern const struct clkops clkops_omap2430_i2chs_wait;
extern const struct clkops clkops_oscck;
extern const struct clkops clkops_apll96;
extern const struct clkops clkops_apll54;
#endif