OMAP: Add opp data

PATCH Superseded Nishanth Menon 4 participants 20 messages Nov 15, 2010 – Nov 17, 2010 1 message not in the archive

Subsystems (5)

Documentation Arm (32-bit) Arm sub-architectures OMAP2+ support +1 more subsystems

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [PATCH 0/3 v2] omap: opp: Add opp data

Nishanth Menon

author

2010-11-15 19:27 UTC #2 lore raw

PATCH v3 1/3 omap: opp: add OMAP3 OPP table data and common init

In reply to a message not in the archive

Add OPP data for OMAP34xx and OMAP36xx and initialization functions to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3 and OMAP4+ SoCs can use to register their OPP definitions.

Signed-off-by Kevin Hilman <[email protected]>

Signed-off-by Nishanth Menon <[email protected]>

---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well for OMAP3 in the Kconfig
v3:
* added documentation for custom opp modification by board files
* switched to using device_initcall to autoinitialize the opp tables
v2: https://patchwork.kernel.org/patch/266911/

 Documentation/arm/OMAP/omap_pm     |   26 ++++++
 arch/arm/mach-omap2/Kconfig        |    1 +
 arch/arm/mach-omap2/Makefile       |    2 +
 arch/arm/mach-omap2/opp.c          |  154 ++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/opp3xxx_data.h |   82 +++++++++++++++++++
 arch/arm/mach-omap2/pm.h           |    9 ++
 6 files changed, 274 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/opp.c
 create mode 100644 arch/arm/mach-omap2/opp3xxx_data.h

Documentation/arm/OMAP/omap_pm +26 -0

index 5389440..88341f0 100644
@@ -127,3 +127,29 @@ implementation needs:
 10. (*pdata->cpu_set_freq)(unsigned long f)
 
 11. (*pdata->cpu_get_freq)(void)
+
+Customizing OPP for platform
+============================
+Defining CONFIG_PM should enable OPP layer for the silicon
+and the registration of OPP table should take place automatically.
+However, in special cases, the default OPP table may need to be
+tweaked, for e.g.:
+ * enable default OPPs which are disabled by default, but which
+   could be enabled on a platform
+ * Disable an unsupported OPP on the platform
+ * Define and add a custom opp table entry
+in these cases, the board file needs to do additional steps as follows:
+arch/arm/mach-omapx/board-xyz.c
+	#include "pm.h"
+	....
+	static void __init omap_xyz_init_irq(void)
+	{
+		....
+		/* Initialize the default table */
+		omapx_opp_init();
+		/* Do customization to the defaults */
+		....
+	}
+NOTE: omapx_opp_init will be omap3_opp_init or as required
+based on the omap family.
+

arch/arm/mach-omap2/Kconfig +1 -0

index ab784bf..93a91ff 100644
@@ -35,6 +35,7 @@ config ARCH_OMAP3
 	select CPU_V7
 	select USB_ARCH_HAS_EHCI
 	select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
+ 	select PM_OPP if PM
 
 config ARCH_OMAP4
 	bool "TI OMAP4"

arch/arm/mach-omap2/Makefile +2 -0

index 60e51bc..1650a62 100644
@@ -64,6 +64,8 @@ endif
 
 endif
 
+obj-$(CONFIG_PM_OPP)		+= opp.o
+
 # PRCM
 obj-$(CONFIG_ARCH_OMAP2)		+= cm.o
 obj-$(CONFIG_ARCH_OMAP3)		+= cm.o

arch/arm/mach-omap2/opp.c new file +154 -0

154 lines not on this page · raw message

arch/arm/mach-omap2/opp3xxx_data.h new file +82 -0

82 lines not on this page · raw message

arch/arm/mach-omap2/pm.h +9 -0

index 0d75bfd..2031f15 100644
@@ -20,6 +20,15 @@ extern int omap3_can_sleep(void);
 extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
 extern int omap3_idle_init(void);
 
