Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi Paul,
So why should getting rid of some *unused* data have any testing
overhead?
Your definition of 'unused' seems to be different than mine:
$ egrep -rn 'c(lk|)-clkdm' arch/arm/
arch/arm/mach-omap2/omap_hwmod.c:560: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
arch/arm/mach-omap2/omap_hwmod.c:563: return clkdm_add_sleepdep(oh-_clk-clkdm,
init_oh-_clk-clkdm);
arch/arm/mach-omap2/omap_hwmod.c:584: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
arch/arm/mach-omap2/omap_hwmod.c:587: return clkdm_del_sleepdep(oh-_clk-clkdm,
init_oh-_clk-clkdm);
I did have a look at these (which are part of _add/_del_initiator_dep()
functions) while I was working on $SUBJECT patch, and was not very sure
of what these functions are expected to do.
They check for a CLKDM_NO_AUTODEPS flag which is not defined across any
clockdomain data files across any OMAP2+ platform.
What it then means is they add a sleep/static dependency for the
modules/hwmods clkdm with mpu on *all* platforms.
The AUTODEPS on the other hand are needed only on OMAP3 I guess, and
AUTODEPS need a sleep/wakeup (Not just a sleep dependency that
the above functions add) dependency not just with MPU but also with
DSP, besides AUTODEPS are already handled very well in the clockdomain
framework for OMAP3.
arch/arm/mach-omap2/omap_hwmod.c:612: if (!oh-_clk-clkdm)
arch/arm/mach-omap2/omap_hwmod.c:2998: if (!c-clkdm)
arch/arm/mach-omap2/omap_hwmod.c:3001: return c-clkdm-pwrdm.ptr;
I have fixed some of these dereferencing in hwmod to derive a clkdm/
pwrdm for a given hwmod by giving a precedence to a clkdm directly
associated with the hwmod and if missing only then looking for
something through the clk route. What I did miss is to update the
OMAP2/3 hwmod data file for some of the clks from where I was removing
the clkdm assocaitions (There are about ~10 clocks from $SUBJECT patch
which figure in hwmod data files out of the 75 from which I get rid of
the clkdms pointers)
arch/arm/mach-omap2/clock.c:96: if (!clk-clkdm_name)
arch/arm/mach-omap2/clock.c:99: clkdm = clkdm_lookup(clk-clkdm_name);
arch/arm/mach-omap2/clock.c:102: clk-name,
clk-clkdm_name);
arch/arm/mach-omap2/clock.c:103:clk-clkdm = clkdm;
arch/arm/mach-omap2/clock.c:106: clkdm %s\n, clk-name,
clk-clkdm_name);
These are part of the init code to resolve clkdm_name into a clkdm
pointer.
arch/arm/mach-omap2/clock.c:292:if (clkdm_control clk-clkdm)
arch/arm/mach-omap2/clock.c:293:clkdm_clk_disable(clk-clkdm,
clk);
arch/arm/mach-omap2/clock.c:332:if (clkdm_control clk-clkdm) {
arch/arm/mach-omap2/clock.c:333:ret =
clkdm_clk_enable(clk-clkdm, clk);
arch/arm/mach-omap2/clock.c:336: %d\n, clk-name,
clk-clkdm-name, ret);
arch/arm/mach-omap2/clock.c:354:if (clkdm_control clk-clkdm)
arch/arm/mach-omap2/clock.c:355:clkdm_clk_disable(clk-clkdm,
clk);
These are only applicable for gate clocks.
arch/arm/mach-omap2/clock.c:441:if (clk-clkdm != NULL)
arch/arm/mach-omap2/clock.c:442:
pwrdm_state_switch(clk-clkdm-pwrdm.ptr);
This again part of disable unused clocks should also matter only for
gate clocks.
That is just the result of a casual grep, not even a code analysis.
Removing this data is not like removing some macros where one can get a
compiler error if they turn out to be needed. Problems with this ares
only likely to show up at runtime.
By the way, I hope you're testing the patches that you send to the lists,
at the very least to the minimal PM testing that I do that is documented
e.g. here:
http://www.pwsan.com/omap/bootlogs/20120508/prcm_devel_a_3.5__0135f6a04642c192bdf4b36e06937d3387e174ff/
yes, I am, atleast with the platforms that I have access to,
2430sdp/N800/3430sdp/3630beagle-xm/4430panda/4460panda.
I don't have any 35xxevm/3517evm/5912osk or cmt3517 platforms.
regards,
Rajendra
Otherwise the testing burden is just getting pushed to other people who
already have too much to do.
...
So to repeat myself on this:
1. The patch that removes some of the struct clk clkdm_name strings should
be part of or otherwise grouped with the CCF conversion patch series
2. The CCF conversion patch series needs to be fully PM-tested
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi On Thu, 7 Jun 2012, Rajendra Nayak wrote: Yes, I can include this as part of the common clock conversion series. What I was trying to say is that neither the clock framework not any other OMAP PM layer today makes any use of this information except for gate clocks. The only 2 places in the clock framework this is used is in omap2_dflt_clk_enable()/omap2_dflt_clk_disable() functions, which are nops for non gate clocks. So I don;t fully understand what you mean by our current low-level PM design being based on this assumption that every clock belongs to a clockdomain. Did I miss anything else our PM frameworks do with the clock-clkdm association? The reason I am asking is because I am doing a lot of changes around based on this assumption and would really like to know if I am missing something. Well I guess the best thing to do is for you to do PM tests with the converted code and data to make sure it works. That's what I'm worried most about right now for the CCF conversion; it's the most time-consuming part of what I do. If the conversion works without them and everything is relatively clean then I probably won't have many issues with it. ... BTW, just to continue on the clk-clkdm topic: while we might be able to get rid of the clk-clkdm association for OMAP4 soon, and maybe someday for OMAP2/3, it looks like we'll need to keep it around for at least one AM335x clock -- this CLKDIV32K clock. Definitely something to keep in mind... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi Paul, On Friday 08 June 2012 01:10 PM, Paul Walmsley wrote: Hi On Thu, 7 Jun 2012, Rajendra Nayak wrote: Yes, I can include this as part of the common clock conversion series. What I was trying to say is that neither the clock framework not any other OMAP PM layer today makes any use of this information except for gate clocks. The only 2 places in the clock framework this is used is in omap2_dflt_clk_enable()/omap2_dflt_clk_disable() functions, which are nops for non gate clocks. So I don;t fully understand what you mean by our current low-level PM design being based on this assumption that every clock belongs to a clockdomain. Did I miss anything else our PM frameworks do with the clock-clkdm association? The reason I am asking is because I am doing a lot of changes around based on this assumption and would really like to know if I am missing something. Well I guess the best thing to do is for you to do PM tests with the converted code and data to make sure it works. That's what I'm worried most about right now for the CCF conversion; it's the most time-consuming part of what I do. If the conversion works without them and everything is relatively clean then I probably won't have many issues with it. The more I read your response, the more I feel you have mistaken what this patch is doing and what I am proposing. This patch only gets rid of clkdm assocation from *non gate* clocks. And what I am trying to say is that, this information in not used at all (for non gate clocks) in any of the frameworks today including clock framework. So why should getting rid of some *unused* data have any testing overhead? I did propose sometime back about getting rid of *all* clk- clkdm assocation for OMAP2/3 and my testing also showed some positive results, but that was just preliminary testing and I know to be able to do that we need to much more testing, so thats definitely not what I am doing here. All the gate clocks still have the clk-clkdm association. Even if you look at my common clk conversion series, I have retained all clk-clkdm associations for all gate clocks across OMAP2 and OMAP3. For any other form of clock it was never used and hence I am getting rid of them. regards, Rajendra ... BTW, just to continue on the clk-clkdm topic: while we might be able to get rid of the clk-clkdm association for OMAP4 soon, and maybe someday for OMAP2/3, it looks like we'll need to keep it around for at least one AM335x clock -- this CLKDIV32K clock. Definitely something to keep in mind... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
On Fri, 8 Jun 2012, Rajendra Nayak wrote:
This patch only gets rid of clkdm assocation from *non gate* clocks.
And what I am trying to say is that, this information in not
used at all (for non gate clocks) in any of the frameworks today
including clock framework.
So why should getting rid of some *unused* data have any testing
overhead?
Your definition of 'unused' seems to be different than mine:
$ egrep -rn 'c(lk|)-clkdm' arch/arm/
arch/arm/mach-omap2/omap_hwmod.c:560: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
arch/arm/mach-omap2/omap_hwmod.c:563: return
clkdm_add_sleepdep(oh-_clk-clkdm, init_oh-_clk-clkdm);
arch/arm/mach-omap2/omap_hwmod.c:584: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
arch/arm/mach-omap2/omap_hwmod.c:587: return
clkdm_del_sleepdep(oh-_clk-clkdm, init_oh-_clk-clkdm);
arch/arm/mach-omap2/omap_hwmod.c:612: if (!oh-_clk-clkdm)
arch/arm/mach-omap2/omap_hwmod.c:2998: if (!c-clkdm)
arch/arm/mach-omap2/omap_hwmod.c:3001: return c-clkdm-pwrdm.ptr;
arch/arm/mach-omap2/clock.c:96: if (!clk-clkdm_name)
arch/arm/mach-omap2/clock.c:99: clkdm = clkdm_lookup(clk-clkdm_name);
arch/arm/mach-omap2/clock.c:102: clk-name,
clk-clkdm_name);
arch/arm/mach-omap2/clock.c:103:clk-clkdm = clkdm;
arch/arm/mach-omap2/clock.c:106: clkdm %s\n,
clk-name, clk-clkdm_name);
arch/arm/mach-omap2/clock.c:292:if (clkdm_control clk-clkdm)
arch/arm/mach-omap2/clock.c:293:clkdm_clk_disable(clk-clkdm,
clk);
arch/arm/mach-omap2/clock.c:332:if (clkdm_control clk-clkdm) {
arch/arm/mach-omap2/clock.c:333:ret =
clkdm_clk_enable(clk-clkdm, clk);
arch/arm/mach-omap2/clock.c:336: %d\n, clk-name,
clk-clkdm-name, ret);
arch/arm/mach-omap2/clock.c:354:if (clkdm_control clk-clkdm)
arch/arm/mach-omap2/clock.c:355:clkdm_clk_disable(clk-clkdm,
clk);
arch/arm/mach-omap2/clock.c:441:if (clk-clkdm != NULL)
arch/arm/mach-omap2/clock.c:442:
pwrdm_state_switch(clk-clkdm-pwrdm.ptr);
That is just the result of a casual grep, not even a code analysis.
Removing this data is not like removing some macros where one can get a
compiler error if they turn out to be needed. Problems with this ares
only likely to show up at runtime.
By the way, I hope you're testing the patches that you send to the lists,
at the very least to the minimal PM testing that I do that is documented
e.g. here:
http://www.pwsan.com/omap/bootlogs/20120508/prcm_devel_a_3.5__0135f6a04642c192bdf4b36e06937d3387e174ff/
Otherwise the testing burden is just getting pushed to other people who
already have too much to do.
...
So to repeat myself on this:
1. The patch that removes some of the struct clk clkdm_name strings should
be part of or otherwise grouped with the CCF conversion patch series
2. The CCF conversion patch series needs to be fully PM-tested
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi Paul,
On Thursday 17 May 2012 03:54 PM, Rajendra Nayak wrote:
clkdm assocations with clocks in the clock framework are useful
only for 'gate' clocks which have enable/disable ops populated.
Get rid of the clkdm_names populated in any other type of clocks.
Any comments on this one?
regards,
Rajendra
Signed-off-by: Rajendra Nayakrna...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 16
arch/arm/mach-omap2/clock2430_data.c | 15 ---
arch/arm/mach-omap2/clock3xxx_data.c | 44 --
3 files changed, 0 insertions(+), 75 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index bace930..914d12a 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -56,14 +56,12 @@ static struct clk func_32k_ck = {
.name = func_32k_ck,
.ops=clkops_null,
.rate = 32768,
- .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 */
@@ -79,7 +77,6 @@ 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,
};
@@ -87,7 +84,6 @@ static struct clk alt_ck = { /* Typical 54M or 48M,
may not exist */
.name = alt_ck,
.ops=clkops_null,
.rate = 5400,
- .clkdm_name = wkup_clkdm,
};
/* Optional external clock input for McBSP CLKS */
@@ -180,7 +176,6 @@ 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,
@@ -192,7 +187,6 @@ 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,
};
@@ -200,7 +194,6 @@ static struct clk func_96m_ck = {
.name = func_96m_ck,
.ops=clkops_null,
.parent =apll96_ck,
- .clkdm_name = wkup_clkdm,
.recalc =followparent_recalc,
};
@@ -226,7 +219,6 @@ 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,
@@ -241,7 +233,6 @@ static struct clk func_12m_ck = {
.ops=clkops_null,
.parent =func_48m_ck,
.fixed_div = 4,
- .clkdm_name = wkup_clkdm,
.recalc =omap_fixed_divisor_recalc,
};
@@ -323,7 +314,6 @@ static struct clk sys_clkout = {
.name = sys_clkout,
.ops=clkops_null,
.parent =sys_clkout_src,
- .clkdm_name = wkup_clkdm,
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask= OMAP24XX_CLKOUT_DIV_MASK,
.clksel = sys_clkout_clksel,
@@ -359,7 +349,6 @@ static struct clk sys_clkout2 = {
.name = sys_clkout2,
.ops=clkops_null,
.parent =sys_clkout2_src,
- .clkdm_name = wkup_clkdm,
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask= OMAP2420_CLKOUT2_DIV_MASK,
.clksel = sys_clkout2_clksel,
@@ -407,7 +396,6 @@ 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,
@@ -541,7 +529,6 @@ 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
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi On Thu, 7 Jun 2012, Rajendra Nayak wrote: On Thursday 17 May 2012 03:54 PM, Rajendra Nayak wrote: clkdm assocations with clocks in the clock framework are useful only for 'gate' clocks which have enable/disable ops populated. Get rid of the clkdm_names populated in any other type of clocks. I don't really see the point in changing this before the common clock conversion. The design of most of the current low-level OMAP PM layers was predicated on each clock belonging to a clockdomain. The testing overhead of changing this before the common clock conversion is something that I don't have time for, and almost no one else seems interested in doing. Your common clock conversion moots this patch anyway, right? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi Paul, On Thursday 07 June 2012 12:37 PM, Paul Walmsley wrote: Hi On Thu, 7 Jun 2012, Rajendra Nayak wrote: On Thursday 17 May 2012 03:54 PM, Rajendra Nayak wrote: clkdm assocations with clocks in the clock framework are useful only for 'gate' clocks which have enable/disable ops populated. Get rid of the clkdm_names populated in any other type of clocks. I don't really see the point in changing this before the common clock conversion. The design of most of the current low-level OMAP PM layers was predicated on each clock belonging to a clockdomain. The testing overhead of changing this before the common clock conversion is something that I don't have time for, and almost no one else seems interested in doing. Your common clock conversion moots this patch anyway, right? Yes, I can include this as part of the common clock conversion series. What I was trying to say is that neither the clock framework not any other OMAP PM layer today makes any use of this information except for gate clocks. The only 2 places in the clock framework this is used is in omap2_dflt_clk_enable()/omap2_dflt_clk_disable() functions, which are nops for non gate clocks. So I don;t fully understand what you mean by our current low-level PM design being based on this assumption that every clock belongs to a clockdomain. Did I miss anything else our PM frameworks do with the clock-clkdm association? The reason I am asking is because I am doing a lot of changes around based on this assumption and would really like to know if I am missing something. regards, Rajendra - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
clkdm assocations with clocks in the clock framework are useful
only for 'gate' clocks which have enable/disable ops populated.
Get rid of the clkdm_names populated in any other type of clocks.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 16
arch/arm/mach-omap2/clock2430_data.c | 15 ---
arch/arm/mach-omap2/clock3xxx_data.c | 44 --
3 files changed, 0 insertions(+), 75 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index bace930..914d12a 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -56,14 +56,12 @@ static struct clk func_32k_ck = {
.name = func_32k_ck,
.ops= clkops_null,
.rate = 32768,
- .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 */
@@ -79,7 +77,6 @@ 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,
};
@@ -87,7 +84,6 @@ static struct clk alt_ck = { /* Typical 54M or 48M,
may not exist */
.name = alt_ck,
.ops= clkops_null,
.rate = 5400,
- .clkdm_name = wkup_clkdm,
};
/* Optional external clock input for McBSP CLKS */
@@ -180,7 +176,6 @@ 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,
@@ -192,7 +187,6 @@ 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,
};
@@ -200,7 +194,6 @@ static struct clk func_96m_ck = {
.name = func_96m_ck,
.ops= clkops_null,
.parent = apll96_ck,
- .clkdm_name = wkup_clkdm,
.recalc = followparent_recalc,
};
@@ -226,7 +219,6 @@ 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,
@@ -241,7 +233,6 @@ static struct clk func_12m_ck = {
.ops= clkops_null,
.parent = func_48m_ck,
.fixed_div = 4,
- .clkdm_name = wkup_clkdm,
.recalc = omap_fixed_divisor_recalc,
};
@@ -323,7 +314,6 @@ static struct clk sys_clkout = {
.name = sys_clkout,
.ops= clkops_null,
.parent = sys_clkout_src,
- .clkdm_name = wkup_clkdm,
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask= OMAP24XX_CLKOUT_DIV_MASK,
.clksel = sys_clkout_clksel,
@@ -359,7 +349,6 @@ static struct clk sys_clkout2 = {
.name = sys_clkout2,
.ops= clkops_null,
.parent = sys_clkout2_src,
- .clkdm_name = wkup_clkdm,
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask= OMAP2420_CLKOUT2_DIV_MASK,
.clksel = sys_clkout2_clksel,
@@ -407,7 +396,6 @@ 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,
@@ -541,7 +529,6 @@ 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,
@@ -597,7 +584,6 @@ static struct clk l4_ck = { /* used both as an
