Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
"Shilimkar, Santosh" writes: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of Menon, Nishanth >> Sent: Thursday, September 16, 2010 10:40 PM >> To: Linus Walleij >> Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm- >> ker...@lists.infradead.org >> Subject: Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific >> OPPs >> >> Linus Walleij had written, on 09/16/2010 12:07 PM, the following: >> > 2010/9/16 Kevin Hilman : >> > >> >> lib/opp/* seems more appropriate to me with the header at >> >> include/linux/opp.h as Linus suggested. >> > >> > I second this. I would love to see the generic OPP stuff in >> > lib/opp/* so we put it in the right place from the beginning and >> > don't have to painfully refactor everything later (clk.h >> > especially comes to mind.) >> cool.. digging a bit deeper into lib directory, I propose the following: >> lib/opp.c >> include/linux/opp.h >> >> any soc specific data (for registration etc) -> goes to >> arch//mach-/oppdata_xyz.c or what ever they choose >> >> the intent being lib/ is no place to put mach or arch specific data >> definitions.. it is just noise.. >> >> if folks are ok with this, will post a new rev soonish.. >> > If you like may be you can take this thread over lkml just to get more > wider perspective I propose Nishanth does the slight rework to move this to lib/ and then post to l-o, l-a-k and lkml for RFC. Note that only the generic parts should be posted first, the OMAP specific usage of this can be fixed after the generic parts are accepted. Kevin -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > Sent: Thursday, September 16, 2010 10:40 PM > To: Linus Walleij > Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific > OPPs > > Linus Walleij had written, on 09/16/2010 12:07 PM, the following: > > 2010/9/16 Kevin Hilman : > > > >> lib/opp/* seems more appropriate to me with the header at > >> include/linux/opp.h as Linus suggested. > > > > I second this. I would love to see the generic OPP stuff in > > lib/opp/* so we put it in the right place from the beginning and > > don't have to painfully refactor everything later (clk.h > > especially comes to mind.) > cool.. digging a bit deeper into lib directory, I propose the following: > lib/opp.c > include/linux/opp.h > > any soc specific data (for registration etc) -> goes to > arch//mach-/oppdata_xyz.c or what ever they choose > > the intent being lib/ is no place to put mach or arch specific data > definitions.. it is just noise.. > > if folks are ok with this, will post a new rev soonish.. > If you like may be you can take this thread over lkml just to get more wider perspective -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
Linus Walleij had written, on 09/16/2010 12:07 PM, the following: 2010/9/16 Kevin Hilman : lib/opp/* seems more appropriate to me with the header at include/linux/opp.h as Linus suggested. I second this. I would love to see the generic OPP stuff in lib/opp/* so we put it in the right place from the beginning and don't have to painfully refactor everything later (clk.h especially comes to mind.) cool.. digging a bit deeper into lib directory, I propose the following: lib/opp.c include/linux/opp.h any soc specific data (for registration etc) -> goes to arch//mach-/oppdata_xyz.c or what ever they choose the intent being lib/ is no place to put mach or arch specific data definitions.. it is just noise.. if folks are ok with this, will post a new rev soonish.. -- Regards, Nishanth Menon -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
2010/9/16 Kevin Hilman : > lib/opp/* seems more appropriate to me with the header at > include/linux/opp.h as Linus suggested. I second this. I would love to see the generic OPP stuff in lib/opp/* so we put it in the right place from the beginning and don't have to painfully refactor everything later (clk.h especially comes to mind.) Yours, Linus Walleij -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
Nishanth Menon writes: > Kevin Hilman had written, on 09/16/2010 10:08 AM, the following: > [..] >>> more than that you name >>> some functions omap_*, and how hard would it be to put it under >>> arch/arm/common/*.c >>> arch/arm/include/asm/*.h >>> >>> Possible even higher up in the directory hiearchy in include/linux/opp.h >>> for the header and drivers/opp/*.c, because I think SuperH and power >>> are not that different in this respect. >> >> Yeah, I guess this isn't ARM specific either, so should be at a higher >> level. >> >> Nishanth, can take my hack below and continue this evolution? As I >> demonstrate with this hack, this won't really change anything for us. > > thanks.. The only contention ahead is: where do we want this? > Is drivers/opp/opp_core.c the right place? Given that this is just a > support library and not really a driver? for some reason lib/opp.c > does'nt sound just right either :( Well, since it's not really a driver, I don't think drivers/* is appropriate. lib/opp/* seems more appropriate to me with the header at include/linux/opp.h as Linus suggested. Kevin -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
Kevin Hilman had written, on 09/16/2010 10:08 AM, the following: [..] more than that you name some functions omap_*, and how hard would it be to put it under arch/arm/common/*.c arch/arm/include/asm/*.h Possible even higher up in the directory hiearchy in include/linux/opp.h for the header and drivers/opp/*.c, because I think SuperH and power are not that different in this respect. Yeah, I guess this isn't ARM specific either, so should be at a higher level. Nishanth, can take my hack below and continue this evolution? As I demonstrate with this hack, this won't really change anything for us. thanks.. The only contention ahead is: where do we want this? Is drivers/opp/opp_core.c the right place? Given that this is just a support library and not really a driver? for some reason lib/opp.c does'nt sound just right either :( [..] -- Regards, Nishanth Menon -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
Hi Linus,
Linus Walleij writes:
> 2010/9/15 Kevin Hilman :
>
>> OMAP SOCs have a standard set of tuples consisting of frequency and
>> voltage pairs that the device will support per voltage domain. These
>> are called Operating Performance Points or OPPs.
>> (...)
>> This introduces a common handling OPP mechanism accross all OMAPs.
>> As a start this is used for OMAP3.
>
> OPPs are a generic concept, it's in silicon construction textbooks and all.
> Should this code not be made generic instead? You wouldn't make
> regulators or even DMA platform-specific these days, so why should
> OPPs be?
You're right.
> What in this code is actually OMAP-specific
Only the users. ;)
We currently register OPPs using an OMAP hwmod name, but we could easily
change that to use a struct device instead which would make this
much more generic (note we manage OPPs per-device, not just for the CPU)
The patch below[1] demonstrates quickly how easily we could remove all OMAP
specific stuff from opp.[ch], and move it to the OMAP-specific code that
does the opp_add()
> more than that you name
> some functions omap_*, and how hard would it be to put it under
> arch/arm/common/*.c
> arch/arm/include/asm/*.h
>
> Possible even higher up in the directory hiearchy in include/linux/opp.h
> for the header and drivers/opp/*.c, because I think SuperH and power
> are not that different in this respect.
Yeah, I guess this isn't ARM specific either, so should be at a higher
level.
Nishanth, can take my hack below and continue this evolution? As I
demonstrate with this hack, this won't really change anything for us.
Kevin
>From 96c4e27ba0cb3d9a056693340c6221bc093bce2c Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Thu, 16 Sep 2010 07:58:16 -0700
Subject: [PATCH] OPP: remove OMAP specifics to make more generic
Internal OPP management is based on 'struct device *', so
we don't need to have omap_hwmod specific knowledge in this layer.
Change opp_add() to take a 'struct device *' instead of using
the OMAP hwmod in the opp_def to lookup the struct device.
Move OMAP-specific hwmod lookups into the OMAP specific layer
which adds OPPs to the database.
Quickly tested on OMAP3 to see that all OPPs are still registered
correctly with CPUfreq
---
arch/arm/mach-omap2/opp3xxx_data.c| 18 +-
arch/arm/plat-omap/include/plat/opp.h |2 +-
arch/arm/plat-omap/opp.c | 24 ++--
3 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index e337aeb..f3f9ae4 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -23,6 +23,7 @@
#include
#include
+#include
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
/* MPU OPP1 */
@@ -114,7 +115,22 @@ int __init omap3_pm_init_opp_table(void)
opp_def = omap3_opp_def_list;
for (i = 0; i < omap3_opp_def_size; i++) {
- r = opp_add(opp_def++);
+ struct omap_hwmod *oh;
+ struct device *dev;
+
+ if (!opp_def->hwmod_name) {
+ pr_err("%s: missing name of omap_hwmod, ignoring.\n",
__func__);
+ return -EINVAL;
+ }
+ oh = omap_hwmod_lookup(opp_def->hwmod_name);
+ if (!oh || !oh->od) {
+ pr_warn("%s: no hwmod or odev for %s, cannot add
OPPs.\n",
+ __func__, opp_def->hwmod_name);
+ return -EINVAL;
+ }
+ dev = &oh->od->pdev.dev;
+
+ r = opp_add(dev, opp_def++);
if (r)
pr_err("unable to add OPP %ld Hz for %s\n",
opp_def->freq, opp_def->hwmod_name);
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 9af8c83..82cfdd6 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -75,7 +75,7 @@ struct omap_opp *opp_find_freq_floor(struct device *dev,
unsigned long *freq);
struct omap_opp *opp_find_freq_ceil(struct device *dev, unsigned long *freq);
-int opp_add(const struct omap_opp_def *opp_def);
+int opp_add(struct device *dev, const struct omap_opp_def *opp_def);
int opp_enable(struct omap_opp *opp);
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index b26326b..f5295ca 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -21,7 +21,6 @@
#include
#include
-#include
/**
* struct omap_opp - OMAP OPP description structure
@@ -58,7 +57,6 @@ struct omap_opp {
struct device_opp {
struct list_head node;
- struct omap_hwmod *oh;
struct device *dev;
struct list_head opp_list;
@@ -291,29 +289,12 @@ static void omap_opp_populate(struct omap_opp *opp,
*
* This function adds an opp definition to the opp list
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Roger Quadros had written, on 09/16/2010 09:20 AM, the following:
[...]
+/**
+ * opp_get_freq() - Gets the frequency corresponding to an opp
+ * @opp: opp for which frequency has to be returned for
+ *
+ * Return frequency in hertz corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_freq(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
ditto.
Yes, the intent here was for opp operational apis to function ONLY on
the enabled opps - this helps to pull out any bugs in the users
who might be unintentionally using bad params.
OK.
do you have any usecase you can think of where we might want to use
these on a disabled opp?
Not really. Based on what is an OPP enabled/disabled? Is it possible for
an initially enabled OPP to be disabled at some point in time? What
triggers this disable?
OR does an OPP enabled at boot time remain enabled throughout the power
session?
At this point - enable/disable is done at init time - there is
flexibility for board files to define their own custom OPPs (as some
custom boards need to). they dont change once this initial definition is
done. there are plans to do dynamic enable disable based on previous
discussion in l-o - the framework to use opp layer in that manner is yet
to go up yet.
--
Regards,
Nishanth Menon
--
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 1/4] OMAP: introduce OPP layer for device-specific OPPs
On 09/16/2010 05:01 PM, ext Nishanth Menon wrote:
Roger Quadros had written, on 09/16/2010 08:54 AM, the following:
Since you are anyways re-sending this you might as well fix these nits.
thanks for reviewing..
[..]
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
new file mode 100644
index 000..17f93b2
--- /dev/null
+++ b/arch/arm/plat-omap/opp.c
@@ -0,0 +1,461 @@
+/*
+ * OMAP OPP Interface
+ *
+ * Copyright (C) 2009-2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Romit Dasgupta
+ *
+ * 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.
+ */
+
+/**
+ * opp_get_voltage() - Gets the voltage corresponding to an opp
+ * @opp: opp for which voltage has to be returned for
+ *
+ * Return voltage in micro volt corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_voltage(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
If !opp->enabled, then is it really an invalid parameter being passed?
I'm not user if people need to know the voltage of a disabled OPP, but
do we need to limit it?
+ pr_err("%s: Invalid parameters being passed\n", __func__);
+ return 0;
+ }
+
+ return opp->u_volt;
+}
+
+/**
+ * opp_get_freq() - Gets the frequency corresponding to an opp
+ * @opp: opp for which frequency has to be returned for
+ *
+ * Return frequency in hertz corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_freq(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
ditto.
Yes, the intent here was for opp operational apis to function ONLY on
the enabled opps - this helps to pull out any bugs in the users
who might be unintentionally using bad params.
OK.
do you have any usecase you can think of where we might want to use
these on a disabled opp?
Not really. Based on what is an OPP enabled/disabled? Is it possible for
an initially enabled OPP to be disabled at some point in time? What
triggers this disable?
OR does an OPP enabled at boot time remain enabled throughout the power
session?
regards,
-roger
--
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 1/4] OMAP: introduce OPP layer for device-specific OPPs
Roger Quadros had written, on 09/16/2010 08:54 AM, the following:
Since you are anyways re-sending this you might as well fix these nits.
thanks for reviewing..
[..]
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
new file mode 100644
index 000..17f93b2
--- /dev/null
+++ b/arch/arm/plat-omap/opp.c
@@ -0,0 +1,461 @@
+/*
+ * OMAP OPP Interface
+ *
+ * Copyright (C) 2009-2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Romit Dasgupta
+ *
+ * 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.
+ */
+
+/**
+ * opp_get_voltage() - Gets the voltage corresponding to an opp
+ * @opp: opp for which voltage has to be returned for
+ *
+ * Return voltage in micro volt corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_voltage(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
If !opp->enabled, then is it really an invalid parameter being passed?
I'm not user if people need to know the voltage of a disabled OPP, but
do we need to limit it?
+ pr_err("%s: Invalid parameters being passed\n", __func__);
+ return 0;
+ }
+
+ return opp->u_volt;
+}
+
+/**
+ * opp_get_freq() - Gets the frequency corresponding to an opp
+ * @opp: opp for which frequency has to be returned for
+ *
+ * Return frequency in hertz corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_freq(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
ditto.
Yes, the intent here was for opp operational apis to function ONLY on
the enabled opps - this helps to pull out any bugs in the users
who might be unintentionally using bad params.
do you have any usecase you can think of where we might want to use
these on a disabled opp?
+ pr_err("%s: Invalid parameters being passed\n", __func__);
+ return 0;
+ }
+
+ return opp->rate;
+}
+
+/**
+ * opp_get_opp_count() - Get number of opps enabled in the opp list
+ * @opp_type: OPP type we want to count
+ *
+ * This functions returns the number of opps if there are any OPPs enabled,
+ * else returns corresponding error value.
+ */
+int opp_get_opp_count(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ dev_opp = find_device_opp(dev);
+ if (IS_ERR(dev_opp))
+ return -ENODEV;
+
+ return dev_opp->enabled_opp_count;
+}
+
+/**
+ * opp_find_freq_exact() - search for an exact frequency
+ * @opp_type: OPP type we want to search in.
+ * @freq: frequency to search for
+ * @enabled: enabled/disabled OPP to search for
+ *
+ * Searches for exact match in the opp list and returns handle to the matching
+ * opp if found, else returns ERR_PTR in case of error and should be handled
+ * using IS_ERR.
+ *
+ * Note enabled is a modifier for the search. if enabled=true, then the match
is
Good to add some punctuation after 'Note'.
Thanks will do
+ * for exact matching frequency and is enabled. if false, the match is for
exact
+ * frequency which is disabled.
+ */
cheers,
-roger
--
Regards,
Nishanth Menon
--
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 1/4] OMAP: introduce OPP layer for device-specific OPPs
Nishant,
Since you are anyways re-sending this you might as well fix these nits.
On 09/16/2010 12:56 AM, ext Kevin Hilman wrote:
From: Nishanth Menon
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
new file mode 100644
index 000..17f93b2
--- /dev/null
+++ b/arch/arm/plat-omap/opp.c
@@ -0,0 +1,461 @@
+/*
+ * OMAP OPP Interface
+ *
+ * Copyright (C) 2009-2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Romit Dasgupta
+ *
+ * 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.
+ */
+
+/**
+ * opp_get_voltage() - Gets the voltage corresponding to an opp
+ * @opp: opp for which voltage has to be returned for
+ *
+ * Return voltage in micro volt corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_voltage(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
If !opp->enabled, then is it really an invalid parameter being passed?
I'm not user if people need to know the voltage of a disabled OPP, but
do we need to limit it?
+ pr_err("%s: Invalid parameters being passed\n", __func__);
+ return 0;
+ }
+
+ return opp->u_volt;
+}
+
+/**
+ * opp_get_freq() - Gets the frequency corresponding to an opp
+ * @opp: opp for which frequency has to be returned for
+ *
+ * Return frequency in hertz corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_freq(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
ditto.
+ pr_err("%s: Invalid parameters being passed\n", __func__);
+ return 0;
+ }
+
+ return opp->rate;
+}
+
+/**
+ * opp_get_opp_count() - Get number of opps enabled in the opp list
+ * @opp_type: OPP type we want to count
+ *
+ * This functions returns the number of opps if there are any OPPs enabled,
+ * else returns corresponding error value.
+ */
+int opp_get_opp_count(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ dev_opp = find_device_opp(dev);
+ if (IS_ERR(dev_opp))
+ return -ENODEV;
+
+ return dev_opp->enabled_opp_count;
+}
+
+/**
+ * opp_find_freq_exact() - search for an exact frequency
+ * @opp_type: OPP type we want to search in.
+ * @freq: frequency to search for
+ * @enabled: enabled/disabled OPP to search for
+ *
+ * Searches for exact match in the opp list and returns handle to the matching
+ * opp if found, else returns ERR_PTR in case of error and should be handled
+ * using IS_ERR.
+ *
+ * Note enabled is a modifier for the search. if enabled=true, then the match
is
Good to add some punctuation after 'Note'.
+ * for exact matching frequency and is enabled. if false, the match is for
exact
+ * frequency which is disabled.
+ */
cheers,
-roger
--
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 1/4] OMAP: introduce OPP layer for device-specific OPPs
Nishanth Menon wrote:
> Linus Walleij had written, on 09/16/2010 07:19 AM, the following:
>> 2010/9/15 Kevin Hilman :
>>
>>> OMAP SOCs have a standard set of tuples consisting of frequency and
>>> voltage pairs that the device will support per voltage domain. These
>>> are called Operating Performance Points or OPPs.
>>> (...)
>>> This introduces a common handling OPP mechanism accross all OMAPs.
>>> As a start this is used for OMAP3.
>> OPPs are a generic concept, it's in silicon construction textbooks and all.
>> Should this code not be made generic instead? You wouldn't make
>> regulators or even DMA platform-specific these days, so why should
>> OPPs be?
> As far as I see this patch :
> hwmod[1] which is omap specific which inturn depends on omap_device. -
> this impacts opp_add function in the opp layer.
Then wrap your local OPP in some clever way:
struct omap_opp {
struct hwmod foo;
struct opp opp;
};
container_of() is your friend.
Alternatively and not as elegant is to provide an
void *private_data; in the generic opp struct.
And similar design patterns for code and other
platform-specific hooks. Overridable struct opp_ops
for example, the same way we just abstracted the
l2x0 operations for example.
It's not like there are no precedents in the linux kernel
on how to handle a superclass of some struct, so
how hard can it be?
The fact that a single struct member is OMAP-specific doesn't
nix the fact that the major part of this OPP framework
is generic code.
Yours,
Linus Walleij
--
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 1/4] OMAP: introduce OPP layer for device-specific OPPs
Linus Walleij had written, on 09/16/2010 07:19 AM, the following: 2010/9/15 Kevin Hilman : OMAP SOCs have a standard set of tuples consisting of frequency and voltage pairs that the device will support per voltage domain. These are called Operating Performance Points or OPPs. (...) This introduces a common handling OPP mechanism accross all OMAPs. As a start this is used for OMAP3. OPPs are a generic concept, it's in silicon construction textbooks and all. Should this code not be made generic instead? You wouldn't make regulators or even DMA platform-specific these days, so why should OPPs be? As far as I see this patch : hwmod[1] which is omap specific which inturn depends on omap_device. - this impacts opp_add function in the opp layer. [1] http://marc.info/?l=linux-omap&m=128226580816341&w=2 -- Regards, Nishanth Menon -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
2010/9/15 Kevin Hilman : > OMAP SOCs have a standard set of tuples consisting of frequency and > voltage pairs that the device will support per voltage domain. These > are called Operating Performance Points or OPPs. > (...) > This introduces a common handling OPP mechanism accross all OMAPs. > As a start this is used for OMAP3. OPPs are a generic concept, it's in silicon construction textbooks and all. Should this code not be made generic instead? You wouldn't make regulators or even DMA platform-specific these days, so why should OPPs be? What in this code is actually OMAP-specific, more than that you name some functions omap_*, and how hard would it be to put it under arch/arm/common/*.c arch/arm/include/asm/*.h Possible even higher up in the directory hiearchy in include/linux/opp.h for the header and drivers/opp/*.c, because I think SuperH and power are not that different in this respect. Yours, Linus Walleij -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
>>-Original Message- >>From: Menon, Nishanth >>Sent: Thursday, September 16, 2010 4:02 PM >>To: Gopinath, Thara; Kevin Hilman; linux-omap@vger.kernel.org >>Cc: linux-arm-ker...@lists.infradead.org >>Subject: RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs >> >>> -Original Message- >>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >>> ow...@vger.kernel.org] On Behalf Of Gopinath, Thara >> >>[...] >>> >>diff --git a/arch/arm/plat-omap/include/plat/opp.h b/arch/arm/plat- >>> omap/include/plat/opp.h >>> >>new file mode 100644 >>> >>index 000..997b56e >>> >>--- /dev/null >>> >>+++ b/arch/arm/plat-omap/include/plat/opp.h >>[..] >>> >>+ >>> >>+#ifdef CONFIG_PM >>> >>+ >>[..] >>> >>+struct omap_opp *opp_find_freq_ceil(struct device *dev, unsigned long >>> *freq); >>> >>+ >>> >>+int opp_add(const struct omap_opp_def *opp_def); >>> >>+ >>> >>+int opp_enable(struct omap_opp *opp); >>> >>+ >>> >>+int opp_disable(struct omap_opp *opp); >>> >>+ >>> >>+void opp_init_cpufreq_table(struct device *dev, >>> >>+ struct cpufreq_frequency_table **table); >>> >>+#else >>> >>> Hello Kevin, >>> >>> IN case of CONFIG_PM not being defined the else part will cause a >>> compilation break as >>> the signature of these APIs defined in the else part do not match with the >>> signature in >>> the if part. >>> >>Thanks for the catch. Will send a patch for this. I learnt this the hard way by actually hitting the issue :-)!! Regards Thara -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Gopinath, Thara [...] > >>diff --git a/arch/arm/plat-omap/include/plat/opp.h b/arch/arm/plat- > omap/include/plat/opp.h > >>new file mode 100644 > >>index 000..997b56e > >>--- /dev/null > >>+++ b/arch/arm/plat-omap/include/plat/opp.h [..] > >>+ > >>+#ifdef CONFIG_PM > >>+ [..] > >>+struct omap_opp *opp_find_freq_ceil(struct device *dev, unsigned long > *freq); > >>+ > >>+int opp_add(const struct omap_opp_def *opp_def); > >>+ > >>+int opp_enable(struct omap_opp *opp); > >>+ > >>+int opp_disable(struct omap_opp *opp); > >>+ > >>+void opp_init_cpufreq_table(struct device *dev, > >>+ struct cpufreq_frequency_table **table); > >>+#else > > Hello Kevin, > > IN case of CONFIG_PM not being defined the else part will cause a > compilation break as > the signature of these APIs defined in the else part do not match with the > signature in > the if part. > Thanks for the catch. Will send a patch for this. Regards, Nishanth Menon -- 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 1/4] OMAP: introduce OPP layer for device-specific OPPs
>>-Original Message-
>>From: linux-omap-ow...@vger.kernel.org
>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
>>Hilman
>>Sent: Thursday, September 16, 2010 3:27 AM
>>To: linux-omap@vger.kernel.org
>>Cc: linux-arm-ker...@lists.infradead.org
>>Subject: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
>>
>>From: Nishanth Menon
>>
>>OMAP SOCs have a standard set of tuples consisting of frequency and
>>voltage pairs that the device will support per voltage domain. These
>>are called Operating Performance Points or OPPs. The actual
>>definitions of OMAP Operating Points varies over silicon within the
>>same family of devices. For a specific domain, you can have a set of
>>{frequency, voltage} pairs. As the kernel boots and more information
>>is available, a set of these are activated based on the precise nature
>>of device the kernel boots up on. It is interesting to remember that
>>each IP which belongs to a voltage domain may define their own set of
>>OPPs on top of this.
>>
>>This introduces a common handling OPP mechanism accross all OMAPs.
>>As a start this is used for OMAP3.
>>
>>Note: OPP is a concept that can be used in all OMAPs, it is hence
>>introduced under plat-omap
>>
>>Contributions include:
>>Sanjeev Premi for the initial concept:
>> http://patchwork.kernel.org/patch/50998/
>>Kevin Hilman for converting original design to device-based
>>Kevin Hilman and Paul Walmsey for cleaning up many of the function
>>abstractions, improvements and data structure handling
>>Romit Dasgupta for using enums instead of opp pointers
>>Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
>>cleanups.
>>
>>Discussions and comments from:
>>http://marc.info/?l=linux-omap&m=126033945313269&w=2
>>http://marc.info/?l=linux-omap&m=125482970102327&w=2
>>http://marc.info/?t=12580924752&r=1&w=2
>>http://marc.info/?l=linux-omap&m=126025973426007&w=2
>>incorporated.
>>
>>Cc: Benoit Cousson
>>Cc: Madhusudhan Chikkature Rajashekar
>>Cc: Phil Carmody
>>Cc: Roberto Granados Dorado
>>Cc: Santosh Shilimkar
>>Cc: Sergio Alberto Aguirre Rodriguez
>>Cc: Tero Kristo
>>Cc: Eduardo Valentin
>>Cc: Paul Walmsley
>>Cc: Romit Dasgupta
>>Cc: Sanjeev Premi
>>Cc: Thara Gopinath
>>Cc: Vishwanath BS
>>Signed-off-by: Nishanth Menon
>>Signed-off-by: Kevin Hilman
>>---
>> Documentation/arm/OMAP/omap_pm| 83 ++
>> arch/arm/plat-omap/Makefile |5 +
>> arch/arm/plat-omap/include/plat/opp.h | 145 +++
>> arch/arm/plat-omap/opp.c | 461
>> +
>> 4 files changed, 694 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/plat-omap/include/plat/opp.h
>> create mode 100644 arch/arm/plat-omap/opp.c
>>
>>diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
>>index 5389440..6527cdf 100644
>>--- a/Documentation/arm/OMAP/omap_pm
>>+++ b/Documentation/arm/OMAP/omap_pm
>>@@ -127,3 +127,86 @@ implementation needs:
>> 10. (*pdata->cpu_set_freq)(unsigned long f)
>>
>> 11. (*pdata->cpu_get_freq)(void)
>>+
>>+OMAP OPP Layer
>>+==
>>+OMAP SOCs have a standard set of tuples consisting of frequency and
>>+voltage pairs that the device will support per voltage domain. This
>>+is called Operating Performance Point or OPP. The actual definitions
>>+of OMAP OPP varies over silicon within the same family of devices.
>>+For a specific domain, you can have a set of {frequency, voltage}
>>+pairs. As the kernel boots and more information is available, a set
>>+of these are activated based on the precise nature of device the kernel
>>+boots up on. It is interesting to remember that each IP which belongs
>>+to a voltage domain may define their own set of OPPs on top of this.
>>+
>>+OPP layer of its own depends on silicon specific implementation and
>>+board specific data to finalize on the final set of OPPs available
>>+in a system
>>+
>>+Initial list initialization:
>>+---
>>+The normal initialization sequence is for boardxyz_init_irq to call
>>+omap2_init_common_hw (for omap2+) and which in turn does the default
>>+setup required.
>>+
>>+Silicon specific initialization: First the OPP layer needs to be told
>>+to initialize the tables for OMAP3, there are two options here:
>>+a) If the desire is to use the default
[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
From: Nishanth Menon
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OMAP Operating Points varies over silicon within the
same family of devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise nature
of device the kernel boots up on. It is interesting to remember that
each IP which belongs to a voltage domain may define their own set of
OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
Note: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=12580924752&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
incorporated.
Cc: Benoit Cousson
Cc: Madhusudhan Chikkature Rajashekar
Cc: Phil Carmody
Cc: Roberto Granados Dorado
Cc: Santosh Shilimkar
Cc: Sergio Alberto Aguirre Rodriguez
Cc: Tero Kristo
Cc: Eduardo Valentin
Cc: Paul Walmsley
Cc: Romit Dasgupta
Cc: Sanjeev Premi
Cc: Thara Gopinath
Cc: Vishwanath BS
Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
---
Documentation/arm/OMAP/omap_pm| 83 ++
arch/arm/plat-omap/Makefile |5 +
arch/arm/plat-omap/include/plat/opp.h | 145 +++
arch/arm/plat-omap/opp.c | 461 +
4 files changed, 694 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..6527cdf 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,86 @@ implementation needs:
10. (*pdata->cpu_set_freq)(unsigned long f)
11. (*pdata->cpu_get_freq)(void)
+
+OMAP OPP Layer
+==
+OMAP SOCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. This
+is called Operating Performance Point or OPP. The actual definitions
+of OMAP OPP varies over silicon within the same family of devices.
+For a specific domain, you can have a set of {frequency, voltage}
+pairs. As the kernel boots and more information is available, a set
+of these are activated based on the precise nature of device the kernel
+boots up on. It is interesting to remember that each IP which belongs
+to a voltage domain may define their own set of OPPs on top of this.
+
+OPP layer of its own depends on silicon specific implementation and
+board specific data to finalize on the final set of OPPs available
+in a system
+
+Initial list initialization:
+---
+The normal initialization sequence is for boardxyz_init_irq to call
+omap2_init_common_hw (for omap2+) and which in turn does the default
+setup required.
+
+Silicon specific initialization: First the OPP layer needs to be told
+to initialize the tables for OMAP3, there are two options here:
+a) If the desire is to use the default tables defined for that silicon,
+the board file does not need to call any initialization function, the
+defaults are setup as part of initialization flow when
+omap2_init_common_hw is called.
+
+b) board files would like to customize the default definition. In this
+case, board file needs to call explicitly prior to table operations.
+the sequence is:
+boardxyz_init_irq()
+{
+ ... do things ..
+ omap3_pm_init_opp_table()
+ .. customizations and other things ..
+ omap2_init_common_hw()
+}
+1. omap3_pm_init_opp_table - this in turn calls opp_init_list for all
+OPP types. This is the generic silicon operating points, however, the
+system may have additional features or customizations required. This
+flexibility is provided by the following apis:
+
+Query functions:
+
+Search for OPPs for various cases:
+2. opp_find_freq_exact - exact search function
+3. opp_find_freq_floor - round_up search function
+4. opp_find_freq_ceil - round_down search function
+
+OPP modifier functions:
+--
+This allows opp layer users to add customized OPPs or change the table
+for any need they may have
+5. opp_add - add a new OPP - NOTE: use st
[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
From: Nishanth Menon
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OMAP Operating Points varies over silicon within the
same family of devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise nature
of device the kernel boots up on. It is interesting to remember that
each IP which belongs to a voltage domain may define their own set of
OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
Note: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=12580924752&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
incorporated.
Cc: Benoit Cousson
Cc: Madhusudhan Chikkature Rajashekar
Cc: Phil Carmody
Cc: Roberto Granados Dorado
Cc: Santosh Shilimkar
Cc: Sergio Alberto Aguirre Rodriguez
Cc: Tero Kristo
Signed-off-by: Eduardo Valentin
Signed-off-by: Kevin Hilman
Signed-off-by: Nishanth Menon
Signed-off-by: Paul Walmsley
Signed-off-by: Romit Dasgupta
Signed-off-by: Sanjeev Premi
Signed-off-by: Thara Gopinath
Signed-off-by: Vishwanath BS
---
Documentation/arm/OMAP/omap_pm| 93 ++
arch/arm/plat-omap/Makefile |5 +
arch/arm/plat-omap/include/plat/opp.h | 160 ++
arch/arm/plat-omap/opp.c | 513 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..b046ebc 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,96 @@ implementation needs:
10. (*pdata->cpu_set_freq)(unsigned long f)
11. (*pdata->cpu_get_freq)(void)
+
+OMAP OPP Layer
+==
+OMAP SOCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. This
+is called Operating Performance Point or OPP. The actual definitions
+of OMAP OPP varies over silicon within the same family of devices.
+For a specific domain, you can have a set of {frequency, voltage}
+pairs. As the kernel boots and more information is available, a set
+of these are activated based on the precise nature of device the kernel
+boots up on. It is interesting to remember that each IP which belongs
+to a voltage domain may define their own set of OPPs on top of this.
+
+OPP layer of its own depends on silicon specific implementation and
+board specific data to finalize on the final set of OPPs available
+in a system
+
+Initial list initialization:
+---
+The normal initialization sequence is for boardxyz_init_irq to call
+omap2_init_common_hw (for omap2+) and which in turn does the default
+setup required.
+
+Silicon specific initialization: First the OPP layer needs to be told
+to initialize the tables for OMAP3, there are two options here:
+a) If the desire is to use the default tables defined for that silicon,
+the board file does not need to call any initialization function, the
+defaults are setup as part of initialization flow when
+omap2_init_common_hw is called.
+
+b) board files would like to customize the default definition. In this
+case, board file needs to call explicitly prior to table operations.
+the sequence is:
+boardxyz_init_irq()
+{
+ ... do things ..
+ omap3_pm_init_opp_table()
+ .. customizations and other things ..
+ omap2_init_common_hw()
+}
+1. omap3_pm_init_opp_table - this in turn calls opp_init_list for all
+OPP types. This is the generic silicon operating points, however, the
+system may have additional features or customizations required. This
+flexibility is provided by the following apis:
+
+Query functions:
+
+Search for OPPs for various cases:
+2. opp_find_freq_exact - exact search function
+3. opp_find_freq_floor - round_up search function
+4. opp_find_freq_ceil - round_down search function
+
+OPP modifier functions:
+--
+This allows opp layer users to add customized OPPs or change the table
+for
[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
From: Nishanth Menon
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OMAP Operating Points varies over silicon within the
same family of devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise nature
of device the kernel boots up on. It is interesting to remember that
each IP which belongs to a voltage domain may define their own set of
OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
Note: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=12580924752&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
incorporated.
Cc: Benoit Cousson
Cc: Madhusudhan Chikkature Rajashekar
Cc: Phil Carmody
Cc: Roberto Granados Dorado
Cc: Santosh Shilimkar
Cc: Sergio Alberto Aguirre Rodriguez
Cc: Tero Kristo
Signed-off-by: Eduardo Valentin
Signed-off-by: Kevin Hilman
Signed-off-by: Nishanth Menon
Signed-off-by: Paul Walmsley
Signed-off-by: Romit Dasgupta
Signed-off-by: Sanjeev Premi
Signed-off-by: Thara Gopinath
Signed-off-by: Vishwanath BS
---
Documentation/arm/OMAP/omap_pm| 93 ++
arch/arm/plat-omap/Makefile |5 +
arch/arm/plat-omap/include/plat/opp.h | 160 ++
arch/arm/plat-omap/opp.c | 513 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..b046ebc 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,96 @@ implementation needs:
10. (*pdata->cpu_set_freq)(unsigned long f)
11. (*pdata->cpu_get_freq)(void)
+
+OMAP OPP Layer
+==
+OMAP SOCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. This
+is called Operating Performance Point or OPP. The actual definitions
+of OMAP OPP varies over silicon within the same family of devices.
+For a specific domain, you can have a set of {frequency, voltage}
+pairs. As the kernel boots and more information is available, a set
+of these are activated based on the precise nature of device the kernel
+boots up on. It is interesting to remember that each IP which belongs
+to a voltage domain may define their own set of OPPs on top of this.
+
+OPP layer of its own depends on silicon specific implementation and
+board specific data to finalize on the final set of OPPs available
+in a system
+
+Initial list initialization:
+---
+The normal initialization sequence is for boardxyz_init_irq to call
+omap2_init_common_hw (for omap2+) and which in turn does the default
+setup required.
+
+Silicon specific initialization: First the OPP layer needs to be told
+to initialize the tables for OMAP3, there are two options here:
+a) If the desire is to use the default tables defined for that silicon,
+the board file does not need to call any initialization function, the
+defaults are setup as part of initialization flow when
+omap2_init_common_hw is called.
+
+b) board files would like to customize the default definition. In this
+case, board file needs to call explicitly prior to table operations.
+the sequence is:
+boardxyz_init_irq()
+{
+ ... do things ..
+ omap3_pm_init_opp_table()
+ .. customizations and other things ..
+ omap2_init_common_hw()
+}
+1. omap3_pm_init_opp_table - this in turn calls opp_init_list for all
+OPP types. This is the generic silicon operating points, however, the
+system may have additional features or customizations required. This
+flexibility is provided by the following apis:
+
+Query functions:
+
+Search for OPPs for various cases:
+2. opp_find_freq_exact - exact search function
+3. opp_find_freq_floor - round_up search function
+4. opp_find_freq_ceil - round_down search function
+
+OPP modifier functions:
+--
+This allows opp layer users to add customized OPPs or change the table
+for