+#if defined(CONFIG_PM_OPP)
+extern int omap3_opp_init(void);
+#else
+static inline int omap3_opp_init(void)
+{
+	return -EINVAL;
+}
+#endif
+
 struct cpuidle_params {
 	u8  valid;
 	u32 sleep_latency;

Signature · 1 line

1.6.3.3

Thomas Petazzoni

2010-11-15 22:52 UTC #3 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Hello,

arch/arm/mach-omap2/opp3xxx_data.h line 57

Quoted 5 lines · On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menon <[email protected]> wrote:

+++ b/arch/arm/mach-omap2/opp3xxx_data.h
arch/arm/mach-omap2/opp3xxx_data.h new file +4 -0
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {

Do we really want to have structure definitions in an header file ? Unless I'm wrong, this means that if the opp3xxx_data.h file is included in two different C files, the structures will be present twice.

As far as I could see, most of the kernel instantiate structure in C files instead.

Regards,

Thomas

Signature · 4 lines

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Nishanth Menon

author

2010-11-16 00:53 UTC #4 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following:

Quoted 5 lines

Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon <[email protected]> wrote:

Quoted 9 lines

arch/arm/mach-omap2/opp3xxx_data.h line 57
Quoted 5 lines
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
arch/arm/mach-omap2/opp3xxx_data.h new file +4 -0
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
Do we really want to have structure definitions in an header file ? Unless I'm wrong, this means that if the opp3xxx_data.h file is included in two different C files, the structures will be present twice.

The intent here - DONT DO precisely THAT!

Quoted 3 lines

As far as I could see, most of the kernel instantiate structure in C files instead.

The intent here though was that opp3xx.h and opp4xx.h are private to just opp.c to prevent misuse elsewhere. hmm.. thinking a bit,
find drivers/ -iname "*.c"|xargs grep "#include"| grep -v "\.h"
shows numerous examples of .c files being included in c files. I dont have an issue of renaming these headers as .c file instead (I had carried them over as .h from old implementation, but we can change it), main point being, I just dont want folks mucking around and hacking stuff with the defines.

Signature · 2 lines

Regards,
Nishanth Menon

Tony Lindgren

maintainer

2010-11-16 20:35 UTC #5 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Quoted 19 lines · Nishanth Menon

Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following:
Quoted 5 lines
Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon <[email protected]> wrote:
Quoted 9 lines
arch/arm/mach-omap2/opp3xxx_data.h line 57
Quoted 5 lines
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
arch/arm/mach-omap2/opp3xxx_data.h new file +4 -0
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
Do we really want to have structure definitions in an header file ? Unless I'm wrong, this means that if the opp3xxx_data.h file is included in two different C files, the structures will be present twice.
The intent here - DONT DO precisely THAT!
Quoted 3 lines
As far as I could see, most of the kernel instantiate structure in C files instead.

Quoted 8 lines

The intent here though was that opp3xx.h and opp4xx.h are private to just opp.c to prevent misuse elsewhere. hmm.. thinking a bit, find drivers/ -iname "*.c"|xargs grep "#include"| grep -v "\.h" shows numerous examples of .c files being included in c files. I dont have an issue of renaming these headers as .c file instead (I had carried them over as .h from old implementation, but we can change it), main point being, I just dont want folks mucking around and hacking stuff with the defines.

What usually works best is to have common opp.c, then have opp34xx.c that has initcall that registers the data in opp.c.

That leaves out if cpu_is_omapxxx else if stuff in opp.c and then adding support for new omaps is just a matter of doing oppxxxx.c.

Regards,

Tony

Nishanth Menon

author

2010-11-16 21:11 UTC #6 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Tony Lindgren had written, on 11/16/2010 02:35 PM, the following:

Quoted 27 lines · Nishanth Menon

Quoted 17 lines
Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following:
Quoted 5 lines
Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon <[email protected]> wrote:
Quoted 8 lines
arch/arm/mach-omap2/opp3xxx_data.h line 57
Quoted 5 lines
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
arch/arm/mach-omap2/opp3xxx_data.h new file +4 -0
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
Do we really want to have structure definitions in an header file ? Unless I'm wrong, this means that if the opp3xxx_data.h file is included in two different C files, the structures will be present twice.
The intent here - DONT DO precisely THAT!
Quoted 2 lines
As far as I could see, most of the kernel instantiate structure in C files instead.
Quoted 8 lines
The intent here though was that opp3xx.h and opp4xx.h are private to just opp.c to prevent misuse elsewhere. hmm.. thinking a bit, find drivers/ -iname "*.c"|xargs grep "#include"| grep -v "\.h" shows numerous examples of .c files being included in c files. I dont have an issue of renaming these headers as .c file instead (I had carried them over as .h from old implementation, but we can change it), main point being, I just dont want folks mucking around and hacking stuff with the defines.

Quoted 5 lines

What usually works best is to have common opp.c, then have opp34xx.c that has initcall that registers the data in opp.c.
That leaves out if cpu_is_omapxxx else if stuff in opp.c and then adding support for new omaps is just a matter of doing oppxxxx.c.

Series rev4 already posted here:
http://marc.info/?l=linux-omap&m=128993367212640&w=2
I believe I have taken care of the comments there - do let me know if I screwed anything up here..

Signature · 2 lines

Regards,
Nishanth Menon

Thomas Petazzoni

2010-11-16 11:21 UTC #7 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

In reply to Nishanth Menon

Hello,

Review

Quoted 2 lines · On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menon <[email protected]> wrote:

(quoted diff) +2 -0

+	/*
+	 * Allow multiple calls, but initialize only if not already initalized

Minor: s/initalized/initialized/.

arch/arm/mach-omap2/opp.c line 90

Quoted 5 lines

arch/arm/mach-omap2/opp.c new file +5 -0

+	 * even if the previous call failed, coz, no reason we'd succeed again
+	 */
+	if (omap_table_init)
+		return 0;
+	omap_table_init = 1;

Do we really need this ? I personaly don't really like this quite of "Hey, I'm already initialized, let's do nothing silently then". Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1).

Regards,

Thomas

Signature · 4 lines

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Nishanth Menon

author

2010-11-16 11:55 UTC #8 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni wrote, on 11/16/2010 05:21 AM:

Quoted 9 lines

Hello,
Review
Quoted 2 lines · On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menon<[email protected]> wrote:
(quoted diff) +2 -0
+	/*
+	 * Allow multiple calls, but initialize only if not already initalized
Minor: s/initalized/initialized/.

aah thanks :)

Quoted 12 lines

arch/arm/mach-omap2/opp.c line 90
Quoted 6 lines
arch/arm/mach-omap2/opp.c new file +5 -0
+	 * even if the previous call failed, coz, no reason we'd succeed again
+	 */
+	if (omap_table_init)
+		return 0;
+	omap_table_init = 1;
Do we really need this ? I personaly don't really like this quite of "Hey, I'm already initialized, let's do nothing silently then". Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1).

Yes, it is needed. The intent here is different. See the documentation that I put along with this patch - At times, board files may need to do customization to opps - like enable 1GHz on that platform alone -> it can do it *only if* the defaults are registered, following which it can call opp_enable. when device_initcall follows this at a later point, it is still valid.

btw, BUG_ON is a strict NO NO for me here - if I dont have OPP table, ok fine, system can still survive without cpufreq, no need to stop system operations because of that.

Signature · 2 lines

Regards,
Nishanth Menon

Thomas Petazzoni

2010-11-16 12:42 UTC #9 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Hello,

Quoted 11 lines · On Tue, 16 Nov 2010 05:54:50 -0600 Nishanth Menon <[email protected]> wrote:

Quoted 5 lines
Do we really need this ? I personaly don't really like this quite of "Hey, I'm already initialized, let's do nothing silently then". Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1).
Yes, it is needed. The intent here is different. See the documentation that I put along with this patch - At times, board files may need to do customization to opps - like enable 1GHz on that platform alone -> it can do it *only if* the defaults are registered, following which it can call opp_enable. when device_initcall follows this at a later point, it is still valid.

Ah, right, I didn't catch that omapX_init_opp() could be called first from the board init function, and then later on as a device_initcall() callback.

But, sorry, I find this even uglier than I thought it was :) What about adding the obligation to boards file to call the omapX_init_opp() function and then do their customization (if needed), then no call to omapX_init_opp() would be needed as a device_initcall() callback. Or, add a mechanism that allows the board file to register its customizations, that are later taken into account by the omapX_init_opp() function.

Maybe it's just a matter of personal taste, but I really don't like this kind of "let's call this function once, do some stuff, then call it again, since it'll know that it shouldn't do anything".

Quoted 3 lines

btw, BUG_ON is a strict NO NO for me here - if I dont have OPP table, ok fine, system can still survive without cpufreq, no need to stop system operations because of that.

I don't see why replacing:

+ if (omap_table_init)
+ return 0;
+ omap_table_init = 1;

	BUG_ON(omap_table_init == 1);
	omap_table_init = 1;

would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()).

