linux/arch/arm/mach-omap2/clock2420_data.c

1951 lines
57 KiB
C
Raw Normal View History

/*
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 05:09:22 +00:00
* linux/arch/arm/mach-omap2/clock2420_data.c
*
* Copyright (C) 2005-2009 Texas Instruments, Inc.
OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are one increment higher than they should be. See for example the OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL". Programming a 0 into the DPLL's M register bitfield is valid for OMAP2/3 and indicates that the DPLL should enter MN-bypass mode. Also, increase the minimum multiplier (M) value for the DPLL rate rounding code from 1 to 2, to ensure that it does not inadvertently put the DPLL into bypass. Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs does not make clear that the actual DPLL divider value (the "N") is the content of the appropriate register bitfield for the N value, _plus one_. (In other words, an N register bitfield of 0 indicates a DPLL divider value of 1.) This is only clearly documented in the OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167 "CM_CLKSEL_DPLL_USB". While here, update copyrights, add kerneldoc for struct dpll_data, drop the unused struct dpll_data.max_tolerance field, remove some unnecessary #includes in DPLL-related code, and replace the #include of <linux/module.h> with <linux/list.h>, which is what was really needed. The OMAP4 clock autogenerator script has 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>
2010-02-23 05:09:12 +00:00
* Copyright (C) 2004-2010 Nokia Corporation
*
* Contacts:
* Richard Woodruff <r-woodruff2@ti.com>
* Paul Walmsley
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <linux/kernel.h>
#include <linux/clk.h>
OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are one increment higher than they should be. See for example the OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL". Programming a 0 into the DPLL's M register bitfield is valid for OMAP2/3 and indicates that the DPLL should enter MN-bypass mode. Also, increase the minimum multiplier (M) value for the DPLL rate rounding code from 1 to 2, to ensure that it does not inadvertently put the DPLL into bypass. Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs does not make clear that the actual DPLL divider value (the "N") is the content of the appropriate register bitfield for the N value, _plus one_. (In other words, an N register bitfield of 0 indicates a DPLL divider value of 1.) This is only clearly documented in the OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167 "CM_CLKSEL_DPLL_USB". While here, update copyrights, add kerneldoc for struct dpll_data, drop the unused struct dpll_data.max_tolerance field, remove some unnecessary #includes in DPLL-related code, and replace the #include of <linux/module.h> with <linux/list.h>, which is what was really needed. The OMAP4 clock autogenerator script has 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>
2010-02-23 05:09:12 +00:00
#include <linux/list.h>
#include <plat/clkdev_omap.h>
#include "clock.h"
#include "clock2xxx.h"
#include "opp2xxx.h"
#include "cm2xxx_3xxx.h"
#include "prm2xxx_3xxx.h"
#include "prm-regbits-24xx.h"
#include "cm-regbits-24xx.h"
#include "sdrc.h"
#include "control.h"
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 05:09:22 +00:00
#define OMAP_CM_REGADDR OMAP2420_CM_REGADDR
/*
* 2420 clock tree.
*
* NOTE:In many cases here we are assigning a 'default' parent. In many
* cases the parent is selectable. The get/set parent calls will also
* switch sources.
*
* Many some clocks say always_enabled, but they can be auto idled for
* power savings. They will always be available upon clock request.
*
* Several sources are given initial rates which may be wrong, this will
* be fixed up in the init func.
*
* Things are broadly separated below by clock domains. It is
* noteworthy that most periferals have dependencies on multiple clock
* domains. Many get their interface clocks from the L4 domain, but get
* functional clocks from fixed sources or other core domain derived
* clocks.
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 05:09:22 +00:00
*/
/* Base external input clocks */
static struct clk func_32k_ck = {
.name = "func_32k_ck",
.ops = &clkops_null,
.rate = 32000,
.clkdm_name = "wkup_clkdm",
};
static struct clk secure_32k_ck = {
.name = "secure_32k_ck",
.ops = &clkops_null,
.rate = 32768,
.clkdm_name = "wkup_clkdm",
};
/* Typical 12/13MHz in standalone mode, will be 26Mhz in chassis mode */
static struct clk osc_ck = { /* (*12, *13, 19.2, *26, 38.4)MHz */
.name = "osc_ck",
.ops = &clkops_oscck,
.clkdm_name = "wkup_clkdm",
.recalc = &omap2_osc_clk_recalc,
};
/* Without modem likely 12MHz, with modem likely 13MHz */
static struct clk sys_ck = { /* (*12, *13, 19.2, 26, 38.4)MHz */
.name = "sys_ck", /* ~ ref_clk also */
.ops = &clkops_null,
.parent = &osc_ck,
.clkdm_name = "wkup_clkdm",
.recalc = &omap2xxx_sys_clk_recalc,
};
static struct clk alt_ck = { /* Typical 54M or 48M, may not exist */
.name = "alt_ck",
.ops = &clkops_null,
.rate = 54000000,
.clkdm_name = "wkup_clkdm",
};
/* Optional external clock input for McBSP CLKS */
static struct clk mcbsp_clks = {
.name = "mcbsp_clks",
.ops = &clkops_null,
};
/*
* Analog domain root source clocks
*/
/* dpll_ck, is broken out in to special cases through clksel */
/* REVISIT: Rate changes on dpll_ck trigger a full set change. ...
* deal with this
*/
ARM: OMAP2: Clock: New OMAP2/3 DPLL rate rounding algorithm This patch adds a new rate rounding algorithm for DPLL clocks on the OMAP2/3 architecture. For a desired DPLL target rate, there may be several multiplier/divider (M, N) values which will generate a sufficiently close rate. Lower N values result in greater power economy. However, lower N values can cause the difference between the rounded rate and the target rate ("rate error") to be larger than it would be with a higher N. This can cause downstream devices to run more slowly than they otherwise would. This DPLL rate rounding algorithm: - attempts to find the lowest possible N (DPLL divider) to reach the target_rate (since, according to Richard Woodruff <r-woodruff@ti.com>, lower N values save more power than higher N values). - allows developers to set an upper bound on the error between the rounded rate and the desired target rate ("rate tolerance"), so an appropriate balance between rate fidelity and power savings can be set. This maximum rate error tolerance is set via omap2_set_dpll_rate_tolerance(). - never returns a rounded rate higher than the target rate. The rate rounding algorithm caches the last rounded M, N, and rate computation to avoid rounding the rate twice for each clk_set_rate() call. (This patch does not yet implement set_rate for DPLLs; that follows in a future patch.) The algorithm trades execution speed for rate accuracy. It will find the (M, N) set that results in the least rate error, within a specified rate tolerance. It does this by evaluating each divider setting - on OMAP3, this involves 128 steps. Another approach to DPLL rate rounding would be to bail out as soon as a valid rate is found within the rate tolerance, which would trade rate accuracy for execution speed. Alternate implementations welcome. This code is not yet used by the OMAP24XX DPLL clock, since it is currently defined as a composite clock, fusing the DPLL M,N and the M2 output divider. This patch also renames the existing OMAP24xx DPLL programming functions to highlight that they program both the DPLL and the DPLL's output multiplier. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-07-03 09:24:46 +00:00
static struct dpll_data dpll_dd = {
.mult_div1_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
.mult_mask = OMAP24XX_DPLL_MULT_MASK,
.div1_mask = OMAP24XX_DPLL_DIV_MASK,
.clk_bypass = &sys_ck,
.clk_ref = &sys_ck,
.control_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKEN),
.enable_mask = OMAP24XX_EN_DPLL_MASK,
OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are one increment higher than they should be. See for example the OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL". Programming a 0 into the DPLL's M register bitfield is valid for OMAP2/3 and indicates that the DPLL should enter MN-bypass mode. Also, increase the minimum multiplier (M) value for the DPLL rate rounding code from 1 to 2, to ensure that it does not inadvertently put the DPLL into bypass. Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs does not make clear that the actual DPLL divider value (the "N") is the content of the appropriate register bitfield for the N value, _plus one_. (In other words, an N register bitfield of 0 indicates a DPLL divider value of 1.) This is only clearly documented in the OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167 "CM_CLKSEL_DPLL_USB". While here, update copyrights, add kerneldoc for struct dpll_data, drop the unused struct dpll_data.max_tolerance field, remove some unnecessary #includes in DPLL-related code, and replace the #include of <linux/module.h> with <linux/list.h>, which is what was really needed. The OMAP4 clock autogenerator script has 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>
2010-02-23 05:09:12 +00:00
.max_multiplier = 1023,
.min_divider = 1,
ARM: OMAP2: Clock: New OMAP2/3 DPLL rate rounding algorithm This patch adds a new rate rounding algorithm for DPLL clocks on the OMAP2/3 architecture. For a desired DPLL target rate, there may be several multiplier/divider (M, N) values which will generate a sufficiently close rate. Lower N values result in greater power economy. However, lower N values can cause the difference between the rounded rate and the target rate ("rate error") to be larger than it would be with a higher N. This can cause downstream devices to run more slowly than they otherwise would. This DPLL rate rounding algorithm: - attempts to find the lowest possible N (DPLL divider) to reach the target_rate (since, according to Richard Woodruff <r-woodruff@ti.com>, lower N values save more power than higher N values). - allows developers to set an upper bound on the error between the rounded rate and the desired target rate ("rate tolerance"), so an appropriate balance between rate fidelity and power savings can be set. This maximum rate error tolerance is set via omap2_set_dpll_rate_tolerance(). - never returns a rounded rate higher than the target rate. The rate rounding algorithm caches the last rounded M, N, and rate computation to avoid rounding the rate twice for each clk_set_rate() call. (This patch does not yet implement set_rate for DPLLs; that follows in a future patch.) The algorithm trades execution speed for rate accuracy. It will find the (M, N) set that results in the least rate error, within a specified rate tolerance. It does this by evaluating each divider setting - on OMAP3, this involves 128 steps. Another approach to DPLL rate rounding would be to bail out as soon as a valid rate is found within the rate tolerance, which would trade rate accuracy for execution speed. Alternate implementations welcome. This code is not yet used by the OMAP24XX DPLL clock, since it is currently defined as a composite clock, fusing the DPLL M,N and the M2 output divider. This patch also renames the existing OMAP24xx DPLL programming functions to highlight that they program both the DPLL and the DPLL's output multiplier. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-07-03 09:24:46 +00:00
.max_divider = 16,
.rate_tolerance = DEFAULT_DPLL_RATE_TOLERANCE
};
ARM: OMAP2: Clock: New OMAP2/3 DPLL rate rounding algorithm This patch adds a new rate rounding algorithm for DPLL clocks on the OMAP2/3 architecture. For a desired DPLL target rate, there may be several multiplier/divider (M, N) values which will generate a sufficiently close rate. Lower N values result in greater power economy. However, lower N values can cause the difference between the rounded rate and the target rate ("rate error") to be larger than it would be with a higher N. This can cause downstream devices to run more slowly than they otherwise would. This DPLL rate rounding algorithm: - attempts to find the lowest possible N (DPLL divider) to reach the target_rate (since, according to Richard Woodruff <r-woodruff@ti.com>, lower N values save more power than higher N values). - allows developers to set an upper bound on the error between the rounded rate and the desired target rate ("rate tolerance"), so an appropriate balance between rate fidelity and power savings can be set. This maximum rate error tolerance is set via omap2_set_dpll_rate_tolerance(). - never returns a rounded rate higher than the target rate. The rate rounding algorithm caches the last rounded M, N, and rate computation to avoid rounding the rate twice for each clk_set_rate() call. (This patch does not yet implement set_rate for DPLLs; that follows in a future patch.) The algorithm trades execution speed for rate accuracy. It will find the (M, N) set that results in the least rate error, within a specified rate tolerance. It does this by evaluating each divider setting - on OMAP3, this involves 128 steps. Another approach to DPLL rate rounding would be to bail out as soon as a valid rate is found within the rate tolerance, which would trade rate accuracy for execution speed. Alternate implementations welcome. This code is not yet used by the OMAP24XX DPLL clock, since it is currently defined as a composite clock, fusing the DPLL M,N and the M2 output divider. This patch also renames the existing OMAP24xx DPLL programming functions to highlight that they program both the DPLL and the DPLL's output multiplier. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-07-03 09:24:46 +00:00
/*
* XXX Cannot add round_rate here yet, as this is still a composite clock,
* not just a DPLL
*/
static struct clk dpll_ck = {
.name = "dpll_ck",
.ops = &clkops_null,
.parent = &sys_ck, /* Can be func_32k also */
.dpll_data = &dpll_dd,
.clkdm_name = "wkup_clkdm",
ARM: OMAP2: Clock: New OMAP2/3 DPLL rate rounding algorithm This patch adds a new rate rounding algorithm for DPLL clocks on the OMAP2/3 architecture. For a desired DPLL target rate, there may be several multiplier/divider (M, N) values which will generate a sufficiently close rate. Lower N values result in greater power economy. However, lower N values can cause the difference between the rounded rate and the target rate ("rate error") to be larger than it would be with a higher N. This can cause downstream devices to run more slowly than they otherwise would. This DPLL rate rounding algorithm: - attempts to find the lowest possible N (DPLL divider) to reach the target_rate (since, according to Richard Woodruff <r-woodruff@ti.com>, lower N values save more power than higher N values). - allows developers to set an upper bound on the error between the rounded rate and the desired target rate ("rate tolerance"), so an appropriate balance between rate fidelity and power savings can be set. This maximum rate error tolerance is set via omap2_set_dpll_rate_tolerance(). - never returns a rounded rate higher than the target rate. The rate rounding algorithm caches the last rounded M, N, and rate computation to avoid rounding the rate twice for each clk_set_rate() call. (This patch does not yet implement set_rate for DPLLs; that follows in a future patch.) The algorithm trades execution speed for rate accuracy. It will find the (M, N) set that results in the least rate error, within a specified rate tolerance. It does this by evaluating each divider setting - on OMAP3, this involves 128 steps. Another approach to DPLL rate rounding would be to bail out as soon as a valid rate is found within the rate tolerance, which would trade rate accuracy for execution speed. Alternate implementations welcome. This code is not yet used by the OMAP24XX DPLL clock, since it is currently defined as a composite clock, fusing the DPLL M,N and the M2 output divider. This patch also renames the existing OMAP24xx DPLL programming functions to highlight that they program both the DPLL and the DPLL's output multiplier. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-07-03 09:24:46 +00:00
.recalc = &omap2_dpllcore_recalc,
.set_rate = &omap2_reprogram_dpllcore,
};
static struct clk apll96_ck = {
.name = "apll96_ck",
.ops = &clkops_apll96,
.parent = &sys_ck,
.rate = 96000000,
.flags = ENABLE_ON_INIT,
.clkdm_name = "wkup_clkdm",
.enable_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKEN),
.enable_bit = OMAP24XX_EN_96M_PLL_SHIFT,
};
static struct clk apll54_ck = {
.name = "apll54_ck",
.ops = &clkops_apll54,
.parent = &sys_ck,
.rate = 54000000,
.flags = ENABLE_ON_INIT,
.clkdm_name = "wkup_clkdm",
.enable_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKEN),
.enable_bit = OMAP24XX_EN_54M_PLL_SHIFT,
};
/*
* PRCM digital base sources
*/
/* func_54m_ck */
static const struct clksel_rate func_54m_apll54_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_24XX },
{ .div = 0 },
};
static const struct clksel_rate func_54m_alt_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 0 },
};
static const struct clksel func_54m_clksel[] = {
{ .parent = &apll54_ck, .rates = func_54m_apll54_rates, },
{ .parent = &alt_ck, .rates = func_54m_alt_rates, },
{ .parent = NULL },
};
static struct clk func_54m_ck = {
.name = "func_54m_ck",
.ops = &clkops_null,
.parent = &apll54_ck, /* can also be alt_clk */
.clkdm_name = "wkup_clkdm",
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_54M_SOURCE_MASK,
.clksel = func_54m_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk core_ck = {
.name = "core_ck",
.ops = &clkops_null,
.parent = &dpll_ck, /* can also be 32k */
.clkdm_name = "wkup_clkdm",
.recalc = &followparent_recalc,
};
static struct clk func_96m_ck = {
.name = "func_96m_ck",
.ops = &clkops_null,
.parent = &apll96_ck,
.clkdm_name = "wkup_clkdm",
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 05:09:22 +00:00
.recalc = &followparent_recalc,
};
/* func_48m_ck */
static const struct clksel_rate func_48m_apll96_rates[] = {
{ .div = 2, .val = 0, .flags = RATE_IN_24XX },
{ .div = 0 },
};
static const struct clksel_rate func_48m_alt_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 0 },
};
static const struct clksel func_48m_clksel[] = {
{ .parent = &apll96_ck, .rates = func_48m_apll96_rates },
{ .parent = &alt_ck, .rates = func_48m_alt_rates },
{ .parent = NULL }
};
static struct clk func_48m_ck = {
.name = "func_48m_ck",
.ops = &clkops_null,
.parent = &apll96_ck, /* 96M or Alt */
.clkdm_name = "wkup_clkdm",
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_48M_SOURCE_MASK,
.clksel = func_48m_clksel,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate = &omap2_clksel_set_rate
};
static struct clk func_12m_ck = {
.name = "func_12m_ck",
.ops = &clkops_null,
.parent = &func_48m_ck,
.fixed_div = 4,
.clkdm_name = "wkup_clkdm",
.recalc = &omap_fixed_divisor_recalc,
};
/* Secure timer, only available in secure mode */
static struct clk wdt1_osc_ck = {
.name = "ck_wdt1_osc",
.ops = &clkops_null, /* RMK: missing? */
.parent = &osc_ck,
.recalc = &followparent_recalc,
};
/*
* The common_clkout* clksel_rate structs are common to
* sys_clkout, sys_clkout_src, sys_clkout2, and sys_clkout2_src.
* sys_clkout2_* are 2420-only, so the
* clksel_rate flags fields are inaccurate for those clocks. This is
* harmless since access to those clocks are gated by the struct clk
* flags fields, which mark them as 2420-only.
*/
static const struct clksel_rate common_clkout_src_core_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel_rate common_clkout_src_sys_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel_rate common_clkout_src_96m_rates[] = {
{ .div = 1, .val = 2, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel_rate common_clkout_src_54m_rates[] = {
{ .div = 1, .val = 3, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel common_clkout_src_clksel[] = {
{ .parent = &core_ck, .rates = common_clkout_src_core_rates },
{ .parent = &sys_ck, .rates = common_clkout_src_sys_rates },
{ .parent = &func_96m_ck, .rates = common_clkout_src_96m_rates },
{ .parent = &func_54m_ck, .rates = common_clkout_src_54m_rates },
{ .parent = NULL }
};
static struct clk sys_clkout_src = {
.name = "sys_clkout_src",
.ops = &clkops_omap2_dflt,
.parent = &func_54m_ck,
.clkdm_name = "wkup_clkdm",
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 05:09:22 +00:00
.enable_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.enable_bit = OMAP24XX_CLKOUT_EN_SHIFT,
.init = &omap2_init_clksel_parent,
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 05:09:22 +00:00
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask = OMAP24XX_CLKOUT_SOURCE_MASK,
.clksel = common_clkout_src_clksel,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate = &omap2_clksel_set_rate
};
static const struct clksel_rate common_clkout_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_24XX },
{ .div = 2, .val = 1, .flags = RATE_IN_24XX },
{ .div = 4, .val = 2, .flags = RATE_IN_24XX },
{ .div = 8, .val = 3, .flags = RATE_IN_24XX },
{ .div = 16, .val = 4, .flags = RATE_IN_24XX },
{ .div = 0 },
};
static const struct clksel sys_clkout_clksel[] = {
{ .parent = &sys_clkout_src, .rates = common_clkout_rates },
{ .parent = NULL }
};
static struct clk sys_clkout = {
.name = "sys_clkout",
.ops = &clkops_null,
.parent = &sys_clkout_src,
.clkdm_name = "wkup_clkdm",
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 05:09:22 +00:00
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask = OMAP24XX_CLKOUT_DIV_MASK,
.clksel = sys_clkout_clksel,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate = &omap2_clksel_set_rate
};
/* In 2430, new in 2420 ES2 */
static struct clk sys_clkout2_src = {
.name = "sys_clkout2_src",
.ops = &clkops_omap2_dflt,
.parent = &func_54m_ck,
.clkdm_name = "wkup_clkdm",
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 05:09:22 +00:00
.enable_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.enable_bit = OMAP2420_CLKOUT2_EN_SHIFT,
.init = &omap2_init_clksel_parent,
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 05:09:22 +00:00
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask = OMAP2420_CLKOUT2_SOURCE_MASK,
.clksel = common_clkout_src_clksel,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate = &omap2_clksel_set_rate
};
static const struct clksel sys_clkout2_clksel[] = {
{ .parent = &sys_clkout2_src, .rates = common_clkout_rates },
{ .parent = NULL }
};
/* In 2430, new in 2420 ES2 */
static struct clk sys_clkout2 = {
.name = "sys_clkout2",
.ops = &clkops_null,
.parent = &sys_clkout2_src,
.clkdm_name = "wkup_clkdm",
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 05:09:22 +00:00
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask = OMAP2420_CLKOUT2_DIV_MASK,
.clksel = sys_clkout2_clksel,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate = &omap2_clksel_set_rate
};
static struct clk emul_ck = {
.name = "emul_ck",
.ops = &clkops_omap2_dflt,
.parent = &func_54m_ck,
.clkdm_name = "wkup_clkdm",
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 05:09:22 +00:00
.enable_reg = OMAP2420_PRCM_CLKEMUL_CTRL,
.enable_bit = OMAP24XX_EMULATION_EN_SHIFT,
.recalc = &followparent_recalc,
};
/*
* MPU clock domain
* Clocks:
* MPU_FCLK, MPU_ICLK
* INT_M_FCLK, INT_M_I_CLK
*
* - Individual clocks are hardware managed.
* - Base divider comes from: CM_CLKSEL_MPU
*
*/
static const struct clksel_rate mpu_core_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 2, .val = 2, .flags = RATE_IN_24XX },
{ .div = 4, .val = 4, .flags = RATE_IN_242X },
{ .div = 6, .val = 6, .flags = RATE_IN_242X },
{ .div = 8, .val = 8, .flags = RATE_IN_242X },
{ .div = 0 },
};
static const struct clksel mpu_clksel[] = {
{ .parent = &core_ck, .rates = mpu_core_rates },
{ .parent = NULL }
};
static struct clk mpu_ck = { /* Control cpu */
.name = "mpu_ck",
.ops = &clkops_null,
.parent = &core_ck,
.clkdm_name = "mpu_clkdm",
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(MPU_MOD, CM_CLKSEL),
.clksel_mask = OMAP24XX_CLKSEL_MPU_MASK,
.clksel = mpu_clksel,
.recalc = &omap2_clksel_recalc,
};
/*
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 05:09:22 +00:00
* DSP (2420-UMA+IVA1) clock domain
* Clocks:
* 2420: UMA_FCLK, UMA_ICLK, IVA_MPU, IVA_COP
*
* Won't be too specific here. The core clock comes into this block
* it is divided then tee'ed. One branch goes directly to xyz enable
* controls. The other branch gets further divided by 2 then possibly
* routed into a synchronizer and out of clocks abc.
*/
static const struct clksel_rate dsp_fck_core_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 2, .val = 2, .flags = RATE_IN_24XX },
{ .div = 3, .val = 3, .flags = RATE_IN_24XX },
{ .div = 4, .val = 4, .flags = RATE_IN_24XX },
{ .div = 6, .val = 6, .flags = RATE_IN_242X },
{ .div = 8, .val = 8, .flags = RATE_IN_242X },
{ .div = 12, .val = 12, .flags = RATE_IN_242X },
{ .div = 0 },
};
static const struct clksel dsp_fck_clksel[] = {
{ .parent = &core_ck, .rates = dsp_fck_core_rates },
{ .parent = NULL }
};
static struct clk dsp_fck = {
.name = "dsp_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &core_ck,
.clkdm_name = "dsp_clkdm",
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_CM_FCLKEN_DSP_EN_DSP_SHIFT,
.clksel_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_CLKSEL),
.clksel_mask = OMAP24XX_CLKSEL_DSP_MASK,
.clksel = dsp_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
/* DSP interface clock */
static const struct clksel_rate dsp_irate_ick_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 2, .val = 2, .flags = RATE_IN_24XX },
{ .div = 0 },
};
static const struct clksel dsp_irate_ick_clksel[] = {
{ .parent = &dsp_fck, .rates = dsp_irate_ick_rates },
{ .parent = NULL }
};
/* This clock does not exist as such in the TRM. */
static struct clk dsp_irate_ick = {
.name = "dsp_irate_ick",
.ops = &clkops_null,
.parent = &dsp_fck,
.clksel_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_CLKSEL),
.clksel_mask = OMAP24XX_CLKSEL_DSP_IF_MASK,
.clksel = dsp_irate_ick_clksel,
.recalc = &omap2_clksel_recalc,
};
/* 2420 only */
static struct clk dsp_ick = {
.name = "dsp_ick", /* apparently ipi and isp */
.ops = &clkops_omap2_dflt_wait,
.parent = &dsp_irate_ick,
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_ICLKEN),
.enable_bit = OMAP2420_EN_DSP_IPI_SHIFT, /* for ipi */
};
/*
* The IVA1 is an ARM7 core on the 2420 that has nothing to do with
* the C54x, but which is contained in the DSP powerdomain. Does not
* exist on later OMAPs.
*/
static struct clk iva1_ifck = {
.name = "iva1_ifck",
.ops = &clkops_omap2_dflt_wait,
.parent = &core_ck,
.clkdm_name = "iva1_clkdm",
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP2420_EN_IVA_COP_SHIFT,
.clksel_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_CLKSEL),
.clksel_mask = OMAP2420_CLKSEL_IVA_MASK,
.clksel = dsp_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
/* IVA1 mpu/int/i/f clocks are /2 of parent */
static struct clk iva1_mpu_int_ifck = {
.name = "iva1_mpu_int_ifck",
.ops = &clkops_omap2_dflt_wait,
.parent = &iva1_ifck,
.clkdm_name = "iva1_clkdm",
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP2420_EN_IVA_MPU_SHIFT,
.fixed_div = 2,
.recalc = &omap_fixed_divisor_recalc,
};
/*
* L3 clock domain
* L3 clocks are used for both interface and functional clocks to
* multiple entities. Some of these clocks are completely managed
* by hardware, and some others allow software control. Hardware
* managed ones general are based on directly CLK_REQ signals and
* various auto idle settings. The functional spec sets many of these
* as 'tie-high' for their enables.
*
* I-CLOCKS:
* L3-Interconnect, SMS, GPMC, SDRC, OCM_RAM, OCM_ROM, SDMA
* CAM, HS-USB.
* F-CLOCK
* SSI.
*
* GPMC memories and SDRC have timing and clock sensitive registers which
* may very well need notification when the clock changes. Currently for low
* operating points, these are taken care of in sleep.S.
*/
static const struct clksel_rate core_l3_core_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 2, .val = 2, .flags = RATE_IN_242X },
{ .div = 4, .val = 4, .flags = RATE_IN_24XX },
{ .div = 6, .val = 6, .flags = RATE_IN_24XX },
{ .div = 8, .val = 8, .flags = RATE_IN_242X },
{ .div = 12, .val = 12, .flags = RATE_IN_242X },
{ .div = 16, .val = 16, .flags = RATE_IN_242X },
{ .div = 0 }
};
static const struct clksel core_l3_clksel[] = {
{ .parent = &core_ck, .rates = core_l3_core_rates },
{ .parent = NULL }
};
static struct clk core_l3_ck = { /* Used for ick and fck, interconnect */
.name = "core_l3_ck",
.ops = &clkops_null,
.parent = &core_ck,
.clkdm_name = "core_l3_clkdm",
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_CLKSEL_L3_MASK,
.clksel = core_l3_clksel,
.recalc = &omap2_clksel_recalc,
};
/* usb_l4_ick */
static const struct clksel_rate usb_l4_ick_core_l3_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 2, .val = 2, .flags = RATE_IN_24XX },
{ .div = 4, .val = 4, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel usb_l4_ick_clksel[] = {
{ .parent = &core_l3_ck, .rates = usb_l4_ick_core_l3_rates },
{ .parent = NULL },
};
/* It is unclear from TRM whether usb_l4_ick is really in L3 or L4 clkdm */
static struct clk usb_l4_ick = { /* FS-USB interface clock */
.name = "usb_l4_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &core_l3_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN2),
.enable_bit = OMAP24XX_EN_USB_SHIFT,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_CLKSEL_USB_MASK,
.clksel = usb_l4_ick_clksel,
.recalc = &omap2_clksel_recalc,
};
/*
* L4 clock management domain
*
* This domain contains lots of interface clocks from the L4 interface, some
* functional clocks. Fixed APLL functional source clocks are managed in
* this domain.
*/
static const struct clksel_rate l4_core_l3_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 2, .val = 2, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel l4_clksel[] = {
{ .parent = &core_l3_ck, .rates = l4_core_l3_rates },
{ .parent = NULL }
};
static struct clk l4_ck = { /* used both as an ick and fck */
.name = "l4_ck",
.ops = &clkops_null,
.parent = &core_l3_ck,
.clkdm_name = "core_l4_clkdm",
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_CLKSEL_L4_MASK,
.clksel = l4_clksel,
.recalc = &omap2_clksel_recalc,
};
/*
* SSI is in L3 management domain, its direct parent is core not l3,
* many core power domain entities are grouped into the L3 clock
* domain.
* SSI_SSR_FCLK, SSI_SST_FCLK, SSI_L4_ICLK
*
* ssr = core/1/2/3/4/5, sst = 1/2 ssr.
*/
static const struct clksel_rate ssi_ssr_sst_fck_core_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 2, .val = 2, .flags = RATE_IN_24XX },
{ .div = 3, .val = 3, .flags = RATE_IN_24XX },
{ .div = 4, .val = 4, .flags = RATE_IN_24XX },
{ .div = 6, .val = 6, .flags = RATE_IN_242X },
{ .div = 8, .val = 8, .flags = RATE_IN_242X },
{ .div = 0 }
};
static const struct clksel ssi_ssr_sst_fck_clksel[] = {
{ .parent = &core_ck, .rates = ssi_ssr_sst_fck_core_rates },
{ .parent = NULL }
};
static struct clk ssi_ssr_sst_fck = {
.name = "ssi_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &core_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_FCLKEN2),
.enable_bit = OMAP24XX_EN_SSI_SHIFT,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_CLKSEL_SSI_MASK,
.clksel = ssi_ssr_sst_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
/*
* Presumably this is the same as SSI_ICLK.
* TRM contradicts itself on what clockdomain SSI_ICLK is in
*/
static struct clk ssi_l4_ick = {
.name = "ssi_l4_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN2),
.enable_bit = OMAP24XX_EN_SSI_SHIFT,
.recalc = &followparent_recalc,
};
/*
* GFX clock domain
* Clocks:
* GFX_FCLK, GFX_ICLK
* GFX_CG1(2d), GFX_CG2(3d)
*
* GFX_FCLK runs from L3, and is divided by (1,2,3,4)
* The 2d and 3d clocks run at a hardware determined
* divided value of fclk.
*
*/
/* This clksel struct is shared between gfx_3d_fck and gfx_2d_fck */
static const struct clksel gfx_fck_clksel[] = {
{ .parent = &core_l3_ck, .rates = gfx_l3_rates },
{ .parent = NULL },
};
static struct clk gfx_3d_fck = {
.name = "gfx_3d_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &core_l3_ck,
.clkdm_name = "gfx_clkdm",
.enable_reg = OMAP_CM_REGADDR(GFX_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_EN_3D_SHIFT,
.clksel_reg = OMAP_CM_REGADDR(GFX_MOD, CM_CLKSEL),
.clksel_mask = OMAP_CLKSEL_GFX_MASK,
.clksel = gfx_fck_clksel,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate = &omap2_clksel_set_rate
};
static struct clk gfx_2d_fck = {
.name = "gfx_2d_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &core_l3_ck,
.clkdm_name = "gfx_clkdm",
.enable_reg = OMAP_CM_REGADDR(GFX_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_EN_2D_SHIFT,
.clksel_reg = OMAP_CM_REGADDR(GFX_MOD, CM_CLKSEL),
.clksel_mask = OMAP_CLKSEL_GFX_MASK,
.clksel = gfx_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gfx_ick = {
.name = "gfx_ick", /* From l3 */
.ops = &clkops_omap2_dflt_wait,
.parent = &core_l3_ck,
.clkdm_name = "gfx_clkdm",
.enable_reg = OMAP_CM_REGADDR(GFX_MOD, CM_ICLKEN),
.enable_bit = OMAP_EN_GFX_SHIFT,
.recalc = &followparent_recalc,
};
/*
* DSS clock domain
* CLOCKs:
* DSS_L4_ICLK, DSS_L3_ICLK,
* DSS_CLK1, DSS_CLK2, DSS_54MHz_CLK
*
* DSS is both initiator and target.
*/
/* XXX Add RATE_NOT_VALIDATED */
static const struct clksel_rate dss1_fck_sys_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel_rate dss1_fck_core_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 2, .val = 2, .flags = RATE_IN_24XX },
{ .div = 3, .val = 3, .flags = RATE_IN_24XX },
{ .div = 4, .val = 4, .flags = RATE_IN_24XX },
{ .div = 5, .val = 5, .flags = RATE_IN_24XX },
{ .div = 6, .val = 6, .flags = RATE_IN_24XX },
{ .div = 8, .val = 8, .flags = RATE_IN_24XX },
{ .div = 9, .val = 9, .flags = RATE_IN_24XX },
{ .div = 12, .val = 12, .flags = RATE_IN_24XX },
{ .div = 16, .val = 16, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel dss1_fck_clksel[] = {
{ .parent = &sys_ck, .rates = dss1_fck_sys_rates },
{ .parent = &core_ck, .rates = dss1_fck_core_rates },
{ .parent = NULL },
};
static struct clk dss_ick = { /* Enables both L3,L4 ICLK's */
.name = "dss_ick",
.ops = &clkops_omap2_dflt,
.parent = &l4_ck, /* really both l3 and l4 */
.clkdm_name = "dss_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_DSS1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk dss1_fck = {
.name = "dss1_fck",
.ops = &clkops_omap2_dflt,
.parent = &core_ck, /* Core or sys */
.clkdm_name = "dss_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_DSS1_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_CLKSEL_DSS1_MASK,
.clksel = dss1_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
static const struct clksel_rate dss2_fck_sys_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel_rate dss2_fck_48m_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel dss2_fck_clksel[] = {
{ .parent = &sys_ck, .rates = dss2_fck_sys_rates },
{ .parent = &func_48m_ck, .rates = dss2_fck_48m_rates },
{ .parent = NULL }
};
static struct clk dss2_fck = { /* Alt clk used in power management */
.name = "dss2_fck",
.ops = &clkops_omap2_dflt,
.parent = &sys_ck, /* fixed at sys_ck or 48MHz */
.clkdm_name = "dss_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_DSS2_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_CLKSEL_DSS2_MASK,
.clksel = dss2_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk dss_54m_fck = { /* Alt clk used in power management */
.name = "dss_54m_fck", /* 54m tv clk */
.ops = &clkops_omap2_dflt_wait,
.parent = &func_54m_ck,
.clkdm_name = "dss_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_TV_SHIFT,
.recalc = &followparent_recalc,
};
/*
* CORE power domain ICLK & FCLK defines.
* Many of the these can have more than one possible parent. Entries
* here will likely have an L4 interface parent, and may have multiple
* functional clock parents.
*/
static const struct clksel_rate gpt_alt_rates[] = {
{ .div = 1, .val = 2, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel omap24xx_gpt_clksel[] = {
{ .parent = &func_32k_ck, .rates = gpt_32k_rates },
{ .parent = &sys_ck, .rates = gpt_sys_rates },
{ .parent = &alt_ck, .rates = gpt_alt_rates },
{ .parent = NULL },
};
static struct clk gpt1_ick = {
.name = "gpt1_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_GPT1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt1_fck = {
.name = "gpt1_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_EN_GPT1_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_CLKSEL1),
.clksel_mask = OMAP24XX_CLKSEL_GPT1_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate = &omap2_clksel_set_rate
};
static struct clk gpt2_ick = {
.name = "gpt2_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT2_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt2_fck = {
.name = "gpt2_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT2_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT2_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt3_ick = {
.name = "gpt3_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT3_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt3_fck = {
.name = "gpt3_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT3_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT3_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt4_ick = {
.name = "gpt4_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT4_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt4_fck = {
.name = "gpt4_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT4_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT4_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt5_ick = {
.name = "gpt5_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT5_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt5_fck = {
.name = "gpt5_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT5_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT5_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt6_ick = {
.name = "gpt6_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT6_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt6_fck = {
.name = "gpt6_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT6_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT6_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt7_ick = {
.name = "gpt7_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT7_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt7_fck = {
.name = "gpt7_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT7_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT7_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt8_ick = {
.name = "gpt8_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT8_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt8_fck = {
.name = "gpt8_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT8_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT8_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt9_ick = {
.name = "gpt9_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT9_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt9_fck = {
.name = "gpt9_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT9_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT9_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt10_ick = {
.name = "gpt10_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT10_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt10_fck = {
.name = "gpt10_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT10_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT10_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt11_ick = {
.name = "gpt11_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT11_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt11_fck = {
.name = "gpt11_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT11_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT11_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk gpt12_ick = {
.name = "gpt12_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT12_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpt12_fck = {
.name = "gpt12_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &secure_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_GPT12_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL2),
.clksel_mask = OMAP24XX_CLKSEL_GPT12_MASK,
.clksel = omap24xx_gpt_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk mcbsp1_ick = {
.name = "mcbsp1_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_MCBSP1_SHIFT,
.recalc = &followparent_recalc,
};
static const struct clksel_rate common_mcbsp_96m_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel_rate common_mcbsp_mcbsp_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_24XX },
{ .div = 0 }
};
static const struct clksel mcbsp_fck_clksel[] = {
{ .parent = &func_96m_ck, .rates = common_mcbsp_96m_rates },
{ .parent = &mcbsp_clks, .rates = common_mcbsp_mcbsp_rates },
{ .parent = NULL }
};
static struct clk mcbsp1_fck = {
.name = "mcbsp1_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_96m_ck,
.init = &omap2_init_clksel_parent,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_MCBSP1_SHIFT,
.clksel_reg = OMAP242X_CTRL_REGADDR(OMAP2_CONTROL_DEVCONF0),
.clksel_mask = OMAP2_MCBSP1_CLKS_MASK,
.clksel = mcbsp_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk mcbsp2_ick = {
.name = "mcbsp2_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_MCBSP2_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mcbsp2_fck = {
.name = "mcbsp2_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_96m_ck,
.init = &omap2_init_clksel_parent,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_MCBSP2_SHIFT,
.clksel_reg = OMAP242X_CTRL_REGADDR(OMAP2_CONTROL_DEVCONF0),
.clksel_mask = OMAP2_MCBSP2_CLKS_MASK,
.clksel = mcbsp_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk mcspi1_ick = {
.name = "mcspi1_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_MCSPI1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mcspi1_fck = {
.name = "mcspi1_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_48m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_MCSPI1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mcspi2_ick = {
.name = "mcspi2_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_MCSPI2_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mcspi2_fck = {
.name = "mcspi2_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_48m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_MCSPI2_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk uart1_ick = {
.name = "uart1_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_UART1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk uart1_fck = {
.name = "uart1_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_48m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_UART1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk uart2_ick = {
.name = "uart2_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_UART2_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk uart2_fck = {
.name = "uart2_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_48m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_UART2_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk uart3_ick = {
.name = "uart3_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN2),
.enable_bit = OMAP24XX_EN_UART3_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk uart3_fck = {
.name = "uart3_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_48m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_FCLKEN2),
.enable_bit = OMAP24XX_EN_UART3_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpios_ick = {
.name = "gpios_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_GPIOS_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpios_fck = {
.name = "gpios_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "wkup_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_EN_GPIOS_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mpu_wdt_ick = {
.name = "mpu_wdt_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_MPU_WDT_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mpu_wdt_fck = {
.name = "mpu_wdt_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "wkup_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_EN_MPU_WDT_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk sync_32k_ick = {
.name = "sync_32k_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.flags = ENABLE_ON_INIT,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_32KSYNC_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk wdt1_ick = {
.name = "wdt1_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_WDT1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk omapctrl_ick = {
.name = "omapctrl_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.flags = ENABLE_ON_INIT,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_OMAPCTRL_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk cam_ick = {
.name = "cam_ick",
.ops = &clkops_omap2_dflt,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_CAM_SHIFT,
.recalc = &followparent_recalc,
};
/*
* cam_fck controls both CAM_MCLK and CAM_FCLK. It should probably be
* split into two separate clocks, since the parent clocks are different
* and the clockdomains are also different.
*/
static struct clk cam_fck = {
.name = "cam_fck",
.ops = &clkops_omap2_dflt,
.parent = &func_96m_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_CAM_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mailboxes_ick = {
.name = "mailboxes_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_MAILBOXES_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk wdt4_ick = {
.name = "wdt4_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_WDT4_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk wdt4_fck = {
.name = "wdt4_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_WDT4_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk wdt3_ick = {
.name = "wdt3_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP2420_EN_WDT3_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk wdt3_fck = {
.name = "wdt3_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_32k_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP2420_EN_WDT3_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mspro_ick = {
.name = "mspro_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_MSPRO_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mspro_fck = {
.name = "mspro_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_96m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_MSPRO_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mmc_ick = {
.name = "mmc_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP2420_EN_MMC_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk mmc_fck = {
.name = "mmc_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_96m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP2420_EN_MMC_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk fac_ick = {
.name = "fac_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_FAC_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk fac_fck = {
.name = "fac_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_12m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_FAC_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk eac_ick = {
.name = "eac_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP2420_EN_EAC_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk eac_fck = {
.name = "eac_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_96m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP2420_EN_EAC_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk hdq_ick = {
.name = "hdq_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_HDQ_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk hdq_fck = {
.name = "hdq_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_12m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP24XX_EN_HDQ_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk i2c2_ick = {
.name = "i2c2_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP2420_EN_I2C2_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk i2c2_fck = {
.name = "i2c2_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_12m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP2420_EN_I2C2_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk i2c1_ick = {
.name = "i2c1_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP2420_EN_I2C1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk i2c1_fck = {
.name = "i2c1_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_12m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP2420_EN_I2C1_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk gpmc_fck = {
.name = "gpmc_fck",
.ops = &clkops_null, /* RMK: missing? */
.parent = &core_l3_ck,
.flags = ENABLE_ON_INIT,
.clkdm_name = "core_l3_clkdm",
.recalc = &followparent_recalc,
};
static struct clk sdma_fck = {
.name = "sdma_fck",
.ops = &clkops_null, /* RMK: missing? */
.parent = &core_l3_ck,
.clkdm_name = "core_l3_clkdm",
.recalc = &followparent_recalc,
};
static struct clk sdma_ick = {
.name = "sdma_ick",
.ops = &clkops_null, /* RMK: missing? */
.parent = &l4_ck,
.clkdm_name = "core_l3_clkdm",
.recalc = &followparent_recalc,
};
static struct clk vlynq_ick = {
.name = "vlynq_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &core_l3_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP2420_EN_VLYNQ_SHIFT,
.recalc = &followparent_recalc,
};
static const struct clksel_rate vlynq_fck_96m_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_242X },
{ .div = 0 }
};
static const struct clksel_rate vlynq_fck_core_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_242X },
{ .div = 2, .val = 2, .flags = RATE_IN_242X },
{ .div = 3, .val = 3, .flags = RATE_IN_242X },
{ .div = 4, .val = 4, .flags = RATE_IN_242X },
{ .div = 6, .val = 6, .flags = RATE_IN_242X },
{ .div = 8, .val = 8, .flags = RATE_IN_242X },
{ .div = 9, .val = 9, .flags = RATE_IN_242X },
{ .div = 12, .val = 12, .flags = RATE_IN_242X },
{ .div = 16, .val = 16, .flags = RATE_IN_242X },
{ .div = 18, .val = 18, .flags = RATE_IN_242X },
{ .div = 0 }
};
static const struct clksel vlynq_fck_clksel[] = {
{ .parent = &func_96m_ck, .rates = vlynq_fck_96m_rates },
{ .parent = &core_ck, .rates = vlynq_fck_core_rates },
{ .parent = NULL }
};
static struct clk vlynq_fck = {
.name = "vlynq_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_96m_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP2420_EN_VLYNQ_SHIFT,
.init = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask = OMAP2420_CLKSEL_VLYNQ_MASK,
.clksel = vlynq_fck_clksel,
.recalc = &omap2_clksel_recalc,
};
static struct clk des_ick = {
.name = "des_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_ICLKEN4),
.enable_bit = OMAP24XX_EN_DES_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk sha_ick = {
.name = "sha_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_ICLKEN4),
.enable_bit = OMAP24XX_EN_SHA_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk rng_ick = {
.name = "rng_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_ICLKEN4),
.enable_bit = OMAP24XX_EN_RNG_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk aes_ick = {
.name = "aes_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_ICLKEN4),
.enable_bit = OMAP24XX_EN_AES_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk pka_ick = {
.name = "pka_ick",
.ops = &clkops_omap2_dflt_wait,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_ICLKEN4),
.enable_bit = OMAP24XX_EN_PKA_SHIFT,
.recalc = &followparent_recalc,
};
static struct clk usb_fck = {
.name = "usb_fck",
.ops = &clkops_omap2_dflt_wait,
.parent = &func_48m_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_FCLKEN2),
.enable_bit = OMAP24XX_EN_USB_SHIFT,
.recalc = &followparent_recalc,
};
/*
* This clock is a composite clock which does entire set changes then
* forces a rebalance. It keys on the MPU speed, but it really could
* be any key speed part of a set in the rate table.
*
* to really change a set, you need memory table sets which get changed
* in sram, pre-notifiers & post notifiers, changing the top set, without
* having low level display recalc's won't work... this is why dpm notifiers
* work, isr's off, walk a list of clocks already _off_ and not messing with
* the bus.
*
* This clock should have no parent. It embodies the entire upper level
* active set. A parent will mess up some of the init also.
*/
static struct clk virt_prcm_set = {
.name = "virt_prcm_set",
.ops = &clkops_null,
.parent = &mpu_ck, /* Indexed by mpu speed, no parent */
.recalc = &omap2_table_mpu_recalc, /* sets are keyed on mpu rate */
.set_rate = &omap2_select_table_rate,
.round_rate = &omap2_round_to_table_rate,
};
/*
* clkdev integration
*/
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 05:09:22 +00:00
static struct omap_clk omap2420_clks[] = {
/* external root sources */
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 05:09:22 +00:00
CLK(NULL, "func_32k_ck", &func_32k_ck, CK_242X),
CLK(NULL, "secure_32k_ck", &secure_32k_ck, CK_242X),
CLK(NULL, "osc_ck", &osc_ck, CK_242X),
CLK(NULL, "sys_ck", &sys_ck, CK_242X),
CLK(NULL, "alt_ck", &alt_ck, CK_242X),
CLK("omap-mcbsp.1", "pad_fck", &mcbsp_clks, CK_242X),
CLK("omap-mcbsp.2", "pad_fck", &mcbsp_clks, CK_242X),
CLK(NULL, "mcbsp_clks", &mcbsp_clks, CK_242X),
/* internal analog sources */
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 05:09:22 +00:00
CLK(NULL, "dpll_ck", &dpll_ck, CK_242X),
CLK(NULL, "apll96_ck", &apll96_ck, CK_242X),
CLK(NULL, "apll54_ck", &apll54_ck, CK_242X),
/* internal prcm root sources */
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 05:09:22 +00:00
CLK(NULL, "func_54m_ck", &func_54m_ck, CK_242X),
CLK(NULL, "core_ck", &core_ck, CK_242X),
CLK("omap-mcbsp.1", "prcm_fck", &func_96m_ck, CK_242X),
CLK("omap-mcbsp.2", "prcm_fck", &func_96m_ck, CK_242X),
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 05:09:22 +00:00
CLK(NULL, "func_96m_ck", &func_96m_ck, CK_242X),
CLK(NULL, "func_48m_ck", &func_48m_ck, CK_242X),
CLK(NULL, "func_12m_ck", &func_12m_ck, CK_242X),
CLK(NULL, "ck_wdt1_osc", &wdt1_osc_ck, CK_242X),
CLK(NULL, "sys_clkout_src", &sys_clkout_src, CK_242X),
CLK(NULL, "sys_clkout", &sys_clkout, CK_242X),
CLK(NULL, "sys_clkout2_src", &sys_clkout2_src, CK_242X),
CLK(NULL, "sys_clkout2", &sys_clkout2, CK_242X),
CLK(NULL, "emul_ck", &emul_ck, CK_242X),
/* mpu domain clocks */
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 05:09:22 +00:00
CLK(NULL, "mpu_ck", &mpu_ck, CK_242X),
/* dsp domain clocks */
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 05:09:22 +00:00
CLK(NULL, "dsp_fck", &dsp_fck, CK_242X),
CLK(NULL, "dsp_irate_ick", &dsp_irate_ick, CK_242X),
CLK(NULL, "dsp_ick", &dsp_ick, CK_242X),
CLK(NULL, "iva1_ifck", &iva1_ifck, CK_242X),
CLK(NULL, "iva1_mpu_int_ifck", &iva1_mpu_int_ifck, CK_242X),
/* GFX domain clocks */
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 05:09:22 +00:00
CLK(NULL, "gfx_3d_fck", &gfx_3d_fck, CK_242X),
CLK(NULL, "gfx_2d_fck", &gfx_2d_fck, CK_242X),
CLK(NULL, "gfx_ick", &gfx_ick, CK_242X),
/* DSS domain clocks */
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 05:09:22 +00:00
CLK("omapdss", "ick", &dss_ick, CK_242X),
CLK("omapdss", "dss1_fck", &dss1_fck, CK_242X),
CLK("omapdss", "dss2_fck", &dss2_fck, CK_242X),
CLK("omapdss", "tv_fck", &dss_54m_fck, CK_242X),
/* L3 domain clocks */
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 05:09:22 +00:00
CLK(NULL, "core_l3_ck", &core_l3_ck, CK_242X),
CLK(NULL, "ssi_fck", &ssi_ssr_sst_fck, CK_242X),
CLK(NULL, "usb_l4_ick", &usb_l4_ick, CK_242X),
/* L4 domain clocks */
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 05:09:22 +00:00
CLK(NULL, "l4_ck", &l4_ck, CK_242X),
CLK(NULL, "ssi_l4_ick", &ssi_l4_ick, CK_242X),
/* virtual meta-group clock */
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 05:09:22 +00:00
CLK(NULL, "virt_prcm_set", &virt_prcm_set, CK_242X),
/* general l4 interface ck, multi-parent functional clk */
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 05:09:22 +00:00
CLK(NULL, "gpt1_ick", &gpt1_ick, CK_242X),
CLK(NULL, "gpt1_fck", &gpt1_fck, CK_242X),
CLK(NULL, "gpt2_ick", &gpt2_ick, CK_242X),
CLK(NULL, "gpt2_fck", &gpt2_fck, CK_242X),
CLK(NULL, "gpt3_ick", &gpt3_ick, CK_242X),
CLK(NULL, "gpt3_fck", &gpt3_fck, CK_242X),
CLK(NULL, "gpt4_ick", &gpt4_ick, CK_242X),
CLK(NULL, "gpt4_fck", &gpt4_fck, CK_242X),
CLK(NULL, "gpt5_ick", &gpt5_ick, CK_242X),
CLK(NULL, "gpt5_fck", &gpt5_fck, CK_242X),
CLK(NULL, "gpt6_ick", &gpt6_ick, CK_242X),
CLK(NULL, "gpt6_fck", &gpt6_fck, CK_242X),
CLK(NULL, "gpt7_ick", &gpt7_ick, CK_242X),
CLK(NULL, "gpt7_fck", &gpt7_fck, CK_242X),
CLK(NULL, "gpt8_ick", &gpt8_ick, CK_242X),
CLK(NULL, "gpt8_fck", &gpt8_fck, CK_242X),
CLK(NULL, "gpt9_ick", &gpt9_ick, CK_242X),
CLK(NULL, "gpt9_fck", &gpt9_fck, CK_242X),
CLK(NULL, "gpt10_ick", &gpt10_ick, CK_242X),
CLK(NULL, "gpt10_fck", &gpt10_fck, CK_242X),
CLK(NULL, "gpt11_ick", &gpt11_ick, CK_242X),
CLK(NULL, "gpt11_fck", &gpt11_fck, CK_242X),
CLK(NULL, "gpt12_ick", &gpt12_ick, CK_242X),
CLK(NULL, "gpt12_fck", &gpt12_fck, CK_242X),
CLK("omap-mcbsp.1", "ick", &mcbsp1_ick, CK_242X),
CLK("omap-mcbsp.1", "fck", &mcbsp1_fck, CK_242X),
CLK("omap-mcbsp.2", "ick", &mcbsp2_ick, CK_242X),
CLK("omap-mcbsp.2", "fck", &mcbsp2_fck, CK_242X),
CLK("omap2_mcspi.1", "ick", &mcspi1_ick, CK_242X),
CLK("omap2_mcspi.1", "fck", &mcspi1_fck, CK_242X),
CLK("omap2_mcspi.2", "ick", &mcspi2_ick, CK_242X),
CLK("omap2_mcspi.2", "fck", &mcspi2_fck, CK_242X),
CLK(NULL, "uart1_ick", &uart1_ick, CK_242X),
CLK(NULL, "uart1_fck", &uart1_fck, CK_242X),
CLK(NULL, "uart2_ick", &uart2_ick, CK_242X),
CLK(NULL, "uart2_fck", &uart2_fck, CK_242X),
CLK(NULL, "uart3_ick", &uart3_ick, CK_242X),
CLK(NULL, "uart3_fck", &uart3_fck, CK_242X),
CLK(NULL, "gpios_ick", &gpios_ick, CK_242X),
CLK(NULL, "gpios_fck", &gpios_fck, CK_242X),
CLK("omap_wdt", "ick", &mpu_wdt_ick, CK_242X),
CLK("omap_wdt", "fck", &mpu_wdt_fck, CK_242X),
CLK(NULL, "sync_32k_ick", &sync_32k_ick, CK_242X),
CLK(NULL, "wdt1_ick", &wdt1_ick, CK_242X),
CLK(NULL, "omapctrl_ick", &omapctrl_ick, CK_242X),
CLK("omap24xxcam", "fck", &cam_fck, CK_242X),
CLK("omap24xxcam", "ick", &cam_ick, CK_242X),
CLK(NULL, "mailboxes_ick", &mailboxes_ick, CK_242X),
CLK(NULL, "wdt4_ick", &wdt4_ick, CK_242X),
CLK(NULL, "wdt4_fck", &wdt4_fck, CK_242X),
CLK(NULL, "wdt3_ick", &wdt3_ick, CK_242X),
CLK(NULL, "wdt3_fck", &wdt3_fck, CK_242X),
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 05:09:22 +00:00
CLK(NULL, "mspro_ick", &mspro_ick, CK_242X),
CLK(NULL, "mspro_fck", &mspro_fck, CK_242X),
CLK("mmci-omap.0", "ick", &mmc_ick, CK_242X),
CLK("mmci-omap.0", "fck", &mmc_fck, CK_242X),
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 05:09:22 +00:00
CLK(NULL, "fac_ick", &fac_ick, CK_242X),
CLK(NULL, "fac_fck", &fac_fck, CK_242X),
CLK(NULL, "eac_ick", &eac_ick, CK_242X),
CLK(NULL, "eac_fck", &eac_fck, CK_242X),
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 05:09:22 +00:00
CLK("omap_hdq.0", "ick", &hdq_ick, CK_242X),
CLK("omap_hdq.1", "fck", &hdq_fck, CK_242X),
CLK("omap_i2c.1", "ick", &i2c1_ick, CK_242X),
CLK("omap_i2c.1", "fck", &i2c1_fck, CK_242X),
CLK("omap_i2c.2", "ick", &i2c2_ick, CK_242X),
CLK("omap_i2c.2", "fck", &i2c2_fck, CK_242X),
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 05:09:22 +00:00
CLK(NULL, "gpmc_fck", &gpmc_fck, CK_242X),
CLK(NULL, "sdma_fck", &sdma_fck, CK_242X),
CLK(NULL, "sdma_ick", &sdma_ick, CK_242X),
CLK(NULL, "vlynq_ick", &vlynq_ick, CK_242X),
CLK(NULL, "vlynq_fck", &vlynq_fck, CK_242X),
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 05:09:22 +00:00
CLK(NULL, "des_ick", &des_ick, CK_242X),
CLK("omap-sham", "ick", &sha_ick, CK_242X),
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 05:09:22 +00:00
CLK("omap_rng", "ick", &rng_ick, CK_242X),
CLK("omap-aes", "ick", &aes_ick, CK_242X),
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 05:09:22 +00:00
CLK(NULL, "pka_ick", &pka_ick, CK_242X),
CLK(NULL, "usb_fck", &usb_fck, CK_242X),
CLK("musb-hdrc", "fck", &osc_ck, CK_242X),
};
/*
* init code
*/
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 05:09:22 +00:00
int __init omap2420_clk_init(void)
{
const struct prcm_config *prcm;
struct omap_clk *c;
u32 clkrate;
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 05:09:22 +00:00
prcm_clksrc_ctrl = OMAP2420_PRCM_CLKSRC_CTRL;
cm_idlest_pll = OMAP_CM_REGADDR(PLL_MOD, CM_IDLEST);
cpu_mask = RATE_IN_242X;
rate_table = omap2420_rate_table;
clk_init(&omap2_clk_functions);
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 05:09:22 +00:00
for (c = omap2420_clks; c < omap2420_clks + ARRAY_SIZE(omap2420_clks);
c++)
clk_preinit(c->lk.clk);
osc_ck.rate = omap2_osc_clk_recalc(&osc_ck);
propagate_rate(&osc_ck);
sys_ck.rate = omap2xxx_sys_clk_recalc(&sys_ck);
propagate_rate(&sys_ck);
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 05:09:22 +00:00
for (c = omap2420_clks; c < omap2420_clks + ARRAY_SIZE(omap2420_clks);
c++) {
clkdev_add(&c->lk);
clk_register(c->lk.clk);
omap2_init_clk_clkdm(c->lk.clk);
}
/* Disable autoidle on all clocks; let the PM code enable it later */
omap_clk_disable_autoidle_all();
/* Check the MPU rate set by bootloader */
clkrate = omap2xxx_clk_get_core_rate(&dpll_ck);
for (prcm = rate_table; prcm->mpu_speed; prcm++) {
if (!(prcm->flags & cpu_mask))
continue;
if (prcm->xtal_speed != sys_ck.rate)
continue;
if (prcm->dpll_speed <= clkrate)
break;
}
curr_prcm_set = prcm;
recalculate_root_clocks();
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 05:09:22 +00:00
pr_info("Clocking rate (Crystal/DPLL/MPU): %ld.%01ld/%ld/%ld MHz\n",
(sys_ck.rate / 1000000), (sys_ck.rate / 100000) % 10,
(dpll_ck.rate / 1000000), (mpu_ck.rate / 1000000)) ;
/*
* Only enable those clocks we will need, let the drivers
* enable other clocks as necessary
*/
clk_enable_init_clocks();
/* Avoid sleeping sleeping during omap2_clk_prepare_for_reboot() */
vclk = clk_get(NULL, "virt_prcm_set");
sclk = clk_get(NULL, "sys_ck");
dclk = clk_get(NULL, "dpll_ck");
return 0;
}