Re: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
> Actually, system boots. It does not break the system. What I've tried is: > > - rx51 board > - omap3_pm_defconfig without CPU_FREQ > - linux-omap-pm/pm-wip-opp branch + this patch > > System boots, but smartreflex disables itself: > > ... > TCP cubic registered > NET: Registered protocol family 17 > NET: Registered protocol family 15 > Power Management for TI OMAP3. > SR: OPP rate tables not defined for platform, not enabling SmartReflex > VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 > ,.. > > But it does not break booting procedure. > > So, I don't see why this would be a reason for doing this compilation fix > into two steps. Unless you see another issue. Ok sorry about the misunderstanding then. Its ok from my side. ACKed. -- 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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 01:54:30PM +0100, ext Romit Dasgupta wrote:
> Eduardo Valentin wrote:
> > On Wed, Jan 20, 2010 at 01:44:31PM +0100, ext Romit Dasgupta wrote:
> >> Eduardo Valentin wrote:
> >>> On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote:
> Eduardo Valentin wrote:
> > On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote:
> >>> From: Eduardo Valentin
> >>>
> >>> OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ
> >>> only.
> >>>
> >>> With this patch, omap opp layer now has its compilation flags
> >>> bound to CONFIG_CPU_FREQ. Also its code has been removed from
> >>> pm34xx.c.
> >>>
> >>> A new file has been created to contain cpu freq code related to
> >>> OMAP3: cpufreq34xx.c.
> >>>
> >>> Signed-off-by: Eduardo Valentin
> >> NAK also for the following non-working kernel (smartreflex without
> >> cpufreq).
> > Then this is a problem of dependency with smartreflex and cpufreq. In
> > this case
> > better to solve this other problem with another patch. This patch is to
> > rip off
> > cpufreq code from pm34xx, as stated in the above description.
> In that case the right fix should
> >>> OK
> >>>
> 1) __not__ include opp.h for non cpufreq builds
> >>> I guess the patch is "more or less" this option, as it maps
> >>> all functions inside opp.h to nops if it is a cpufreq build.
> >>> And all related real code is not compiled.
> >>>
> >>> Basically removes the opp layer code if cpufreq is disabled.
> >>>
> >> IMHO, making functions return 0 will give you run time issues when opp
> >> related
> >> APIs are called in non cpufreq path. So your patch will for the time being
> >> solve
> >> the build issue but not runtime issue. Hence I suggested to compile out
> >> opp.h if
> >> you are not using cpufreq. Solving a build issue is not the right fix for
> >> this.
> >
> > No, they are cleaned up by compiler. The following:
> >
> > +static inline unsigned long omap_twl_vsel_to_uv(const u8 vsel)
> > +{
> > + return 0;
> > +}
> >
> > will be translated to a nop in final kernel image.
> >
> > That's the whole idea of this patch.
> >
> >
>
> Ok, what I mean is that it still solves build issue only. It does not produce
> a
> bootable kernel without CPU_FREQ but with SMARTREFLEX. Smartreflex is almost
> always there for a OMAP kernel. It is not a rarely used feature. So this patch
> should have another part that fixes the Smartreflex issue!
Actually, system boots. It does not break the system. What I've tried is:
- rx51 board
- omap3_pm_defconfig without CPU_FREQ
- linux-omap-pm/pm-wip-opp branch + this patch
System boots, but smartreflex disables itself:
...
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
Power Management for TI OMAP3.
SR: OPP rate tables not defined for platform, not enabling SmartReflex
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
,..
But it does not break booting procedure.
So, I don't see why this would be a reason for doing this compilation fix
into two steps. Unless you see another issue.
BR,
--
Eduardo Valentin
--
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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
Eduardo Valentin wrote:
> On Wed, Jan 20, 2010 at 01:44:31PM +0100, ext Romit Dasgupta wrote:
>> Eduardo Valentin wrote:
>>> On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
> On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote:
>>> From: Eduardo Valentin
>>>
>>> OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only.
>>>
>>> With this patch, omap opp layer now has its compilation flags
>>> bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c.
>>>
>>> A new file has been created to contain cpu freq code related to
>>> OMAP3: cpufreq34xx.c.
>>>
>>> Signed-off-by: Eduardo Valentin
>> NAK also for the following non-working kernel (smartreflex without
>> cpufreq).
> Then this is a problem of dependency with smartreflex and cpufreq. In
> this case
> better to solve this other problem with another patch. This patch is to
> rip off
> cpufreq code from pm34xx, as stated in the above description.
In that case the right fix should
>>> OK
>>>
1) __not__ include opp.h for non cpufreq builds
>>> I guess the patch is "more or less" this option, as it maps
>>> all functions inside opp.h to nops if it is a cpufreq build.
>>> And all related real code is not compiled.
>>>
>>> Basically removes the opp layer code if cpufreq is disabled.
>>>
>> IMHO, making functions return 0 will give you run time issues when opp
>> related
>> APIs are called in non cpufreq path. So your patch will for the time being
>> solve
>> the build issue but not runtime issue. Hence I suggested to compile out
>> opp.h if
>> you are not using cpufreq. Solving a build issue is not the right fix for
>> this.
>
> No, they are cleaned up by compiler. The following:
>
> +static inline unsigned long omap_twl_vsel_to_uv(const u8 vsel)
> +{
> + return 0;
> +}
>
> will be translated to a nop in final kernel image.
>
> That's the whole idea of this patch.
>
>
Ok, what I mean is that it still solves build issue only. It does not produce a
bootable kernel without CPU_FREQ but with SMARTREFLEX. Smartreflex is almost
always there for a OMAP kernel. It is not a rarely used feature. So this patch
should have another part that fixes the Smartreflex issue!
--
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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 01:44:31PM +0100, ext Romit Dasgupta wrote:
> Eduardo Valentin wrote:
> > On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote:
> >> Eduardo Valentin wrote:
> >>> On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote:
> > From: Eduardo Valentin
> >
> > OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only.
> >
> > With this patch, omap opp layer now has its compilation flags
> > bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c.
> >
> > A new file has been created to contain cpu freq code related to
> > OMAP3: cpufreq34xx.c.
> >
> > Signed-off-by: Eduardo Valentin
> NAK also for the following non-working kernel (smartreflex without
> cpufreq).
> >>> Then this is a problem of dependency with smartreflex and cpufreq. In
> >>> this case
> >>> better to solve this other problem with another patch. This patch is to
> >>> rip off
> >>> cpufreq code from pm34xx, as stated in the above description.
> >> In that case the right fix should
> >
> > OK
> >
> >> 1) __not__ include opp.h for non cpufreq builds
> >
> > I guess the patch is "more or less" this option, as it maps
> > all functions inside opp.h to nops if it is a cpufreq build.
> > And all related real code is not compiled.
> >
> > Basically removes the opp layer code if cpufreq is disabled.
> >
> IMHO, making functions return 0 will give you run time issues when opp related
> APIs are called in non cpufreq path. So your patch will for the time being
> solve
> the build issue but not runtime issue. Hence I suggested to compile out opp.h
> if
> you are not using cpufreq. Solving a build issue is not the right fix for
> this.
No, they are cleaned up by compiler. The following:
+static inline unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+ return 0;
+}
will be translated to a nop in final kernel image.
That's the whole idea of this patch.
--
Eduardo Valentin
--
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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
Eduardo Valentin wrote: > On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote: >> Eduardo Valentin wrote: >>> On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote: > From: Eduardo Valentin > > OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. > > With this patch, omap opp layer now has its compilation flags > bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. > > A new file has been created to contain cpu freq code related to > OMAP3: cpufreq34xx.c. > > Signed-off-by: Eduardo Valentin NAK also for the following non-working kernel (smartreflex without cpufreq). >>> Then this is a problem of dependency with smartreflex and cpufreq. In this >>> case >>> better to solve this other problem with another patch. This patch is to rip >>> off >>> cpufreq code from pm34xx, as stated in the above description. >> In that case the right fix should > > OK > >> 1) __not__ include opp.h for non cpufreq builds > > I guess the patch is "more or less" this option, as it maps > all functions inside opp.h to nops if it is a cpufreq build. > And all related real code is not compiled. > > Basically removes the opp layer code if cpufreq is disabled. > IMHO, making functions return 0 will give you run time issues when opp related APIs are called in non cpufreq path. So your patch will for the time being solve the build issue but not runtime issue. Hence I suggested to compile out opp.h if you are not using cpufreq. Solving a build issue is not the right fix for this. -- 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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote:
> Eduardo Valentin wrote:
> > On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote:
> >>> From: Eduardo Valentin
> >>>
> >>> OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only.
> >>>
> >>> With this patch, omap opp layer now has its compilation flags
> >>> bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c.
> >>>
> >>> A new file has been created to contain cpu freq code related to
> >>> OMAP3: cpufreq34xx.c.
> >>>
> >>> Signed-off-by: Eduardo Valentin
> >> NAK also for the following non-working kernel (smartreflex without
> >> cpufreq).
> >
> > Then this is a problem of dependency with smartreflex and cpufreq. In this
> > case
> > better to solve this other problem with another patch. This patch is to rip
> > off
> > cpufreq code from pm34xx, as stated in the above description.
>
> In that case the right fix should
OK
>
> 1) __not__ include opp.h for non cpufreq builds
I guess the patch is "more or less" this option, as it maps
all functions inside opp.h to nops if it is a cpufreq build.
And all related real code is not compiled.
Basically removes the opp layer code if cpufreq is disabled.
One thing I forgot to add here was this part:
diff --git a/arch/arm/plat-omap/include/plat/opp_twl_tps.h
b/arch/arm/plat-omap/include/plat/opp
index 8784e5f..0460ca8 100644
--- a/arch/arm/plat-omap/include/plat/opp_twl_tps.h
+++ b/arch/arm/plat-omap/include/plat/opp_twl_tps.h
@@ -15,7 +15,16 @@
#include
+#ifdef CONFIG_CPU_FREQ
unsigned long omap_twl_vsel_to_uv(const u8 vsel);
u8 omap_twl_uv_to_vsel(unsigned long uV);
+#else
+static inline unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+}
+static inline u8 omap_twl_uv_to_vsel(unsigned long uV)
+{
+}
+#endif
> OR
> 2) If it includes opp.h the functions for getting current opp
> should abstract out the right mechanism to get current frequency/voltage from
> the chip/power IC.
I guess this looks as good way to do it. But the patch I sent is more like the
first
option and fixes the compilation issue.
>
> >
> > And sorry, I didn't get your boot log (if you intended to put it, as you
> > said
> > "following non-working kernel"
> >
> Actually I meant for the following non-working kernel __configuration__. I do
> not have boot logs!
Ahh. right! No I see. Yeah, as mention in other thread, the patch is meant to
fix that one.
--
Eduardo Valentin
--
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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
Eduardo Valentin wrote: > On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote: >>> From: Eduardo Valentin >>> >>> OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. >>> >>> With this patch, omap opp layer now has its compilation flags >>> bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. >>> >>> A new file has been created to contain cpu freq code related to >>> OMAP3: cpufreq34xx.c. >>> >>> Signed-off-by: Eduardo Valentin >> NAK also for the following non-working kernel (smartreflex without cpufreq). > > Then this is a problem of dependency with smartreflex and cpufreq. In this > case > better to solve this other problem with another patch. This patch is to rip > off > cpufreq code from pm34xx, as stated in the above description. In that case the right fix should 1) __not__ include opp.h for non cpufreq builds OR 2) If it includes opp.h the functions for getting current opp should abstract out the right mechanism to get current frequency/voltage from the chip/power IC. > > And sorry, I didn't get your boot log (if you intended to put it, as you said > "following non-working kernel" > Actually I meant for the following non-working kernel __configuration__. I do not have boot logs! -- 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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote: > > > From: Eduardo Valentin > > > > OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. > > > > With this patch, omap opp layer now has its compilation flags > > bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. > > > > A new file has been created to contain cpu freq code related to > > OMAP3: cpufreq34xx.c. > > > > Signed-off-by: Eduardo Valentin > NAK also for the following non-working kernel (smartreflex without cpufreq). Then this is a problem of dependency with smartreflex and cpufreq. In this case better to solve this other problem with another patch. This patch is to rip off cpufreq code from pm34xx, as stated in the above description. And sorry, I didn't get your boot log (if you intended to put it, as you said "following non-working kernel" BR, -- Eduardo Valentin -- 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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
>>> Signed-off-by: Eduardo Valentin >>> --- >>> arch/arm/mach-omap2/Makefile |5 + >> NAK. Your kernel will not boot if you build it without CONFIG_CPU_FREQ. > > I guess you mean without CONFIG_CPU_FREQ and SMART_REFLEX > Just without CONFIG_CPU_FREQ. Did it boot? -- 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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 12:13:17PM +0100, ext Romit Dasgupta wrote: > > From: Eduardo Valentin > > > > OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. > > > > With this patch, omap opp layer now has its compilation flags > > bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. > > > > A new file has been created to contain cpu freq code related to > > OMAP3: cpufreq34xx.c. > > > > Signed-off-by: Eduardo Valentin > > --- > > arch/arm/mach-omap2/Makefile |5 + > NAK. Your kernel will not boot if you build it without CONFIG_CPU_FREQ. I guess you mean without CONFIG_CPU_FREQ and SMART_REFLEX -- Eduardo Valentin -- 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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
> From: Eduardo Valentin > > OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. > > With this patch, omap opp layer now has its compilation flags > bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. > > A new file has been created to contain cpu freq code related to > OMAP3: cpufreq34xx.c. > > Signed-off-by: Eduardo Valentin NAK also for the following non-working kernel (smartreflex without cpufreq). -- 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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
> From: Eduardo Valentin > > OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. > > With this patch, omap opp layer now has its compilation flags > bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. > > A new file has been created to contain cpu freq code related to > OMAP3: cpufreq34xx.c. > > Signed-off-by: Eduardo Valentin > --- > arch/arm/mach-omap2/Makefile |5 + NAK. Your kernel will not boot if you build it without CONFIG_CPU_FREQ. -- 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
[PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
From: Eduardo Valentin
OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only.
With this patch, omap opp layer now has its compilation flags
bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c.
A new file has been created to contain cpu freq code related to
OMAP3: cpufreq34xx.c.
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/Makefile |5 +
arch/arm/mach-omap2/cpufreq34xx.c | 133 ++
arch/arm/mach-omap2/omap3-opp.h | 13 +++
arch/arm/mach-omap2/pm.h |6 --
arch/arm/mach-omap2/pm34xx.c | 105
arch/arm/plat-omap/Makefile |2 +
arch/arm/plat-omap/include/plat/opp.h | 145 +
7 files changed, 263 insertions(+), 146 deletions(-)
create mode 100644 arch/arm/mach-omap2/cpufreq34xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4ca93f1..22f2afd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -42,6 +42,11 @@ obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += smartreflex.o
endif
+# CPU Frequency
+ifeq ($(CONFIG_CPU_FREQ),y)
+obj-$(CONFIG_ARCH_OMAP3) += cpufreq34xx.o
+endif
+
# PRCM
obj-$(CONFIG_ARCH_OMAP2) += cm.o
obj-$(CONFIG_ARCH_OMAP3) += cm.o
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
new file mode 100644
index 000..07873e8
--- /dev/null
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -0,0 +1,133 @@
+/*
+ * arch/arm/mach-omap2/cpufreq34xx.c
+ * OMAP3 resource init/change_level/validate_level functions
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ *
+ * 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.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ * History:
+ *
+ */
+
+#include
+#include
+
+#include
+#include
+
+static struct omap_opp_def __initdata omap34xx_mpu_rate_table[] = {
+ /* OPP1 */
+ OMAP_OPP_DEF(true, 12500, 975000),
+ /* OPP2 */
+ OMAP_OPP_DEF(true, 25000, 1075000),
+ /* OPP3 */
+ OMAP_OPP_DEF(true, 5, 120),
+ /* OPP4 */
+ OMAP_OPP_DEF(true, 55000, 127),
+ /* OPP5 */
+ OMAP_OPP_DEF(true, 6, 135),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap34xx_l3_rate_table[] = {
+ /* OPP1 */
+ OMAP_OPP_DEF(false, 0, 975000),
+ /* OPP2 */
+ OMAP_OPP_DEF(true, 8300, 105),
+ /* OPP3 */
+ OMAP_OPP_DEF(true, 16600, 115),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap34xx_dsp_rate_table[] = {
+ /* OPP1 */
+ OMAP_OPP_DEF(true, 9000, 975000),
+ /* OPP2 */
+ OMAP_OPP_DEF(true, 18000, 1075000),
+ /* OPP3 */
+ OMAP_OPP_DEF(true, 36000, 120),
+ /* OPP4 */
+ OMAP_OPP_DEF(true, 4, 127),
+ /* OPP5 */
+ OMAP_OPP_DEF(true, 43000, 135),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 3, 93),
+ /* OPP2 - OPP100 */
+ OMAP_OPP_DEF(true, 6, 110),
+ /* OPP3 - OPP-Turbo */
+ OMAP_OPP_DEF(false, 8, 126),
+ /* OPP4 - OPP-SB */
+ OMAP_OPP_DEF(false, 10, 131),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 1, 93),
+ /* OPP2 - OPP100, OPP-Turbo, OPP-SB */
+ OMAP_OPP_DEF(true, 2, 1137500),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 26000, 93),
+ /* OPP2 - OPP100 */
+ OMAP_OPP_DEF(true, 52000, 110),
+ /* OPP3 - OPP-Turbo */
+ OMAP_OPP_DEF(false, 66000, 126),
+ /* OPP4 - OPP-SB */
+ OMAP_OPP_DEF(false, 87500, 131),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+void __init omap3_pm_init_opp_table(void)
+{
+ int i;
+ struct omap_opp_def **omap3_opp_def_list;
+ struct omap_opp_def *o