Regards,

Thomas

Signature · 4 lines

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Nishanth Menon

author

2010-11-16 13:17 UTC #10 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni wrote, on 11/16/2010 06:42 AM:

Quoted 29 lines

Hello,
Quoted 11 lines · On Tue, 16 Nov 2010 05:54:50 -0600 Nishanth Menon<[email protected]> wrote:
Quoted 5 lines
Do we really need this ? I personaly don't really like this quite of "Hey, I'm already initialized, let's do nothing silently then". Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1).
Yes, it is needed. The intent here is different. See the documentation that I put along with this patch - At times, board files may need to do customization to opps - like enable 1GHz on that platform alone -> it can do it *only if* the defaults are registered, following which it can call opp_enable. when device_initcall follows this at a later point, it is still valid.
Ah, right, I didn't catch that omapX_init_opp() could be called first from the board init function, and then later on as a device_initcall() callback.
But, sorry, I find this even uglier than I thought it was :) What about adding the obligation to boards file to call the omapX_init_opp() function and then do their customization (if needed), then no call to omapX_init_opp() would be needed as a device_initcall() callback. Or, add a mechanism that allows the board file to register its customizations, that are later taken into account by the omapX_init_opp() function.

Quoted 3 lines

Maybe it's just a matter of personal taste, but I really don't like this kind of "let's call this function once, do some stuff, then call it again, since it'll know that it shouldn't do anything".,

I feel you may have misunderstood the code, we DONOT oblige all boards to *have* to call omapX_init_opp. It is a device_initcall - so for the boards that dont call it, device_initcall will trigger and initialzie it. the hooks for the customization of the OPPs is in OPP layer itself.

the need we satisfy is this: if you need to support two sets of boards:
a) boards that are happy with the defaults - most of the boards - dont do anything in the board file. (device_init_call with auto register the defaults)
b) boards that need customization - these guys need to call omapX_init_opp(to register the defaults) before customizing the defaults.

Does this explain the code and reason for the logic? if you do have a better mechanism, lets know.

Quoted 11 lines

Quoted 4 lines
btw, BUG_ON is a strict NO NO for me here - if I dont have OPP table, ok fine, system can still survive without cpufreq, no need to stop system operations because of that.
I don't see why replacing:
arch/arm/mach-omap2/opp.c new file +3 -0
+	if (omap_table_init)
+		return 0;
+	omap_table_init = 1;

Quoted 7 lines

by
	BUG_ON(omap_table_init == 1);
	omap_table_init = 1;
would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()).

HUH?? NULL table to a static function - what code are you talking about?? why are you so behind BUG_ON, when there are valid reasons for reentry into code.

Signature · 2 lines

Regards,
Nishanth Menon

Thomas Petazzoni

2010-11-16 13:20 UTC #11 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Hello,

Quoted 4 lines · On Tue, 16 Nov 2010 07:10:36 -0600 Nishanth Menon <[email protected]> wrote:

I feel you may have misunderstood the code, we DONOT oblige all boards to *have* to call omapX_init_opp. It is a device_initcall - so for the boards that dont call it, device_initcall will trigger and initialzie it. the hooks for the customization of the OPPs is in OPP layer itself.

This is exactly what I have understood.

Quoted 9 lines

the need we satisfy is this: if you need to support two sets of boards:
a) boards that are happy with the defaults - most of the boards - dont do anything in the board file. (device_init_call with auto register the defaults)
b) boards that need customization - these guys need to call omapX_init_opp(to register the defaults) before customizing the defaults.
Does this explain the code and reason for the logic? if you do have a better mechanism, lets know.

Yes, it explains the code and reason for the logic, but still doesn't make it pretty :-)

Quoted 5 lines

Quoted 2 lines
would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()).
HUH?? NULL table to a static function - what code are you talking about?? why are you so behind BUG_ON, when there are valid reasons for reentry into code.

In the current design, yes, there are indeed valid reasons for reentry into the omapX_init_opp() function, and that's exactly the point I'm critizicing here.

Regards!

Thomas

Signature · 4 lines

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Nishanth Menon

author

2010-11-16 14:02 UTC #12 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni had written, on 11/16/2010 07:20 AM, the following:

Quoted 7 lines

Quoted 3 lines
Quoted 2 lines
would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()).
HUH?? NULL table to a static function - what code are you talking about?? why are you so behind BUG_ON, when there are valid reasons for reentry into code.
In the current design, yes, there are indeed valid reasons for reentry into the omapX_init_opp() function, and that's exactly the point I'm critizicing here.

how about:

	if (omap_table_init)
		return -EEXIST;

does that make it better? it still retains the ability to handle both kinds of platforms as well as not BUG out.

Signature · 2 lines

Regards,
Nishanth Menon

Nishanth Menon

author

2010-11-16 15:23 UTC #13 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

In reply to Thomas Petazzoni

Thomas Petazzoni had written, on 11/16/2010 06:42 AM, the following:

Quoted 3 lines

But, sorry, I find this even uglier than I thought it was :) What about adding the obligation to boards file to call the omapX_init_opp() function and then do their customization (if needed), then no call to

I knew I had discussed this before! Apologies, I should have dug this thread up earlier in the discussion.

my initial implementation had forced board files to call the opp_init_table, then changed that here:
http://marc.info/?l=linux-omap&m=127431810922704&w=2
Kevin seemed happy with the change here:
http://marc.info/?l=linux-omap&m=127507237109393&w=2

Signature · 2 lines

Regards,
Nishanth Menon

Thomas Petazzoni

2010-11-16 15:50 UTC #14 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Quoted 5 lines · On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon <[email protected]> wrote:

my initial implementation had forced board files to call the opp_init_table, then changed that here:
http://marc.info/?l=linux-omap&m=127431810922704&w=2
Kevin seemed happy with the change here:
http://marc.info/?l=linux-omap&m=127507237109393&w=2

Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers.

Regards,

Thomas

Signature · 4 lines

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Nishanth Menon

author

2010-11-16 15:56 UTC #15 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni had written, on 11/16/2010 09:50 AM, the following:

Quoted 10 lines

Quoted 4 lines · On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon <[email protected]> wrote:
my initial implementation had forced board files to call the opp_init_table, then changed that here:
http://marc.info/?l=linux-omap&m=127431810922704&w=2
Kevin seemed happy with the change here:
http://marc.info/?l=linux-omap&m=127507237109393&w=2
Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers.

Thanks for taking the time to review and the comments. It is always a good idea to evolve to a better solution.

If there are no further comments, I will post a v4 later today incorporating comments:
a) return error instead of 0 if opp table is already initialized
b) change the .h to .c

Signature · 2 lines

Regards,
Nishanth Menon

Kevin Hilman

2010-11-16 16:16 UTC #16 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

In reply to Thomas Petazzoni

Quoted 11 lines · Thomas Petazzoni

Quoted 5 lines · On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon <[email protected]> wrote:
my initial implementation had forced board files to call the opp_init_table, then changed that here:
http://marc.info/?l=linux-omap&m=127431810922704&w=2
Kevin seemed happy with the change here:
http://marc.info/?l=linux-omap&m=127507237109393&w=2
Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers.

Yes, I'm not a big fan of the init function called multiple times either, but I really want to minimize what board files have to do.

Historically, we tend to add all the init functions to every board file, and this is getting cumbersome to understand and maintain. What we need is for common code to take care of sensible defaults for all boards, and then only boards with non-default behavior have to have custom code.

Kevin

Tony Lindgren

maintainer

2010-11-16 20:38 UTC #17 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Quoted 14 lines · Kevin Hilman

Quoted 11 lines · Thomas Petazzoni
Quoted 5 lines · On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon <[email protected]> wrote:
my initial implementation had forced board files to call the opp_init_table, then changed that here:
http://marc.info/?l=linux-omap&m=127431810922704&w=2
Kevin seemed happy with the change here:
http://marc.info/?l=linux-omap&m=127507237109393&w=2
Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers.

Quoted 7 lines

Yes, I'm not a big fan of the init function called multiple times either, but I really want to minimize what board files have to do.
Historically, we tend to add all the init functions to every board file, and this is getting cumbersome to understand and maintain. What we need is for common code to take care of sensible defaults for all boards, and then only boards with non-default behavior have to have custom code.

Yeah. The initial comment from Thomas with data in .h file should be fixed though.

Tony

Thomas Petazzoni

2010-11-17 08:19 UTC #18 lore raw

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

In reply to Kevin Hilman

Quoted 8 lines · On Tue, 16 Nov 2010 08:16:07 -0800 Kevin Hilman <[email protected]>…

Yes, I'm not a big fan of the init function called multiple times either, but I really want to minimize what board files have to do.
Historically, we tend to add all the init functions to every board file, and this is getting cumbersome to understand and maintain. What we need is for common code to take care of sensible defaults for all boards, and then only boards with non-default behavior have to have custom code.

The other way is to have the board code "register" its customization into the OPP subsystem, and then when the OPP subsystem is initialized, it takes those customizations into account. But in that specific case, it's not clear how those customizations could easily be expressed, so maybe that multiple call strategy is the simplest solution.

Thomas

Signature · 4 lines

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Nishanth Menon

author

2010-11-15 19:27 UTC #19 lore raw

PATCH v3 2/3 omap4: opp: add OPP table data

In reply to a message not in the archive

This patch adds OPP tables for OMAP4. New file has been added to keep the OMAP4 opp tables and the registration of these tables with the generic opp framework by OMAP SoC OPP interface.

Based on:
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blob;f=arch/arm/mach-omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next

Signed-off-by Thara Gopinath <[email protected]>

Signed-off-by Nishanth Menon <[email protected]>

---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well for OMAP4 in Kconfig
v3:
* switched to using device_initcall to autoinitialize the opp tables
v2: https://patchwork.kernel.org/patch/266921/

 arch/arm/mach-omap2/Kconfig        |    1 +
 arch/arm/mach-omap2/opp.c          |   18 +++++++++++++++++
 arch/arm/mach-omap2/opp4xxx_data.h |   37 ++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/pm.h           |    5 ++++
 4 files changed, 61 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/opp4xxx_data.h

arch/arm/mach-omap2/Kconfig +1 -0

index 93a91ff..0f1855a 100644
@@ -45,6 +45,7 @@ config ARCH_OMAP4
 	select ARM_GIC
 	select PL310_ERRATA_588369
 	select ARM_ERRATA_720789
+ 	select PM_OPP if PM
 
 comment "OMAP Core Type"
 	depends on ARCH_OMAP2

arch/arm/mach-omap2/opp.c +18 -0

index 79c711c..d1012bd 100644
@@ -152,3 +152,21 @@ int __init omap3_opp_init(void)
 }
 device_initcall(omap3_opp_init);
 
+/* omap4 opps */
+#include "opp4xxx_data.h"
+/**
+ * omap4_opp_init() - initialize omap4 opp table
+ */
+int __init omap4_opp_init(void)
+{
+	int r = -ENODEV;
+
+	if (!cpu_is_omap44xx())
+		return r;
+
+	r = omap_init_opp_table(omap44xx_opp_def_list,
+			ARRAY_SIZE(omap44xx_opp_def_list));
+
+	return r;
+}
+device_initcall(omap4_opp_init);

arch/arm/mach-omap2/opp4xxx_data.h new file +37 -0

new file mode 100644
index 0000000..2e5fe67
@@ -0,0 +1,37 @@
+/*
+ * OMAP4 OPP table definitions.
+ *
+ * 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
+ * Copyright (C) 2010 Texas Instruments Incorporated.
+ *	Thara Gopinath
+ *
+ * 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.
+ */
+
+#ifndef __ASM_PLAT_OPP_OMAP4XXX_H__
+#define __ASM_PLAT_OPP_OMAP4XXX_H__
+
+static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
+	/* MPU OPP1 - OPP50 */
+	OPP_INITIALIZER("mpu", true, 300000000, 1100000),
+	/* MPU OPP2 - OPP100 */
+	OPP_INITIALIZER("mpu", true, 600000000, 1200000),
+	/* MPU OPP3 - OPP-Turbo */
+	OPP_INITIALIZER("mpu", false, 800000000, 1260000),
+	/* MPU OPP4 - OPP-SB */
+	OPP_INITIALIZER("mpu", false, 1008000000, 1350000),
+	/* L3 OPP1 - OPP50 */
+	OPP_INITIALIZER("l3_main_1", true, 100000000, 930000),
+	/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
+	OPP_INITIALIZER("l3_main_1", true, 200000000, 1100000),
+	/* TODO: add IVA, DSP, aess, fdif, gpu */
+};
+
+#endif		/*  __ASM_PLAT_OPP_OMAP4XXX_H__ */

arch/arm/mach-omap2/pm.h +5 -0

index 2031f15..a43e069 100644
@@ -22,11 +22,16 @@ extern int omap3_idle_init(void);
 
 #if defined(CONFIG_PM_OPP)
 extern int omap3_opp_init(void);
+extern int omap4_opp_init(void);
 #else
 static inline int omap3_opp_init(void)
 {
 	return -EINVAL;
 }
+static inline int omap4_opp_init(void)
+{
+	return -EINVAL;
+}
 #endif
 
 struct cpuidle_params {

Signature · 1 line

1.6.3.3

Nishanth Menon

author

2010-11-15 19:27 UTC #20 lore raw

PATCH v3 3/3 OMAP3: remove OPP interfaces from OMAP PM layer

In reply to a message not in the archive

From: Kevin Hilman <[email protected]>

With new OPP layer, OPP users will access OPP API directly instead of using OMAP PM layer, so remove all notions of OPPs from the OMAP PM layer.

Signed-off-by Nishanth Menon <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

---
v3: no longer explicitly calling the init_table, instead
depending on the device_initcall to initialize as needed

v2: https://patchwork.kernel.org/patch/266931/

 arch/arm/mach-omap2/io.c                  |    3 +-
 arch/arm/plat-omap/include/plat/omap-pm.h |   31 +++++++++-------------------
 arch/arm/plat-omap/omap-pm-noop.c         |   11 +---------
 3 files changed, 12 insertions(+), 33 deletions(-)

arch/arm/mach-omap2/io.c +1 -2

index 40562dd..2fe4e02 100644
@@ -327,8 +327,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
 	else if (cpu_is_omap44xx())
 		omap44xx_hwmod_init();
 
-	/* The OPP tables have to be registered before a clk init */
-	omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+	omap_pm_if_early_init();
 
 	if (cpu_is_omap2420())
 		omap2420_clk_init();

arch/arm/plat-omap/include/plat/omap-pm.h +10 ~~-21~~

index 728fbb9..62c3fe9 100644
@@ -17,27 +17,10 @@
 #include <linux/device.h>
 #include <linux/cpufreq.h>
 #include <linux/clk.h>
+#include <linux/opp.h>
 
 #include "powerdomain.h"
 
-/**
- * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
- * @rate: target clock rate
- * @opp_id: OPP ID
- * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
- *
- * Operating performance point data.  Can vary by OMAP chip and board.
- */
-struct omap_opp {
-	unsigned long rate;
-	u8 opp_id;
-	u16 min_vdd;
-};
-
-extern struct omap_opp *mpu_opps;
-extern struct omap_opp *dsp_opps;
-extern struct omap_opp *l3_opps;
-
 /*
  * agent_id values for use with omap_pm_set_min_bus_tput():
  *

@@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
  * framework starts.  The "_if_" is to avoid name collisions with the
  * PM idle-loop code.
  */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-				 struct omap_opp *dsp_opp_table,
-				 struct omap_opp *l3_opp_table);
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_early_init() 0
+#else
+int __init omap_pm_if_early_init(void);
+#endif
 
 /**
  * omap_pm_if_init - OMAP PM init code called after clock fw init

@@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
  * The main initialization code.  OPP tables are passed in here.  The
  * "_if_" is to avoid name collisions with the PM idle-loop code.
  */
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_init() 0
+#else
 int __init omap_pm_if_init(void);
+#endif
 
 /**
  * omap_pm_if_exit - OMAP PM exit code

arch/arm/plat-omap/omap-pm-noop.c +1 ~~-10~~

index e129ce8..ca75abb 100644
@@ -26,10 +26,6 @@
 
 #include <plat/powerdomain.h>
 
-struct omap_opp *dsp_opps;
-struct omap_opp *mpu_opps;
-struct omap_opp *l3_opps;
-
 /*
  * Device-driver-originated constraints (via board-*.c files)
  */

@@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device *dev)
 
 
 /* Should be called before clk framework init */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-				 struct omap_opp *dsp_opp_table,
-				 struct omap_opp *l3_opp_table)
+int __init omap_pm_if_early_init(void)
 {
-	mpu_opps = mpu_opp_table;
-	dsp_opps = dsp_opp_table;
-	l3_opps = l3_opp_table;
 	return 0;
 }

Signature · 1 line

1.6.3.3