[PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Nishanth Menon]

The following version 3 of the series arose from trying to use BeagleBoard-XM
(OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
generic cpufreq-cpu0 driver to be used in device tree enabled boot while
maintaining support of the legacy omap-cpufreq driver when used in non device
tree enabled boot.

However, in order to enable complete SoC entitlement for OMAP platforms, with
this series, key features are still pending on device tree adaptation for OMAP:
A) clock framework data transition to DT - this should happen soon, so this
series hacks the clock node for the time being as suggested in review of
original series[1].
B) On processors that use voltage controller, voltage processor (VC/VP hardware
loop using I2C_SR path) - we have started work on transitioning them to
regulator framework driven by DT.
C) Adaptive Body Bias and SmartReflex AVS conversion to DT. [2]

Note: At this point in time, we do not have DT entries for clock on OMAP
platforms. Common Clock Framework(CCF) could also control regulators[3].
Once these conversions are complete, there might be minimal cleanup work to
switch to the new data structure changes.

Key benefit of the series is to allow all relevant TI platforms now to use a
single cpufreq driver and equivalent frameworks in addition be part of the
transition to device tree.
NOTE: As a result of this series:
1. omap-cpufreq will be used only in non device tree boot scenario. we should
   delete this driver once the 100% DT conversion is complete.
2. Generic cpufreq-cpu0 will be used only in device tree boot scenario.
   boot systems.

Key changes in version 3:
	- series now rebased on Device tree patches queued for OMAP 3.10
	- DT patches introducing OPPs are now merged, so pending patches alone
	  are part of the new series.
	- omap-cpufreq is now converted to platform_device to address:
		http://marc.info/?t=136434901900001&r=1&w=2

version 2 of the series:
	http://marc.info/?t=136371570200003&r=1&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2

version 1 of the series:
	http://marc.info/?t=136329485400005&r=1&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1

[1] Original discussion thread which triggered this series:
	http://marc.info/?l=linux-pm&m=136304313700602&w=2
	https://patchwork.kernel.org/patch/2251841/
	https://patchwork.kernel.org/patch/2251851/
[2] ABB RFC: http://marc.info/?l=linux-omap&m=136449099409794&w=2 
[3] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/

Version 3 is now based on for-3.10/dts branch from Benoit:
	http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts
	d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node

Version 3 is also available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3
	git link: git://github.com/nmenon/linux-2.6-playground.git
	branch: cpufreq-cpu0-omap-all-v3

Test coverage:
	test script: http://pastebin.com/zrr8ptge
Platforms verified:
	beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/GVP2wDVr
	beagleboard (rev C1D) - OMAP3430 compatible
		- DT enabled boot: http://pastebin.com/2AY1F5Qa
		- No DT enabled boot: http://pastebin.com/hDk0gbpU
	omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/5tHAQcLZ
	Pandaboard -(OMAP4430 ES2.2) - http://pastebin.com/6D9aDPXT
	Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/ExrBEczr

Nishanth Menon (2):
  ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
  cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

 arch/arm/mach-omap2/board-generic.c   |    5 +++++
 arch/arm/mach-omap2/cclock33xx_data.c |    2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |    3 ++-
 arch/arm/mach-omap2/cclock44xx_data.c |    3 ++-
 arch/arm/mach-omap2/pm.c              |    9 +++++++++
 drivers/cpufreq/omap-cpufreq.c        |   19 ++++++++++++++-----
 6 files changed, 33 insertions(+), 8 deletions(-)

Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>

Regards,
Nishanth Menon
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Nishanth Menon]

The following version 3 of the series arose from trying to use BeagleBoard-XM
(OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
generic cpufreq-cpu0 driver to be used in device tree enabled boot while
maintaining support of the legacy omap-cpufreq driver when used in non device
tree enabled boot.

However, in order to enable complete SoC entitlement for OMAP platforms, with
this series, key features are still pending on device tree adaptation for OMAP:
A) clock framework data transition to DT - this should happen soon, so this
series hacks the clock node for the time being as suggested in review of
original series[1].
B) On processors that use voltage controller, voltage processor (VC/VP hardware
loop using I2C_SR path) - we have started work on transitioning them to
regulator framework driven by DT.
C) Adaptive Body Bias and SmartReflex AVS conversion to DT. [2]

Note: At this point in time, we do not have DT entries for clock on OMAP
platforms. Common Clock Framework(CCF) could also control regulators[3].
Once these conversions are complete, there might be minimal cleanup work to
switch to the new data structure changes.

Key benefit of the series is to allow all relevant TI platforms now to use a
single cpufreq driver and equivalent frameworks in addition be part of the
transition to device tree.
NOTE: As a result of this series:
1. omap-cpufreq will be used only in non device tree boot scenario. we should
   delete this driver once the 100% DT conversion is complete.
2. Generic cpufreq-cpu0 will be used only in device tree boot scenario.
   boot systems.

Key changes in version 3:
	- series now rebased on Device tree patches queued for OMAP 3.10
	- DT patches introducing OPPs are now merged, so pending patches alone
	  are part of the new series.
	- omap-cpufreq is now converted to platform_device to address:
		http://marc.info/?t=136434901900001&r=1&w=2

version 2 of the series:
	http://marc.info/?t=136371570200003&r=1&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2

version 1 of the series:
	http://marc.info/?t=136329485400005&r=1&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1

[1] Original discussion thread which triggered this series:
	http://marc.info/?l=linux-pm&m=136304313700602&w=2
	https://patchwork.kernel.org/patch/2251841/
	https://patchwork.kernel.org/patch/2251851/
[2] ABB RFC: http://marc.info/?l=linux-omap&m=136449099409794&w=2 
[3] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/

Version 3 is now based on for-3.10/dts branch from Benoit:
	http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts
	d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node

Version 3 is also available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3
	git link: git://github.com/nmenon/linux-2.6-playground.git
	branch: cpufreq-cpu0-omap-all-v3

Test coverage:
	test script: http://pastebin.com/zrr8ptge
Platforms verified:
	beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/GVP2wDVr
	beagleboard (rev C1D) - OMAP3430 compatible
		- DT enabled boot: http://pastebin.com/2AY1F5Qa
		- No DT enabled boot: http://pastebin.com/hDk0gbpU
	omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/5tHAQcLZ
	Pandaboard -(OMAP4430 ES2.2) - http://pastebin.com/6D9aDPXT
	Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/ExrBEczr

Nishanth Menon (2):
  ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
  cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

 arch/arm/mach-omap2/board-generic.c   |    5 +++++
 arch/arm/mach-omap2/cclock33xx_data.c |    2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |    3 ++-
 arch/arm/mach-omap2/cclock44xx_data.c |    3 ++-
 arch/arm/mach-omap2/pm.c              |    9 +++++++++
 drivers/cpufreq/omap-cpufreq.c        |   19 ++++++++++++++-----
 6 files changed, 33 insertions(+), 8 deletions(-)

Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>

Regards,
Nishanth Menon
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points defined, we can now use the SoC
generic cpufreq-cpu0 driver by registering appropriate device.

As part of this change, add dummy clock node to use cpufreq-cpu0.
This is an suggested solution till we have OMAP clock nodes in device
tree.
Once the OMAP device tree conversion is complete, we can then do:
clocks = <&dpll_mpu_ck>; or the SoC specific equivalent.

Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.

Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in v3:
	- modified CC list.
	- no functional change
V2: https://patchwork.kernel.org/patch/2303471/
V1: https://patchwork.kernel.org/patch/2273571/

 arch/arm/mach-omap2/board-generic.c   |    5 +++++
 arch/arm/mach-omap2/cclock33xx_data.c |    2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |    3 ++-
 arch/arm/mach-omap2/cclock44xx_data.c |    3 ++-
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
 		omap4_panda_display_init_of();
 	else if (of_machine_is_compatible("ti,omap4-sdp"))
 		omap_4430sdp_display_init_of();
+
+	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+		platform_device_register_full(&devinfo);
+	}
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..cf7e736 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
 	CLK(NULL,	"dpll_core_m5_ck",	&dpll_core_m5_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_core_m6_ck",	&dpll_core_m6_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_mpu_ck",		&dpll_mpu_ck,	CK_AM33XX),
-	CLK("cpu0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
+	CLK("cpufreq-cpu0.0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_mpu_m2_ck",	&dpll_mpu_m2_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_ddr_ck",		&dpll_ddr_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_ddr_m2_ck",	&dpll_ddr_m2_ck,	CK_AM33XX),
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..5a5b471 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
 	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
-	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
+	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX), /* used in non-device tree boot */
+	CLK("cpufreq-cpu0.0",	NULL,	&dpll1_ck,	CK_3XXX), /* used in device tree boot */
 };
 
 static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..bcea785 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,8 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
-	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
+	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X), /* used in non-device tree boot */
+	CLK("cpufreq-cpu0.0",	NULL,	&dpll_mpu_ck,	CK_443X), /* used in device tree boot */
 };
 
 int __init omap4xxx_clk_init(void)
-- 
1.7.9.5

[PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points defined, we can now use the SoC
generic cpufreq-cpu0 driver by registering appropriate device.

As part of this change, add dummy clock node to use cpufreq-cpu0.
This is an suggested solution till we have OMAP clock nodes in device
tree.
Once the OMAP device tree conversion is complete, we can then do:
clocks = <&dpll_mpu_ck>; or the SoC specific equivalent.

Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.

Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in v3:
	- modified CC list.
	- no functional change
V2: https://patchwork.kernel.org/patch/2303471/
V1: https://patchwork.kernel.org/patch/2273571/

 arch/arm/mach-omap2/board-generic.c   |    5 +++++
 arch/arm/mach-omap2/cclock33xx_data.c |    2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |    3 ++-
 arch/arm/mach-omap2/cclock44xx_data.c |    3 ++-
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
 		omap4_panda_display_init_of();
 	else if (of_machine_is_compatible("ti,omap4-sdp"))
 		omap_4430sdp_display_init_of();
+
+	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+		platform_device_register_full(&devinfo);
+	}
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..cf7e736 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
 	CLK(NULL,	"dpll_core_m5_ck",	&dpll_core_m5_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_core_m6_ck",	&dpll_core_m6_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_mpu_ck",		&dpll_mpu_ck,	CK_AM33XX),
-	CLK("cpu0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
+	CLK("cpufreq-cpu0.0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_mpu_m2_ck",	&dpll_mpu_m2_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_ddr_ck",		&dpll_ddr_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_ddr_m2_ck",	&dpll_ddr_m2_ck,	CK_AM33XX),
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..5a5b471 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
 	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
-	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
+	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX), /* used in non-device tree boot */
+	CLK("cpufreq-cpu0.0",	NULL,	&dpll1_ck,	CK_3XXX), /* used in device tree boot */
 };
 
 static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..bcea785 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,8 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
-	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
+	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X), /* used in non-device tree boot */
+	CLK("cpufreq-cpu0.0",	NULL,	&dpll_mpu_ck,	CK_443X), /* used in device tree boot */
 };
 
 int __init omap4xxx_clk_init(void)
-- 
1.7.9.5

[PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Nishanth Menon]

As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.

Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
"omap-cpufreq" device only when booted without device tree nodes on
OMAP platforms.

This allows the following:
a) Will only run on platforms that create the platform_device
   "omap-cpufreq".
b) Since the platform_device is registered only when device tree nodes
   are *not* populated, omap-cpufreq driver does not conflict with
   the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
   device tree nodes are present.

Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
[robherring2@gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in V3:
	- converted to platform_driver to
		address https://patchwork.kernel.org/patch/2303491/ as well
	- modified CC list.
V2: https://patchwork.kernel.org/patch/2303491/
V1: https://patchwork.kernel.org/patch/2273681/

 arch/arm/mach-omap2/pm.c       |    9 +++++++++
 drivers/cpufreq/omap-cpufreq.c |   19 ++++++++++++++-----
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 673a4c1..8d15f9a 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -265,6 +265,12 @@ static void __init omap4_init_voltages(void)
 	omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", "iva");
 }
 
+static inline void omap_init_cpufreq(void)
+{
+	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
+	platform_device_register_full(&devinfo);
+}
+
 static int __init omap2_common_pm_init(void)
 {
 	if (!of_have_populated_dt())
@@ -294,6 +300,9 @@ int __init omap2_common_pm_late_init(void)
 
 		/* Smartreflex device init */
 		omap_devinit_smartreflex();
+
+		/* cpufreq dummy device instantiation */
+		omap_init_cpufreq();
 	}
 
 #ifdef CONFIG_SUSPEND
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..d4f84b8 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -25,6 +25,7 @@
 #include <linux/opp.h>
 #include <linux/cpu.h>
 #include <linux/module.h>
+#include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
 
 #include <asm/smp_plat.h>
@@ -252,7 +253,7 @@ static struct cpufreq_driver omap_driver = {
 	.attr		= omap_cpufreq_attr,
 };
 
-static int __init omap_cpufreq_init(void)
+static int omap_cpufreq_probe(struct platform_device *pdev)
 {
 	mpu_dev = get_cpu_device(0);
 	if (!mpu_dev) {
@@ -280,12 +281,20 @@ static int __init omap_cpufreq_init(void)
 	return cpufreq_register_driver(&omap_driver);
 }
 
-static void __exit omap_cpufreq_exit(void)
+static int omap_cpufreq_remove(struct platform_device *pdev)
 {
-	cpufreq_unregister_driver(&omap_driver);
+	return cpufreq_unregister_driver(&omap_driver);
 }
 
+static struct platform_driver omap_cpufreq_platdrv = {
+	.driver = {
+		.name	= "omap-cpufreq",
+		.owner	= THIS_MODULE,
+	},
+	.probe		= omap_cpufreq_probe,
+	.remove		= omap_cpufreq_remove,
+};
+module_platform_driver(omap_cpufreq_platdrv);
+
 MODULE_DESCRIPTION("cpufreq driver for OMAP SoCs");
 MODULE_LICENSE("GPL");
-module_init(omap_cpufreq_init);
-module_exit(omap_cpufreq_exit);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Nishanth Menon]

As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.

Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
"omap-cpufreq" device only when booted without device tree nodes on
OMAP platforms.

This allows the following:
a) Will only run on platforms that create the platform_device
   "omap-cpufreq".
b) Since the platform_device is registered only when device tree nodes
   are *not* populated, omap-cpufreq driver does not conflict with
   the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
   device tree nodes are present.

Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
[robherring2@gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in V3:
	- converted to platform_driver to
		address https://patchwork.kernel.org/patch/2303491/ as well
	- modified CC list.
V2: https://patchwork.kernel.org/patch/2303491/
V1: https://patchwork.kernel.org/patch/2273681/

 arch/arm/mach-omap2/pm.c       |    9 +++++++++
 drivers/cpufreq/omap-cpufreq.c |   19 ++++++++++++++-----
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 673a4c1..8d15f9a 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -265,6 +265,12 @@ static void __init omap4_init_voltages(void)
 	omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", "iva");
 }
 
+static inline void omap_init_cpufreq(void)
+{
+	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
+	platform_device_register_full(&devinfo);
+}
+
 static int __init omap2_common_pm_init(void)
 {
 	if (!of_have_populated_dt())
@@ -294,6 +300,9 @@ int __init omap2_common_pm_late_init(void)
 
 		/* Smartreflex device init */
 		omap_devinit_smartreflex();
+
+		/* cpufreq dummy device instantiation */
+		omap_init_cpufreq();
 	}
 
 #ifdef CONFIG_SUSPEND
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..d4f84b8 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -25,6 +25,7 @@
 #include <linux/opp.h>
 #include <linux/cpu.h>
 #include <linux/module.h>
+#include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
 
 #include <asm/smp_plat.h>
@@ -252,7 +253,7 @@ static struct cpufreq_driver omap_driver = {
 	.attr		= omap_cpufreq_attr,
 };
 
-static int __init omap_cpufreq_init(void)
+static int omap_cpufreq_probe(struct platform_device *pdev)
 {
 	mpu_dev = get_cpu_device(0);
 	if (!mpu_dev) {
@@ -280,12 +281,20 @@ static int __init omap_cpufreq_init(void)
 	return cpufreq_register_driver(&omap_driver);
 }
 
-static void __exit omap_cpufreq_exit(void)
+static int omap_cpufreq_remove(struct platform_device *pdev)
 {
-	cpufreq_unregister_driver(&omap_driver);
+	return cpufreq_unregister_driver(&omap_driver);
 }
 
+static struct platform_driver omap_cpufreq_platdrv = {
+	.driver = {
+		.name	= "omap-cpufreq",
+		.owner	= THIS_MODULE,
+	},
+	.probe		= omap_cpufreq_probe,
+	.remove		= omap_cpufreq_remove,
+};
+module_platform_driver(omap_cpufreq_platdrv);
+
 MODULE_DESCRIPTION("cpufreq driver for OMAP SoCs");
 MODULE_LICENSE("GPL");
-module_init(omap_cpufreq_init);
-module_exit(omap_cpufreq_exit);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Viresh Kumar]

On Fri, Mar 29, 2013 at 3:22 AM, Nishanth Menon <nm@ti.com> wrote:
> As multi-platform build is being adopted by more and more ARM platforms,
> initcall function should be used very carefully.  For example, when
> CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
> will be called on all the platforms to initialize omap-cpufreq driver.
>
> Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
> tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
> for OMAP in a single image, we need to ensure the following:
> 1. With device tree boot, we use cpufreq-cpu0
> 2. With non device tree boot, we use omap-cpufreq
>
> In the case of (1), we will have cpu OPPs and regulator registered
> as part of the device tree nodes, to ensure that omap-cpufreq
> and cpufreq-cpu0 don't conflict in managing the frequency of the
> same CPU, we should not permit omap-cpufreq to be probed.
>
> In the case of (2), we will not have the cpufreq-cpu0 device, hence
> only omap-cpufreq will be active.
>
> To eliminate this undesired these effects, we change omap-cpufreq
> driver to have it instantiated as a platform_driver and register
> "omap-cpufreq" device only when booted without device tree nodes on
> OMAP platforms.
>
> This allows the following:
> a) Will only run on platforms that create the platform_device
>    "omap-cpufreq".
> b) Since the platform_device is registered only when device tree nodes
>    are *not* populated, omap-cpufreq driver does not conflict with
>    the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
>    device tree nodes are present.
>
> Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
> (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: "Benoît Cousson" <b-cousson@ti.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Cc: Keerthy <j-keerthy@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> [robherring2@gmail.com: reported conflict of omap-cpufreq vs other
> driver in an non-device tree supported boot]
> Reported-by: Rob Herring <robherring2@gmail.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Changes in V3:
>         - converted to platform_driver to
>                 address https://patchwork.kernel.org/patch/2303491/ as well
>         - modified CC list.
> V2: https://patchwork.kernel.org/patch/2303491/
> V1: https://patchwork.kernel.org/patch/2273681/
>
>  arch/arm/mach-omap2/pm.c       |    9 +++++++++
>  drivers/cpufreq/omap-cpufreq.c |   19 ++++++++++++++-----
>  2 files changed, 23 insertions(+), 5 deletions(-)

For cpufreq core:

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

Re: [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> The following version 3 of the series arose from trying to use BeagleBoard-XM
> (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
> generic cpufreq-cpu0 driver to be used in device tree enabled boot while
> maintaining support of the legacy omap-cpufreq driver when used in non device
> tree enabled boot.
>
> However, in order to enable complete SoC entitlement for OMAP platforms, with
> this series, key features are still pending on device tree adaptation for OMAP:
> A) clock framework data transition to DT - this should happen soon, so this
> series hacks the clock node for the time being as suggested in review of
> original series[1].
> B) On processors that use voltage controller, voltage processor (VC/VP hardware
> loop using I2C_SR path) - we have started work on transitioning them to
> regulator framework driven by DT.
> C) Adaptive Body Bias and SmartReflex AVS conversion to DT. [2]
>
> Note: At this point in time, we do not have DT entries for clock on OMAP
> platforms. Common Clock Framework(CCF) could also control regulators[3].
> Once these conversions are complete, there might be minimal cleanup work to
> switch to the new data structure changes.
>
> Key benefit of the series is to allow all relevant TI platforms now to use a
> single cpufreq driver and equivalent frameworks in addition be part of the
> transition to device tree.
> NOTE: As a result of this series:
> 1. omap-cpufreq will be used only in non device tree boot scenario. we should
>    delete this driver once the 100% DT conversion is complete.
> 2. Generic cpufreq-cpu0 will be used only in device tree boot scenario.
>    boot systems.

Yes, I like this direction better.  Thanks for reworking and thanks for
the thorough changelog.

> Key changes in version 3:
> 	- series now rebased on Device tree patches queued for OMAP 3.10
> 	- DT patches introducing OPPs are now merged, so pending patches alone
> 	  are part of the new series.
> 	- omap-cpufreq is now converted to platform_device to address:
> 		http://marc.info/?t=136434901900001&r=1&w=2
>
> version 2 of the series:
> 	http://marc.info/?t=136371570200003&r=1&w=2
> 	available at:
> 	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2
>
> version 1 of the series:
> 	http://marc.info/?t=136329485400005&r=1&w=2
> 	available at:
> 	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1
>
> [1] Original discussion thread which triggered this series:
> 	http://marc.info/?l=linux-pm&m=136304313700602&w=2
> 	https://patchwork.kernel.org/patch/2251841/
> 	https://patchwork.kernel.org/patch/2251851/
> [2] ABB RFC: http://marc.info/?l=linux-omap&m=136449099409794&w=2 
> [3] CCF DVFS patches:
> https://patchwork.kernel.org/patch/2195431/
> https://patchwork.kernel.org/patch/2195421/
> https://patchwork.kernel.org/patch/2195451/
> https://patchwork.kernel.org/patch/2195441/
> https://patchwork.kernel.org/patch/2195461/
>
> Version 3 is now based on for-3.10/dts branch from Benoit:
> 	http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts
> 	d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
>
> Version 3 is also available at:
> 	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3
> 	git link: git://github.com/nmenon/linux-2.6-playground.git
> 	branch: cpufreq-cpu0-omap-all-v3
>
> Test coverage:
> 	test script: http://pastebin.com/zrr8ptge
> Platforms verified:
> 	beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/GVP2wDVr
> 	beagleboard (rev C1D) - OMAP3430 compatible
> 		- DT enabled boot: http://pastebin.com/2AY1F5Qa
> 		- No DT enabled boot: http://pastebin.com/hDk0gbpU
> 	omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/5tHAQcLZ
> 	Pandaboard -(OMAP4430 ES2.2) - http://pastebin.com/6D9aDPXT
> 	Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/ExrBEczr

And thanks also for the broad testing.

One nit about the test report/coverage is I don't see any
test/verification that the voltage is still being scaled based on the DT
based OPPs.  It's easy to verify at least from the regulator PoV that
the voltage is scaled also.

My dumb DVFS test script (below) should work on any busybox rootfs 

Care to give that (or something like it) a try as well?  

With that extra confirmation of testing, I will queue up this series.

Thanks,

Kevin

[1]
#!/bin/sh

REG=`find /sys/class/regulator -follow -maxdepth 2 -name name -exec grep -l mpu {} \;`
mpu_reg=`echo $REG | cut -d'/' -f5`
echo MPU regulator: $mpu_reg

if [ ! -d /sys/devices/system/cpu/cpu0/cpufreq ]; then
  echo "CPUfreq not enabled in kernel."
  exit 0
fi

cd /sys/devices/system/cpu/cpu0/cpufreq
echo -n "Available frequencies: "
cat scaling_available_frequencies
echo -n "Current frequency: "
cat scaling_cur_freq
echo userspace > scaling_governor

for freq in `cat scaling_available_frequencies`; do
  echo ${freq} > scaling_setspeed
  echo -n "current freq: "
  cat scaling_cur_freq
  echo -n "current voltage: "
  cat /sys/class/regulator/${mpu_reg}/microvolts
  sleep 2
done

Re: [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Nishanth Menon]

On 10:47-20130403, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
[...]
> > Test coverage:
> > 	test script: http://pastebin.com/zrr8ptge
> > Platforms verified:
> > 	beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/GVP2wDVr
> > 	beagleboard (rev C1D) - OMAP3430 compatible
> > 		- DT enabled boot: http://pastebin.com/2AY1F5Qa
> > 		- No DT enabled boot: http://pastebin.com/hDk0gbpU
> > 	omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/5tHAQcLZ
> > 	Pandaboard -(OMAP4430 ES2.2) - http://pastebin.com/6D9aDPXT
> > 	Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/ExrBEczr
> 
> And thanks also for the broad testing.
> 
> One nit about the test report/coverage is I don't see any
> test/verification that the voltage is still being scaled based on the DT
> based OPPs.  It's easy to verify at least from the regulator PoV that
> the voltage is scaled also.
I had probed and verified voltage on beagle and beagle XM. OMAP4
obviously wont scale (as mentioned) due to the fact that vc-vp regulator
is needed.

> 
> My dumb DVFS test script (below) should work on any busybox rootfs 
thanks for the script. yep - I can use this as well, but given that probe
did verify voltage scale on TWL5030 inductors, it might be redundant.

Ref:
https://plus.google.com/photos/112464029509057661457/albums/5715034179943520193/5854221132322035042
I can take it again and show the same snap along with the log with the
mentioned script later today.

-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> With OMAP3+ and AM33xx supported SoC having defined CPU device tree
> entries with operating-points defined, we can now use the SoC
> generic cpufreq-cpu0 driver by registering appropriate device.
>
> As part of this change, add dummy clock node to use cpufreq-cpu0.
> This is an suggested solution till we have OMAP clock nodes in device
> tree.
> Once the OMAP device tree conversion is complete, we can then do:
> clocks = <&dpll_mpu_ck>; or the SoC specific equivalent.
> Inspired by patch: https://patchwork.kernel.org/patch/2067841/
> now made generic.
>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: "Benoît Cousson" <b-cousson@ti.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Cc: Keerthy <j-keerthy@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Nishanth Menon <nm@ti.com>

One more thought on this patch...
> ---
> Changes in v3:
> 	- modified CC list.
> 	- no functional change
> V2: https://patchwork.kernel.org/patch/2303471/
> V1: https://patchwork.kernel.org/patch/2273571/
>
>  arch/arm/mach-omap2/board-generic.c   |    5 +++++
>  arch/arm/mach-omap2/cclock33xx_data.c |    2 +-
>  arch/arm/mach-omap2/cclock3xxx_data.c |    3 ++-
>  arch/arm/mach-omap2/cclock44xx_data.c |    3 ++-
>  4 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index afa509a..5b147ef 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
>  		omap4_panda_display_init_of();
>  	else if (of_machine_is_compatible("ti,omap4-sdp"))
>  		omap_4430sdp_display_init_of();
> +
> +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> +		platform_device_register_full(&devinfo);
> +	}

Rather than adding new clkdev nodes below, how about using clk add_alias
here?

Kevin

>  }
>  
>  #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
> index 476b820..cf7e736 100644
> --- a/arch/arm/mach-omap2/cclock33xx_data.c
> +++ b/arch/arm/mach-omap2/cclock33xx_data.c
> @@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
>  	CLK(NULL,	"dpll_core_m5_ck",	&dpll_core_m5_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_core_m6_ck",	&dpll_core_m6_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_mpu_ck",		&dpll_mpu_ck,	CK_AM33XX),
> -	CLK("cpu0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
> +	CLK("cpufreq-cpu0.0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_mpu_m2_ck",	&dpll_mpu_m2_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_ddr_ck",		&dpll_ddr_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_ddr_m2_ck",	&dpll_ddr_m2_ck,	CK_AM33XX),
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 4579c3c..5a5b471 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
>  	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
>  	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
>  	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
> -	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
> +	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX), /* used in non-device tree boot */
> +	CLK("cpufreq-cpu0.0",	NULL,	&dpll1_ck,	CK_3XXX), /* used in device tree boot */
>  };
>  
>  static const char *enable_init_clks[] = {
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> index 3d58f33..bcea785 100644
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -1660,7 +1660,8 @@ static struct omap_clk omap44xx_clks[] = {
>  	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
>  	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
>  	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
> -	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
> +	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X), /* used in non-device tree boot */
> +	CLK("cpufreq-cpu0.0",	NULL,	&dpll_mpu_ck,	CK_443X), /* used in device tree boot */
>  };
>  
>  int __init omap4xxx_clk_init(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> With OMAP3+ and AM33xx supported SoC having defined CPU device tree
> entries with operating-points defined, we can now use the SoC
> generic cpufreq-cpu0 driver by registering appropriate device.
>
> As part of this change, add dummy clock node to use cpufreq-cpu0.
> This is an suggested solution till we have OMAP clock nodes in device
> tree.
> Once the OMAP device tree conversion is complete, we can then do:
> clocks = <&dpll_mpu_ck>; or the SoC specific equivalent.
> Inspired by patch: https://patchwork.kernel.org/patch/2067841/
> now made generic.
>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: "Benoît Cousson" <b-cousson@ti.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Cc: Keerthy <j-keerthy@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Nishanth Menon <nm@ti.com>

One more thought on this patch...
> ---
> Changes in v3:
> 	- modified CC list.
> 	- no functional change
> V2: https://patchwork.kernel.org/patch/2303471/
> V1: https://patchwork.kernel.org/patch/2273571/
>
>  arch/arm/mach-omap2/board-generic.c   |    5 +++++
>  arch/arm/mach-omap2/cclock33xx_data.c |    2 +-
>  arch/arm/mach-omap2/cclock3xxx_data.c |    3 ++-
>  arch/arm/mach-omap2/cclock44xx_data.c |    3 ++-
>  4 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index afa509a..5b147ef 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
>  		omap4_panda_display_init_of();
>  	else if (of_machine_is_compatible("ti,omap4-sdp"))
>  		omap_4430sdp_display_init_of();
> +
> +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> +		platform_device_register_full(&devinfo);
> +	}

Rather than adding new clkdev nodes below, how about using clk add_alias
here?

Kevin

>  }
>  
>  #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
> index 476b820..cf7e736 100644
> --- a/arch/arm/mach-omap2/cclock33xx_data.c
> +++ b/arch/arm/mach-omap2/cclock33xx_data.c
> @@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
>  	CLK(NULL,	"dpll_core_m5_ck",	&dpll_core_m5_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_core_m6_ck",	&dpll_core_m6_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_mpu_ck",		&dpll_mpu_ck,	CK_AM33XX),
> -	CLK("cpu0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
> +	CLK("cpufreq-cpu0.0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_mpu_m2_ck",	&dpll_mpu_m2_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_ddr_ck",		&dpll_ddr_ck,	CK_AM33XX),
>  	CLK(NULL,	"dpll_ddr_m2_ck",	&dpll_ddr_m2_ck,	CK_AM33XX),
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 4579c3c..5a5b471 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
>  	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
>  	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
>  	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
> -	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
> +	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX), /* used in non-device tree boot */
> +	CLK("cpufreq-cpu0.0",	NULL,	&dpll1_ck,	CK_3XXX), /* used in device tree boot */
>  };
>  
>  static const char *enable_init_clks[] = {
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> index 3d58f33..bcea785 100644
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -1660,7 +1660,8 @@ static struct omap_clk omap44xx_clks[] = {
>  	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
>  	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
>  	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
> -	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
> +	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X), /* used in non-device tree boot */
> +	CLK("cpufreq-cpu0.0",	NULL,	&dpll_mpu_ck,	CK_443X), /* used in device tree boot */
>  };
>  
>  int __init omap4xxx_clk_init(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On 11:47-20130403, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
> 
[...]
> > diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> > index afa509a..5b147ef 100644
> > --- a/arch/arm/mach-omap2/board-generic.c
> > +++ b/arch/arm/mach-omap2/board-generic.c
> > @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
> >  		omap4_panda_display_init_of();
> >  	else if (of_machine_is_compatible("ti,omap4-sdp"))
> >  		omap_4430sdp_display_init_of();
> > +
> > +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> > +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> > +		platform_device_register_full(&devinfo);
> > +	}
> 
> Rather than adding new clkdev nodes below, how about using clk add_alias
> here?
Thanks for pointing this out, I spend some time implementing such a
scheme and following is my opinion:

Summary:
There is one major problem which forces us to introduce this "clock
hack" - clock nodes are not in device tree yet. Yes, clock add alias
can be used (see option b,c,d..) - but the maintenance burden while we
transition into DT based clock node is just not worth the effort. The
current patch(option a) seems to be least of the compromise approaches
available, IMHO.

(testing example:
 options a, b, c all generate the log: http://pastebin.com/dJe7G9Q9
 with the updated test script: http://pastebin.com/c3ZiU2Ng (now prints
voltage as well))

So this means we have to be able to choose one of the available hacks:
option a) - add clock nodes in cclock_xyz_data.c
	the current patch under discussion.
Pros:
	- we keep board-generic.c intact
	- DT entries as needed example:
	clocks = <&dpll1>; can be used. So conversion of DT clock nodes
	and delete of cclock_xyz_data.c could be done in a smooth manner
	- we do can continue to support with the same code some TI
	platforms which have been transitioned to DT clock nodes, while
	in the same code others remain with _data.c and at the end of
	complete transition we dont need to cleanup code.
	- Allows us to have different DPLL names for controlling cpu0
	clock as SoC needs in DT/_data.c
Cons:
	yes, we have those ugly clock entries in clock_xyz_data.c files
	- but it anyways needs an HACK to work with current data files -
	why spread the hack around to other files and DT as well?

option b) using *only* clock alias cpufreq_ck
	http://pastebin.com/BHLNsfib
Pros:
	- we could maintain clock_xyz_data.c without much modification
Cons:
	- forced to maintain cpufreq_ck clock node even for DT
	conversion
	- tons of cleanup in code, DT entries to be done while we
	are in-transition and completion of transition to DT clock
	nodes.

option c) detect if clock node is populated, else use clock alias:
	http://pastebin.com/WpP8CSL8
Pros:
	- we could add DT nodes without cleanup later on.
Cons:
	- replicated code (which needs to be eventually cleaned up) just
	to detect cpu nodes with clock nodes registered
	- cleanup needs to be done anyways in 
Pros:
	- we could maintain clock_xyz_data.c without much modification
Cons:
	- forced to maintain cpufreq_ck clock node even for DT
	conversion
	- tons of cleanup in code, DT entries to be done while we
	are in-transition and completion of transition to DT clock
	nodes.

option d) pass the dummy pdev created for cpufreq to clock_xyz_data
init/ io.c early_init.
	I did not implement this, but is an theoretical possibility
	we create the clock nodes in early_init, yeah we could register
	the platform_device and pass the node over to clock_xyz_data as
	an option, but that just means we have to cleanup in more than
	one place now - board-generic, io.c, clock_xyz_data.c etc..

[...]
> > diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
> > index 4579c3c..5a5b471 100644
> > --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> > +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> > @@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
> >  	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
> >  	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
> >  	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
> > -	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
> > +	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX), /* used in non-device tree boot */
> > +	CLK("cpufreq-cpu0.0",	NULL,	&dpll1_ck,	CK_3XXX), /* used in device tree boot */
> >  };
[...]

-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Rajendra Nayak]

On Thursday 04 April 2013 08:22 AM, Nishanth Menon wrote:
> On 11:47-20130403, Kevin Hilman wrote:
>> Nishanth Menon <nm@ti.com> writes:
>>
> [...]
>>> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
>>> index afa509a..5b147ef 100644
>>> --- a/arch/arm/mach-omap2/board-generic.c
>>> +++ b/arch/arm/mach-omap2/board-generic.c
>>> @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
>>>  		omap4_panda_display_init_of();
>>>  	else if (of_machine_is_compatible("ti,omap4-sdp"))
>>>  		omap_4430sdp_display_init_of();
>>> +
>>> +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
>>> +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
>>> +		platform_device_register_full(&devinfo);
>>> +	}
>>
>> Rather than adding new clkdev nodes below, how about using clk add_alias
>> here?
> Thanks for pointing this out, I spend some time implementing such a
> scheme and following is my opinion:
> 
> Summary:
> There is one major problem which forces us to introduce this "clock
> hack" - clock nodes are not in device tree yet. Yes, clock add alias

There's already a patch floating around for this..
https://lkml.org/lkml/2013/4/2/84

> can be used (see option b,c,d..) - but the maintenance burden while we
> transition into DT based clock node is just not worth the effort. The
> current patch(option a) seems to be least of the compromise approaches
> available, IMHO.
> 
> (testing example:
>  options a, b, c all generate the log: http://pastebin.com/dJe7G9Q9
>  with the updated test script: http://pastebin.com/c3ZiU2Ng (now prints
> voltage as well))
> 
> So this means we have to be able to choose one of the available hacks:
> option a) - add clock nodes in cclock_xyz_data.c
> 	the current patch under discussion.
> Pros:
> 	- we keep board-generic.c intact
> 	- DT entries as needed example:
> 	clocks = <&dpll1>; can be used. So conversion of DT clock nodes
> 	and delete of cclock_xyz_data.c could be done in a smooth manner
> 	- we do can continue to support with the same code some TI
> 	platforms which have been transitioned to DT clock nodes, while
> 	in the same code others remain with _data.c and at the end of
> 	complete transition we dont need to cleanup code.
> 	- Allows us to have different DPLL names for controlling cpu0
> 	clock as SoC needs in DT/_data.c
> Cons:
> 	yes, we have those ugly clock entries in clock_xyz_data.c files
> 	- but it anyways needs an HACK to work with current data files -
> 	why spread the hack around to other files and DT as well?
> 
> option b) using *only* clock alias cpufreq_ck
> 	http://pastebin.com/BHLNsfib
> Pros:
> 	- we could maintain clock_xyz_data.c without much modification
> Cons:
> 	- forced to maintain cpufreq_ck clock node even for DT
> 	conversion
> 	- tons of cleanup in code, DT entries to be done while we
> 	are in-transition and completion of transition to DT clock
> 	nodes.
> 
> option c) detect if clock node is populated, else use clock alias:
> 	http://pastebin.com/WpP8CSL8
> Pros:
> 	- we could add DT nodes without cleanup later on.
> Cons:
> 	- replicated code (which needs to be eventually cleaned up) just
> 	to detect cpu nodes with clock nodes registered
> 	- cleanup needs to be done anyways in 
> Pros:
> 	- we could maintain clock_xyz_data.c without much modification
> Cons:
> 	- forced to maintain cpufreq_ck clock node even for DT
> 	conversion
> 	- tons of cleanup in code, DT entries to be done while we
> 	are in-transition and completion of transition to DT clock
> 	nodes.
> 
> option d) pass the dummy pdev created for cpufreq to clock_xyz_data
> init/ io.c early_init.
> 	I did not implement this, but is an theoretical possibility
> 	we create the clock nodes in early_init, yeah we could register
> 	the platform_device and pass the node over to clock_xyz_data as
> 	an option, but that just means we have to cleanup in more than
> 	one place now - board-generic, io.c, clock_xyz_data.c etc..
> 
> [...]
>>> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
>>> index 4579c3c..5a5b471 100644
>>> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
>>> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
>>> @@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
>>>  	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
>>>  	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
>>>  	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
>>> -	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
>>> +	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX), /* used in non-device tree boot */
>>> +	CLK("cpufreq-cpu0.0",	NULL,	&dpll1_ck,	CK_3XXX), /* used in device tree boot */
>>>  };
> [...]
> 

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On 10:43-20130404, Rajendra Nayak wrote:
> On Thursday 04 April 2013 08:22 AM, Nishanth Menon wrote:
> > On 11:47-20130403, Kevin Hilman wrote:
> >> Nishanth Menon <nm@ti.com> writes:
> >>
> > [...]
> >>> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> >>> index afa509a..5b147ef 100644
> >>> --- a/arch/arm/mach-omap2/board-generic.c
> >>> +++ b/arch/arm/mach-omap2/board-generic.c
> >>> @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
> >>>  		omap4_panda_display_init_of();
> >>>  	else if (of_machine_is_compatible("ti,omap4-sdp"))
> >>>  		omap_4430sdp_display_init_of();
> >>> +
> >>> +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> >>> +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> >>> +		platform_device_register_full(&devinfo);
> >>> +	}
> >>
> >> Rather than adding new clkdev nodes below, how about using clk add_alias
> >> here?
> > Thanks for pointing this out, I spend some time implementing such a
> > scheme and following is my opinion:
> > 
> > Summary:
> > There is one major problem which forces us to introduce this "clock
> > hack" - clock nodes are not in device tree yet. Yes, clock add alias
> 
> There's already a patch floating around for this..
> https://lkml.org/lkml/2013/4/2/84
Not really. Try on OMAP4 PandaBoard:
Based on
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts  d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
+ the patch https://patchwork.kernel.org/patch/2335671/ applied
Pandaboard 4 Log: http://pastebin.com/qsdsbv7p
The Patch does not even work, unless there is un-documented patch
dependencies!

Secondly, even if it did work, it would still continue to need yet another
hack[1] - I am agree with Tony in his discussion in
http://marc.info/?t=136370325600009&r=1&w=2

*if* we are moving clock to DT, we should move the data to DT as well -
similar to what other platforms do - highbank as far as i can quickly
see. (drivers/clk/clk-highbank.c and arch/arm/boot/dts/ecx-common.dtsi
as examples). Clk alias might have been a solution, but in this case,
clk add alias (as I indicated in this thread is not really worth the
effort for the mess of code it creates for cpu clock).

[1]
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index dd8f58f..9282b4c 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -635,4 +635,9 @@
 			ti,has-mailbox;
 		};
 	};
+
+	dpll_mpu: scrmclks {
+		compatible = "ti,omap4-clock";
+		#clock-cells = <1>;
+	};
 };
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..1587a5f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -21,6 +21,8 @@
 				800000  1313000
 				1008000 1375000
 			>;
+			clocks = <&dpll_mpu>;
+			clock-names = "cpu";
 			clock-latency = <300000>; /* From legacy driver */
 		};
 	};
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
 		omap4_panda_display_init_of();
 	else if (of_machine_is_compatible("ti,omap4-sdp"))
 		omap_4430sdp_display_init_of();
+
+	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+		platform_device_register_full(&devinfo);
+	}
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index a93617b..ba4562a 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1675,6 +1675,7 @@ static struct clk *dt_clks[] = {
 	&auxclk3_ck,
 	&auxclk4_ck,
 	&auxclk5_ck,
+	&dpll_mpu_ck,
 };
 
 static struct clk_onecell_data clock_data;

-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Rajendra Nayak]

On Friday 05 April 2013 12:30 AM, Nishanth Menon wrote:
> On 10:43-20130404, Rajendra Nayak wrote:
>> On Thursday 04 April 2013 08:22 AM, Nishanth Menon wrote:
>>> On 11:47-20130403, Kevin Hilman wrote:
>>>> Nishanth Menon <nm@ti.com> writes:
>>>>
>>> [...]
>>>>> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
>>>>> index afa509a..5b147ef 100644
>>>>> --- a/arch/arm/mach-omap2/board-generic.c
>>>>> +++ b/arch/arm/mach-omap2/board-generic.c
>>>>> @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
>>>>>  		omap4_panda_display_init_of();
>>>>>  	else if (of_machine_is_compatible("ti,omap4-sdp"))
>>>>>  		omap_4430sdp_display_init_of();
>>>>> +
>>>>> +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
>>>>> +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
>>>>> +		platform_device_register_full(&devinfo);
>>>>> +	}
>>>>
>>>> Rather than adding new clkdev nodes below, how about using clk add_alias
>>>> here?
>>> Thanks for pointing this out, I spend some time implementing such a
>>> scheme and following is my opinion:
>>>
>>> Summary:
>>> There is one major problem which forces us to introduce this "clock
>>> hack" - clock nodes are not in device tree yet. Yes, clock add alias
>>
>> There's already a patch floating around for this..
>> https://lkml.org/lkml/2013/4/2/84
> Not really. Try on OMAP4 PandaBoard:
> Based on
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
> for_3.10/dts  d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
> + the patch https://patchwork.kernel.org/patch/2335671/ applied
> Pandaboard 4 Log: http://pastebin.com/qsdsbv7p
> The Patch does not even work, unless there is un-documented patch
> dependencies!

I guess Roger responded to that.

> 
> Secondly, even if it did work, it would still continue to need yet another
> hack[1] 

Why do you think thats a hack? Besides I don't know if you are
doing it right.

- I am agree with Tony in his discussion in
> http://marc.info/?t=136370325600009&r=1&w=2
> 
> *if* we are moving clock to DT, we should move the data to DT as well -

I don't think Tony said 'move all clock data into DT'. He was suggesting
a combination of DT and /lib/firmware

> similar to what other platforms do - highbank as far as i can quickly
> see. (drivers/clk/clk-highbank.c and arch/arm/boot/dts/ecx-common.dtsi

Well, you chose to look at highbank (which has 8 clock nodes in DT, as
opposed to OMAP5 which has around 250 in kernel) why don't you also look at imx?
drivers/clk/mxs/clk-imx28.c and Documentation/devicetree/bindings/clock/imx28-clock.txt
for examples.
They have around 65 nodes (still way lesser than OMAP) and see what
they do. Thats exactly what Roger does in his patch.

regards,
Rajendra

> as examples). Clk alias might have been a solution, but in this case,
> clk add alias (as I indicated in this thread is not really worth the
> effort for the mess of code it creates for cpu clock).
> 
> [1]
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index dd8f58f..9282b4c 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -635,4 +635,9 @@
>  			ti,has-mailbox;
>  		};
>  	};
> +
> +	dpll_mpu: scrmclks {
> +		compatible = "ti,omap4-clock";
> +		#clock-cells = <1>;
> +	};
>  };
> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
> index cccf39a..1587a5f 100644
> --- a/arch/arm/boot/dts/omap443x.dtsi
> +++ b/arch/arm/boot/dts/omap443x.dtsi
> @@ -21,6 +21,8 @@
>  				800000  1313000
>  				1008000 1375000
>  			>;
> +			clocks = <&dpll_mpu>;
> +			clock-names = "cpu";
>  			clock-latency = <300000>; /* From legacy driver */
>  		};
>  	};
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index afa509a..5b147ef 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
>  		omap4_panda_display_init_of();
>  	else if (of_machine_is_compatible("ti,omap4-sdp"))
>  		omap_4430sdp_display_init_of();
> +
> +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> +		platform_device_register_full(&devinfo);
> +	}
>  }
>  
>  #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> index a93617b..ba4562a 100644
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -1675,6 +1675,7 @@ static struct clk *dt_clks[] = {
>  	&auxclk3_ck,
>  	&auxclk4_ck,
>  	&auxclk5_ck,
> +	&dpll_mpu_ck,
>  };
>  
>  static struct clk_onecell_data clock_data;
> 

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On Fri, Apr 5, 2013 at 4:50 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Friday 05 April 2013 12:30 AM, Nishanth Menon wrote:
>> On 10:43-20130404, Rajendra Nayak wrote:
>>> On Thursday 04 April 2013 08:22 AM, Nishanth Menon wrote:
>>>> On 11:47-20130403, Kevin Hilman wrote:
>>>>> Nishanth Menon <nm@ti.com> writes:
>>>>>
>>>> [...]
>>>>>> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
>>>>>> index afa509a..5b147ef 100644
>>>>>> --- a/arch/arm/mach-omap2/board-generic.c
>>>>>> +++ b/arch/arm/mach-omap2/board-generic.c
>>>>>> @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
>>>>>>           omap4_panda_display_init_of();
>>>>>>   else if (of_machine_is_compatible("ti,omap4-sdp"))
>>>>>>           omap_4430sdp_display_init_of();
>>>>>> +
>>>>>> + if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
>>>>>> +         struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
>>>>>> +         platform_device_register_full(&devinfo);
>>>>>> + }
>>>>>
>>>>> Rather than adding new clkdev nodes below, how about using clk add_alias
>>>>> here?
>>>> Thanks for pointing this out, I spend some time implementing such a
>>>> scheme and following is my opinion:
>>>>
>>>> Summary:
>>>> There is one major problem which forces us to introduce this "clock
>>>> hack" - clock nodes are not in device tree yet. Yes, clock add alias
>>>
>>> There's already a patch floating around for this..
>>> https://lkml.org/lkml/2013/4/2/84
>> Not really. Try on OMAP4 PandaBoard:
>> Based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
>> for_3.10/dts  d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
>> + the patch https://patchwork.kernel.org/patch/2335671/ applied
>> Pandaboard 4 Log: http://pastebin.com/qsdsbv7p
>> The Patch does not even work, unless there is un-documented patch
>> dependencies!
>
> I guess Roger responded to that.
yep, I am beyond that now :)
>
>>
>> Secondly, even if it did work, it would still continue to need yet another
>> hack[1]
>
> Why do you think thats a hack? Besides I don't know if you are
> doing it right.
traditionally, we state the following:
DT will represent actual hardware data.
what we are doing is the following:
DT has virtual clk nodes and kernel contains the actual data.

This is counter intuitive to the original idea of DT containing
hardware data - hence the notion, IMHO, of a hack.

>
> - I am agree with Tony in his discussion in
>> http://marc.info/?t=136370325600009&r=1&w=2
>>
>> *if* we are moving clock to DT, we should move the data to DT as well -
>
> I don't think Tony said 'move all clock data into DT'. He was suggesting
> a combination of DT and /lib/firmware
>
>> similar to what other platforms do - highbank as far as i can quickly
>> see. (drivers/clk/clk-highbank.c and arch/arm/boot/dts/ecx-common.dtsi
>
> Well, you chose to look at highbank (which has 8 clock nodes in DT, as
> opposed to OMAP5 which has around 250 in kernel) why don't you also look at imx?
> drivers/clk/mxs/clk-imx28.c and Documentation/devicetree/bindings/clock/imx28-clock.txt
> for examples.
> They have around 65 nodes (still way lesser than OMAP) and see what
> they do. Thats exactly what Roger does in his patch.
>

Precisely - thanks for highlighting my view - all the more reason for
us to move clock data out of kernel image :).
$ c_count arch/arm/mach-omap2/cclock*_data.c|tail -1
8110
$ wc -l arch/arm/mach-omap2/cclock*_data.c|tail -1
10310 total

that much code sitting in kernel makes it heavier for us(and others
working on clock framework code) -
we do also foresee that eventually dt data might move out to it's own
repository.

Further, maintaining dts vs kernel code compatibility aside, consider
adding new platforms - more code containing clock data that we have to
carry on in kernel - If we have !

I love the idea that Roger's patch does, as a *step #1* of
transitioning clock data out-of-kernel image and enabling drivers to
entitle DT based boot.

if this is the only step we will ever take, then it will be a
disappointing decision. whether the final data goes to /lib/firmware
or arch/arm/boot/dts - even though, I prefer it in dts, I have no
strong feelings about it.
However, we need to be prepared (at the earliest possible time) to
move that data out of kernel image as *step #2*.

Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [130405 04:31]:
> On Fri, Apr 5, 2013 at 4:50 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> > On Friday 05 April 2013 12:30 AM, Nishanth Menon wrote:
> > - I am agree with Tony in his discussion in
> >> http://marc.info/?t=136370325600009&r=1&w=2
> >>
> >> *if* we are moving clock to DT, we should move the data to DT as well -
> >
> > I don't think Tony said 'move all clock data into DT'. He was suggesting
> > a combination of DT and /lib/firmware

Yes that also covers the case of 100% DT clocks and 0% /lib/firmware
clocks if somebody wants that. But most usable combination would be:

1. Parent clocks allocated by the driver

2. Timer, serial, MMC, Ethernet and whatever is needed for mounting root
   clocks defined in DT

3. The rest of the clocs loaded from /lib/firmware

> >> similar to what other platforms do - highbank as far as i can quickly
> >> see. (drivers/clk/clk-highbank.c and arch/arm/boot/dts/ecx-common.dtsi
> >
> > Well, you chose to look at highbank (which has 8 clock nodes in DT, as
> > opposed to OMAP5 which has around 250 in kernel) why don't you also look at imx?
> > drivers/clk/mxs/clk-imx28.c and Documentation/devicetree/bindings/clock/imx28-clock.txt
> > for examples.
> > They have around 65 nodes (still way lesser than OMAP) and see what
> > they do. Thats exactly what Roger does in his patch.
> >
> 
> Precisely - thanks for highlighting my view - all the more reason for
> us to move clock data out of kernel image :).
> $ c_count arch/arm/mach-omap2/cclock*_data.c|tail -1
> 8110
> $ wc -l arch/arm/mach-omap2/cclock*_data.c|tail -1
> 10310 total
> 
> that much code sitting in kernel makes it heavier for us(and others
> working on clock framework code) -
> we do also foresee that eventually dt data might move out to it's own
> repository.

Yes we want to get rid of the large amounts of static data in the
kernel. It's just a constant source for flames, and I'm getting pretty
tired of that. We already did that with pinctrl-single.c for the mux
data, so it's cleary doable even with more complex data such as the
clock data or hwmod data.

BTW, regarding the legacy mux data, although we have not yet been able
to remove the legacy mux data, we have am33xx already using it, and can
drop the omap4 legacy mux data probably for v3.11.
 
> Further, maintaining dts vs kernel code compatibility aside, consider
> adding new platforms - more code containing clock data that we have to
> carry on in kernel - If we have !
> 
> I love the idea that Roger's patch does, as a *step #1* of
> transitioning clock data out-of-kernel image and enabling drivers to
> entitle DT based boot.
> 
> if this is the only step we will ever take, then it will be a
> disappointing decision. whether the final data goes to /lib/firmware
> or arch/arm/boot/dts - even though, I prefer it in dts, I have no
> strong feelings about it.
> However, we need to be prepared (at the earliest possible time) to
> move that data out of kernel image as *step #2*.

Yes agreed, Roger's approach is a good first step. It just needs to
be a proper device driver under drivers/clock/omap. Also note that
the /lib/firmware part is an additional step to the DT defined clocks,
but might actually make it easier to implement various PM related bits
than trying to map them as DT properties.

Regards,

Tony

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On 09:13-20130405, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [130405 04:31]:
> > On Fri, Apr 5, 2013 at 4:50 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> > > On Friday 05 April 2013 12:30 AM, Nishanth Menon wrote:
> > > - I am agree with Tony in his discussion in
> > >> http://marc.info/?t=136370325600009&r=1&w=2
> > >>
> > >> *if* we are moving clock to DT, we should move the data to DT as well -
> > >
> > Further, maintaining dts vs kernel code compatibility aside, consider
> > adding new platforms - more code containing clock data that we have to
> > carry on in kernel - If we have !
> > 
> > I love the idea that Roger's patch does, as a *step #1* of
> > transitioning clock data out-of-kernel image and enabling drivers to
> > entitle DT based boot.
> > 
> > if this is the only step we will ever take, then it will be a
> > disappointing decision. whether the final data goes to /lib/firmware
> > or arch/arm/boot/dts - even though, I prefer it in dts, I have no
> > strong feelings about it.
> > However, we need to be prepared (at the earliest possible time) to
> > move that data out of kernel image as *step #2*.
> 
> Yes agreed, Roger's approach is a good first step. It just needs to
> be a proper device driver under drivers/clock/omap. Also note that
> the /lib/firmware part is an additional step to the DT defined clocks,
> but might actually make it easier to implement various PM related bits
> than trying to map them as DT properties.

on the first step angle,
Applying current approach that Roger has taken:
Benoit's tree:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts  d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
+:
https://patchwork.kernel.org/patch/2312211/
https://patchwork.kernel.org/patch/2335671/
And the diff below[1] as replacement for this patch - does indeed work on
PandaBoard. Now the question is which direction should I take - will
wait on decision in https://lkml.org/lkml/2013/4/5/173 thread.
I have similar issues: clock alias is a mess of a code to cleanup and keep alive
for mpu dplls - I have posted on this mail thread various variants of trying to
do this - there is no simple solution.

If we cannot go any further, we are essentially stalled on moving
cpufreq (OPP entries along with it, regulators, voltage ....) to device
tree.

[1]
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..1fddb1e 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -21,6 +21,8 @@
 				800000  1313000
 				1008000 1375000
 			>;
+			clocks = <&clks 6>;
+			clock-names = "cpu";
 			clock-latency = <300000>; /* From legacy driver */
 		};
 	};
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
 		omap4_panda_display_init_of();
 	else if (of_machine_is_compatible("ti,omap4-sdp"))
 		omap_4430sdp_display_init_of();
+
+	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+		platform_device_register_full(&devinfo);
+	}
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index a93617b..54530d0 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1675,6 +1675,7 @@ static struct clk *dt_clks[] = {
 	&auxclk3_ck,
 	&auxclk4_ck,
 	&auxclk5_ck,
+	&dpll_mpu_ck,
 };
 
 static struct clk_onecell_data clock_data;
-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [130405 09:37]:
> 
> on the first step angle,
> Applying current approach that Roger has taken:
> Benoit's tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
> for_3.10/dts  d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
> +:
> https://patchwork.kernel.org/patch/2312211/
> https://patchwork.kernel.org/patch/2335671/
> And the diff below[1] as replacement for this patch - does indeed work on
> PandaBoard. Now the question is which direction should I take - will
> wait on decision in https://lkml.org/lkml/2013/4/5/173 thread.

No need to wait AFAIK :) It seems we can already work on this:

1. Limit the DT clock use to the standard binding as defined in
   the Documentation/devicetree/bindings/clock/clock-bindings.txt
   until we have a clear plan of the possible additional bindings
   needed

2. Do a minimal drivers/clock/omap driver that remaps the bindings
   to the existing clocks. It seems that Roger already has all
   the code, it just needs to become a proper driver

> I have similar issues: clock alias is a mess of a code to cleanup and keep alive
> for mpu dplls - I have posted on this mail thread various variants of trying to
> do this - there is no simple solution.

I can see an issue there if the clocks are board specific, but
what's the clock alias issue with mpu dplls?
 
> If we cannot go any further, we are essentially stalled on moving
> cpufreq (OPP entries along with it, regulators, voltage ....) to device
> tree.

Heh I doubt that :)
 
> [1]
> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
> index cccf39a..1fddb1e 100644
> --- a/arch/arm/boot/dts/omap443x.dtsi
> +++ b/arch/arm/boot/dts/omap443x.dtsi
> @@ -21,6 +21,8 @@
>  				800000  1313000
>  				1008000 1375000
>  			>;
> +			clocks = <&clks 6>;
> +			clock-names = "cpu";
>  			clock-latency = <300000>; /* From legacy driver */
>  		};
>  	};

So the clock-latency is non-standard here, but that's a
separate issue.

> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index afa509a..5b147ef 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
>  		omap4_panda_display_init_of();
>  	else if (of_machine_is_compatible("ti,omap4-sdp"))
>  		omap_4430sdp_display_init_of();
> +
> +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> +		platform_device_register_full(&devinfo);
> +	}
>  }

Hmm why would the driver need this? Sounds like the driver is
missing support for DT?
  
>  #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> index a93617b..54530d0 100644
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -1675,6 +1675,7 @@ static struct clk *dt_clks[] = {
>  	&auxclk3_ck,
>  	&auxclk4_ck,
>  	&auxclk5_ck,
> +	&dpll_mpu_ck,
>  };
>  
>  static struct clk_onecell_data clock_data;

The dt_clks[] should be something that's allocated in the
driver/clock/omap driver, let's not stuff that into
cclock44xx_data.c.

Regards,

Tony

Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Nishanth Menon]

On 08:29-20130329, Viresh Kumar wrote:
> On Fri, Mar 29, 2013 at 3:22 AM, Nishanth Menon <nm@ti.com> wrote:
> > As multi-platform build is being adopted by more and more ARM platforms,
> > initcall function should be used very carefully.  For example, when
> > CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
> > will be called on all the platforms to initialize omap-cpufreq driver.
> >
> > Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
> > tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
> > for OMAP in a single image, we need to ensure the following:
> > 1. With device tree boot, we use cpufreq-cpu0
> > 2. With non device tree boot, we use omap-cpufreq
> >
> > In the case of (1), we will have cpu OPPs and regulator registered
> > as part of the device tree nodes, to ensure that omap-cpufreq
> > and cpufreq-cpu0 don't conflict in managing the frequency of the
> > same CPU, we should not permit omap-cpufreq to be probed.
> >
> > In the case of (2), we will not have the cpufreq-cpu0 device, hence
> > only omap-cpufreq will be active.
> >
> > To eliminate this undesired these effects, we change omap-cpufreq
> > driver to have it instantiated as a platform_driver and register
> > "omap-cpufreq" device only when booted without device tree nodes on
> > OMAP platforms.
> >
> > This allows the following:
> > a) Will only run on platforms that create the platform_device
> >    "omap-cpufreq".
> > b) Since the platform_device is registered only when device tree nodes
> >    are *not* populated, omap-cpufreq driver does not conflict with
> >    the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
> >    device tree nodes are present.
> >
> > Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
> > (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
> >
> > Cc: Kevin Hilman <khilman@linaro.org>
> > Cc: Rajendra Nayak <rnayak@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Cc: "Benoît Cousson" <b-cousson@ti.com>
> > Cc: Jon Hunter <jon-hunter@ti.com>
> > Cc: Keerthy <j-keerthy@ti.com>
> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > [robherring2@gmail.com: reported conflict of omap-cpufreq vs other
> > driver in an non-device tree supported boot]
> > Reported-by: Rob Herring <robherring2@gmail.com>
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > ---
> > Changes in V3:
> >         - converted to platform_driver to
> >                 address https://patchwork.kernel.org/patch/2303491/ as well
> >         - modified CC list.
> > V2: https://patchwork.kernel.org/patch/2303491/
> > V1: https://patchwork.kernel.org/patch/2273681/
> >
> >  arch/arm/mach-omap2/pm.c       |    9 +++++++++
> >  drivers/cpufreq/omap-cpufreq.c |   19 ++++++++++++++-----
> >  2 files changed, 23 insertions(+), 5 deletions(-)
> 
> For cpufreq core:
> 
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Since this patch could be merged independently to help multi-platform
builds, While the omap community discusses:
http://marc.info/?t=136450773400004&r=1&w=2
http://marc.info/?t=136370325600009&r=1&w=2&n=7

To enable cpufreq-cpu0 driver in DT mode, I wonder if we could queue this up
for 3.10.
-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On 10:05-20130405, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [130405 09:37]:
> > 
> > on the first step angle,
> > Applying current approach that Roger has taken:
> > Benoit's tree:
> > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
> > for_3.10/dts  d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
> > +:
> > https://patchwork.kernel.org/patch/2312211/
> > https://patchwork.kernel.org/patch/2335671/
> > And the diff below[1] as replacement for this patch - does indeed work on
> > PandaBoard. Now the question is which direction should I take - will
> > wait on decision in https://lkml.org/lkml/2013/4/5/173 thread.
> 
> No need to wait AFAIK :) It seems we can already work on this:
/me perks ears :)
> 
> 1. Limit the DT clock use to the standard binding as defined in
>    the Documentation/devicetree/bindings/clock/clock-bindings.txt
>    until we have a clear plan of the possible additional bindings
>    needed
> 
> 2. Do a minimal drivers/clock/omap driver that remaps the bindings
>    to the existing clocks. It seems that Roger already has all
>    the code, it just needs to become a proper driver
Cool, I can afford to wait for it if that is what I should build upon.
> 
> > I have similar issues: clock alias is a mess of a code to cleanup and keep alive
> > for mpu dplls - I have posted on this mail thread various variants of trying to
> > do this - there is no simple solution.
> 
> I can see an issue there if the clocks are board specific, but
> what's the clock alias issue with mpu dplls?
I highlighted it on this thread here:
http://marc.info/?l=linux-pm&m=136504393718316&w=2
>  
> > If we cannot go any further, we are essentially stalled on moving
> > cpufreq (OPP entries along with it, regulators, voltage ....) to device
> > tree.
> 
> Heh I doubt that :)
I have to go top bottom -> do the entire dvfs track to be of any use..
I have already started an thread for voltage using regulator chaining
here http://marc.info/?t=136513865200005&r=1&w=2 
- need to dig in more and bring it along as well..
>  
> > [1]
> > diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
> > index cccf39a..1fddb1e 100644
> > --- a/arch/arm/boot/dts/omap443x.dtsi
> > +++ b/arch/arm/boot/dts/omap443x.dtsi
> > @@ -21,6 +21,8 @@
> >  				800000  1313000
> >  				1008000 1375000
> >  			>;
> > +			clocks = <&clks 6>;
> > +			clock-names = "cpu";
> >  			clock-latency = <300000>; /* From legacy driver */
> >  		};
> >  	};
> 
> So the clock-latency is non-standard here, but that's a
> separate issue.
yep.
> 
> > diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> > index afa509a..5b147ef 100644
> > --- a/arch/arm/mach-omap2/board-generic.c
> > +++ b/arch/arm/mach-omap2/board-generic.c
> > @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
> >  		omap4_panda_display_init_of();
> >  	else if (of_machine_is_compatible("ti,omap4-sdp"))
> >  		omap_4430sdp_display_init_of();
> > +
> > +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> > +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> > +		platform_device_register_full(&devinfo);
> > +	}
> >  }
> 
> Hmm why would the driver need this? Sounds like the driver is
> missing support for DT?
Nope, this was a long chain of discussion in previous iterations of this
patch.. more or less started here:
https://patchwork.kernel.org/patch/2251821/
Suggested as the generic approach for cpufreq drivers.
Paul questioned this approach in:
http://marc.info/?l=linux-pm&m=136485349218809&w=2
>   
> >  #ifdef CONFIG_SOC_OMAP2420
> > diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> > index a93617b..54530d0 100644
> > --- a/arch/arm/mach-omap2/cclock44xx_data.c
> > +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> > @@ -1675,6 +1675,7 @@ static struct clk *dt_clks[] = {
> >  	&auxclk3_ck,
> >  	&auxclk4_ck,
> >  	&auxclk5_ck,
> > +	&dpll_mpu_ck,
> >  };
> >  
> >  static struct clk_onecell_data clock_data;
> 
> The dt_clks[] should be something that's allocated in the
> driver/clock/omap driver, let's not stuff that into
> cclock44xx_data.c.
I agree, I dont like it either - just following Roger's hint here.

-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [130405 10:22]:
> On 10:05-20130405, Tony Lindgren wrote:
> > 
> > > diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> > > index afa509a..5b147ef 100644
> > > --- a/arch/arm/mach-omap2/board-generic.c
> > > +++ b/arch/arm/mach-omap2/board-generic.c
> > > @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
> > >  		omap4_panda_display_init_of();
> > >  	else if (of_machine_is_compatible("ti,omap4-sdp"))
> > >  		omap_4430sdp_display_init_of();
> > > +
> > > +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> > > +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> > > +		platform_device_register_full(&devinfo);
> > > +	}
> > >  }
> > 
> > Hmm why would the driver need this? Sounds like the driver is
> > missing support for DT?
> Nope, this was a long chain of discussion in previous iterations of this
> patch.. more or less started here:
> https://patchwork.kernel.org/patch/2251821/
> Suggested as the generic approach for cpufreq drivers.
> Paul questioned this approach in:
> http://marc.info/?l=linux-pm&m=136485349218809&w=2

How about just set it up in omap2_common_pm_init instead
of the board-generic?

Regards,

Tony

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On 12:28-20130405, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [130405 10:22]:
> > On 10:05-20130405, Tony Lindgren wrote:
> > > 
> > > > diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> > > > index afa509a..5b147ef 100644
> > > > --- a/arch/arm/mach-omap2/board-generic.c
> > > > +++ b/arch/arm/mach-omap2/board-generic.c
> > > > @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
> > > >  		omap4_panda_display_init_of();
> > > >  	else if (of_machine_is_compatible("ti,omap4-sdp"))
> > > >  		omap_4430sdp_display_init_of();
> > > > +
> > > > +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> > > > +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> > > > +		platform_device_register_full(&devinfo);
> > > > +	}
> > > >  }
> > > 
> > > Hmm why would the driver need this? Sounds like the driver is
> > > missing support for DT?
> > Nope, this was a long chain of discussion in previous iterations of this
> > patch.. more or less started here:
> > https://patchwork.kernel.org/patch/2251821/
> > Suggested as the generic approach for cpufreq drivers.
> > Paul questioned this approach in:
> > http://marc.info/?l=linux-pm&m=136485349218809&w=2
> 
> How about just set it up in omap2_common_pm_init instead
> of the board-generic?
umm.. We want to eventually want to get rid of mach-omap2/pm.c (all
those create processor devices etc should go away with proper
representation of devices as nodes in DT if possible.
But, I think you mean something like in the "else" condition of
https://patchwork.kernel.org/patch/2359711/ ? - I'd again have the same
request of not having anything to do with pm.c and keeping as little as
possible for all TI processors in mach-omap2.

Could you enlighten me about why you'd not like it in board-generic.c?
will creating an function ti_generic_cpufreq_init() in board-generic.c
and calling it from omap_generic_init help?

-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [130405 13:06]:
> On 12:28-20130405, Tony Lindgren wrote:
> > * Nishanth Menon <nm@ti.com> [130405 10:22]:
> > > On 10:05-20130405, Tony Lindgren wrote:
> > > > 
> > > > > diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> > > > > index afa509a..5b147ef 100644
> > > > > --- a/arch/arm/mach-omap2/board-generic.c
> > > > > +++ b/arch/arm/mach-omap2/board-generic.c
> > > > > @@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
> > > > >  		omap4_panda_display_init_of();
> > > > >  	else if (of_machine_is_compatible("ti,omap4-sdp"))
> > > > >  		omap_4430sdp_display_init_of();
> > > > > +
> > > > > +	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> > > > > +		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> > > > > +		platform_device_register_full(&devinfo);
> > > > > +	}
> > > > >  }
> > > > 
> > > > Hmm why would the driver need this? Sounds like the driver is
> > > > missing support for DT?
> > > Nope, this was a long chain of discussion in previous iterations of this
> > > patch.. more or less started here:
> > > https://patchwork.kernel.org/patch/2251821/
> > > Suggested as the generic approach for cpufreq drivers.
> > > Paul questioned this approach in:
> > > http://marc.info/?l=linux-pm&m=136485349218809&w=2
> > 
> > How about just set it up in omap2_common_pm_init instead
> > of the board-generic?
> umm.. We want to eventually want to get rid of mach-omap2/pm.c (all
> those create processor devices etc should go away with proper
> representation of devices as nodes in DT if possible.
> But, I think you mean something like in the "else" condition of
> https://patchwork.kernel.org/patch/2359711/ ? - I'd again have the same
> request of not having anything to do with pm.c and keeping as little as
> possible for all TI processors in mach-omap2.
> 
> Could you enlighten me about why you'd not like it in board-generic.c?
> will creating an function ti_generic_cpufreq_init() in board-generic.c
> and calling it from omap_generic_init help?

I'd like to keep board-generic.c down to minimum. Can't you
set it up in omap_init_cpufreq() in your second patch of this
series?

Regards,

Tony

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On 14:10-20130405, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [130405 13:06]:
> > On 12:28-20130405, Tony Lindgren wrote:
[...]
> > > How about just set it up in omap2_common_pm_init instead
> > > of the board-generic?
> > umm.. We want to eventually want to get rid of mach-omap2/pm.c (all
> > those create processor devices etc should go away with proper
> > representation of devices as nodes in DT if possible.
> > But, I think you mean something like in the "else" condition of
> > https://patchwork.kernel.org/patch/2359711/ ? - I'd again have the same
> > request of not having anything to do with pm.c and keeping as little as
> > possible for all TI processors in mach-omap2.
> > 
> > Could you enlighten me about why you'd not like it in board-generic.c?
> > will creating an function ti_generic_cpufreq_init() in board-generic.c
> > and calling it from omap_generic_init help?
> 
> I'd like to keep board-generic.c down to minimum. Can't you
> set it up in omap_init_cpufreq() in your second patch of this
> series?
Thanks. That seems to be a better compromise. Will do. I can sequence patch
[2] above the current patch[1] if there is a need to fix multi-arch builds
for 3.9: in that case I will probably leave the current [2] patch as
is, and once our clock representation discussion is done, the rev 4 of
the patch [1], I can do the following:
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 8d15f9a..b250689 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -267,8 +267,14 @@ static void __init omap4_init_voltages(void)
 
 static inline void omap_init_cpufreq(void)
 {
-	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
-	platform_device_register_full(&devinfo);
+	struct platform_device_info devinfo = { .name = "omap-cpufreq", }
+
+	if (!of_have_populated_dt()) {
+		platform_device_register_full(&devinfo);
+	} else if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+		devinfo.name = "cpufreq-cpu0"
+		platform_device_register_full(&devinfo);
+	}
 }
 
 static int __init omap2_common_pm_init(void)
@@ -301,9 +307,9 @@ int __init omap2_common_pm_late_init(void)
 		/* Smartreflex device init */
 		omap_devinit_smartreflex();
 
-		/* cpufreq dummy device instantiation */
-		omap_init_cpufreq();
 	}
+	/* cpufreq dummy device instantiation */
+	omap_init_cpufreq();
 
 #ifdef CONFIG_SUSPEND
 	suspend_set_ops(&omap_pm_ops);
[1] https://patchwork.kernel.org/patch/2399201/
[2] https://patchwork.kernel.org/patch/2359711/
-- 
Regards,
Nishanth Menon

Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> On 08:29-20130329, Viresh Kumar wrote:
>> On Fri, Mar 29, 2013 at 3:22 AM, Nishanth Menon <nm@ti.com> wrote:
>> > As multi-platform build is being adopted by more and more ARM platforms,
>> > initcall function should be used very carefully.  For example, when
>> > CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
>> > will be called on all the platforms to initialize omap-cpufreq driver.
>> >
>> > Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
>> > tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
>> > for OMAP in a single image, we need to ensure the following:
>> > 1. With device tree boot, we use cpufreq-cpu0
>> > 2. With non device tree boot, we use omap-cpufreq
>> >
>> > In the case of (1), we will have cpu OPPs and regulator registered
>> > as part of the device tree nodes, to ensure that omap-cpufreq
>> > and cpufreq-cpu0 don't conflict in managing the frequency of the
>> > same CPU, we should not permit omap-cpufreq to be probed.
>> >
>> > In the case of (2), we will not have the cpufreq-cpu0 device, hence
>> > only omap-cpufreq will be active.
>> >
>> > To eliminate this undesired these effects, we change omap-cpufreq
>> > driver to have it instantiated as a platform_driver and register
>> > "omap-cpufreq" device only when booted without device tree nodes on
>> > OMAP platforms.
>> >
>> > This allows the following:
>> > a) Will only run on platforms that create the platform_device
>> >    "omap-cpufreq".
>> > b) Since the platform_device is registered only when device tree nodes
>> >    are *not* populated, omap-cpufreq driver does not conflict with
>> >    the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
>> >    device tree nodes are present.
>> >
>> > Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
>> > (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
>> >
>> > Cc: Kevin Hilman <khilman@linaro.org>
>> > Cc: Rajendra Nayak <rnayak@ti.com>
>> > Cc: Paul Walmsley <paul@pwsan.com>
>> > Cc: "Benoît Cousson" <b-cousson@ti.com>
>> > Cc: Jon Hunter <jon-hunter@ti.com>
>> > Cc: Keerthy <j-keerthy@ti.com>
>> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > Cc: Shawn Guo <shawn.guo@linaro.org>
>> > [robherring2@gmail.com: reported conflict of omap-cpufreq vs other
>> > driver in an non-device tree supported boot]
>> > Reported-by: Rob Herring <robherring2@gmail.com>
>> > Signed-off-by: Nishanth Menon <nm@ti.com>
>> > ---
>> > Changes in V3:
>> >         - converted to platform_driver to
>> >                 address https://patchwork.kernel.org/patch/2303491/ as well
>> >         - modified CC list.
>> > V2: https://patchwork.kernel.org/patch/2303491/
>> > V1: https://patchwork.kernel.org/patch/2273681/
>> >
>> >  arch/arm/mach-omap2/pm.c       |    9 +++++++++
>> >  drivers/cpufreq/omap-cpufreq.c |   19 ++++++++++++++-----
>> >  2 files changed, 23 insertions(+), 5 deletions(-)
>> 
>> For cpufreq core:
>> 
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Since this patch could be merged independently to help multi-platform
> builds, While the omap community discusses:
> http://marc.info/?t=136450773400004&r=1&w=2
> http://marc.info/?t=136370325600009&r=1&w=2&n=7
>
> To enable cpufreq-cpu0 driver in DT mode, I wonder if we could queue this up
> for 3.10.

Yes, I've queued this one for v3.10.  Working on getting some pull
requests out to Tony today.

Kevin

Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> On 08:29-20130329, Viresh Kumar wrote:
>> On Fri, Mar 29, 2013 at 3:22 AM, Nishanth Menon <nm@ti.com> wrote:
>> > As multi-platform build is being adopted by more and more ARM platforms,
>> > initcall function should be used very carefully.  For example, when
>> > CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
>> > will be called on all the platforms to initialize omap-cpufreq driver.
>> >
>> > Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
>> > tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
>> > for OMAP in a single image, we need to ensure the following:
>> > 1. With device tree boot, we use cpufreq-cpu0
>> > 2. With non device tree boot, we use omap-cpufreq
>> >
>> > In the case of (1), we will have cpu OPPs and regulator registered
>> > as part of the device tree nodes, to ensure that omap-cpufreq
>> > and cpufreq-cpu0 don't conflict in managing the frequency of the
>> > same CPU, we should not permit omap-cpufreq to be probed.
>> >
>> > In the case of (2), we will not have the cpufreq-cpu0 device, hence
>> > only omap-cpufreq will be active.
>> >
>> > To eliminate this undesired these effects, we change omap-cpufreq
>> > driver to have it instantiated as a platform_driver and register
>> > "omap-cpufreq" device only when booted without device tree nodes on
>> > OMAP platforms.
>> >
>> > This allows the following:
>> > a) Will only run on platforms that create the platform_device
>> >    "omap-cpufreq".
>> > b) Since the platform_device is registered only when device tree nodes
>> >    are *not* populated, omap-cpufreq driver does not conflict with
>> >    the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
>> >    device tree nodes are present.
>> >
>> > Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
>> > (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
>> >
>> > Cc: Kevin Hilman <khilman@linaro.org>
>> > Cc: Rajendra Nayak <rnayak@ti.com>
>> > Cc: Paul Walmsley <paul@pwsan.com>
>> > Cc: "Benoît Cousson" <b-cousson@ti.com>
>> > Cc: Jon Hunter <jon-hunter@ti.com>
>> > Cc: Keerthy <j-keerthy@ti.com>
>> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > Cc: Shawn Guo <shawn.guo@linaro.org>
>> > [robherring2@gmail.com: reported conflict of omap-cpufreq vs other
>> > driver in an non-device tree supported boot]
>> > Reported-by: Rob Herring <robherring2@gmail.com>
>> > Signed-off-by: Nishanth Menon <nm@ti.com>
>> > ---
>> > Changes in V3:
>> >         - converted to platform_driver to
>> >                 address https://patchwork.kernel.org/patch/2303491/ as well
>> >         - modified CC list.
>> > V2: https://patchwork.kernel.org/patch/2303491/
>> > V1: https://patchwork.kernel.org/patch/2273681/
>> >
>> >  arch/arm/mach-omap2/pm.c       |    9 +++++++++
>> >  drivers/cpufreq/omap-cpufreq.c |   19 ++++++++++++++-----
>> >  2 files changed, 23 insertions(+), 5 deletions(-)
>> 
>> For cpufreq core:
>> 
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Since this patch could be merged independently to help multi-platform
> builds, While the omap community discusses:
> http://marc.info/?t=136450773400004&r=1&w=2
> http://marc.info/?t=136370325600009&r=1&w=2&n=7
>
> To enable cpufreq-cpu0 driver in DT mode, I wonder if we could queue this up
> for 3.10.

Yes, I've queued this one for v3.10.  Working on getting some pull
requests out to Tony today.

Kevin

Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Nishanth Menon]

On 14:34-20130405, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
> 
> > On 08:29-20130329, Viresh Kumar wrote:
> >> On Fri, Mar 29, 2013 at 3:22 AM, Nishanth Menon <nm@ti.com> wrote:
[...]
> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Since this patch could be merged independently to help multi-platform
> > builds, While the omap community discusses:
> > http://marc.info/?t=136450773400004&r=1&w=2
> > http://marc.info/?t=136370325600009&r=1&w=2&n=7
> >
> > To enable cpufreq-cpu0 driver in DT mode, I wonder if we could queue this up
> > for 3.10.
> 
> Yes, I've queued this one for v3.10.  Working on getting some pull
> requests out to Tony today.
Thanks. I will hold off posting v4 of
https://patchwork.kernel.org/patch/2394591/ until the said discussions
on clock nodes are concluded in some form for 3.10 or so.
-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [130405 14:37]:
> On 14:10-20130405, Tony Lindgren wrote:
> > * Nishanth Menon <nm@ti.com> [130405 13:06]:
> > > On 12:28-20130405, Tony Lindgren wrote:
> [...]
> > > > How about just set it up in omap2_common_pm_init instead
> > > > of the board-generic?
> > > umm.. We want to eventually want to get rid of mach-omap2/pm.c (all
> > > those create processor devices etc should go away with proper
> > > representation of devices as nodes in DT if possible.
> > > But, I think you mean something like in the "else" condition of
> > > https://patchwork.kernel.org/patch/2359711/ ? - I'd again have the same
> > > request of not having anything to do with pm.c and keeping as little as
> > > possible for all TI processors in mach-omap2.
> > > 
> > > Could you enlighten me about why you'd not like it in board-generic.c?
> > > will creating an function ti_generic_cpufreq_init() in board-generic.c
> > > and calling it from omap_generic_init help?
> > 
> > I'd like to keep board-generic.c down to minimum. Can't you
> > set it up in omap_init_cpufreq() in your second patch of this
> > series?
> Thanks. That seems to be a better compromise. Will do. I can sequence patch
> [2] above the current patch[1] if there is a need to fix multi-arch builds
> for 3.9: in that case I will probably leave the current [2] patch as
> is, and once our clock representation discussion is done, the rev 4 of
> the patch [1], I can do the following:

OK makes sense to me.

> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 8d15f9a..b250689 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -267,8 +267,14 @@ static void __init omap4_init_voltages(void)
>  
>  static inline void omap_init_cpufreq(void)
>  {
> -	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
> -	platform_device_register_full(&devinfo);
> +	struct platform_device_info devinfo = { .name = "omap-cpufreq", }
> +
> +	if (!of_have_populated_dt()) {
> +		platform_device_register_full(&devinfo);
> +	} else if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> +		devinfo.name = "cpufreq-cpu0"
> +		platform_device_register_full(&devinfo);
> +	}
>  }

Maybe move platform_device_register_full(&devinfo) out of
the if else as the different naming needed is the only
difference?

Regards,

Tony

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On 14:40-20130405, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [130405 14:37]:
> > On 14:10-20130405, Tony Lindgren wrote:
> > > * Nishanth Menon <nm@ti.com> [130405 13:06]:
> > > > On 12:28-20130405, Tony Lindgren wrote:
> > [...]
> > > > > How about just set it up in omap2_common_pm_init instead
> > > > > of the board-generic?
> > > > umm.. We want to eventually want to get rid of mach-omap2/pm.c (all
> > > > those create processor devices etc should go away with proper
> > > > representation of devices as nodes in DT if possible.
> > > > But, I think you mean something like in the "else" condition of
> > > > https://patchwork.kernel.org/patch/2359711/ ? - I'd again have the same
> > > > request of not having anything to do with pm.c and keeping as little as
> > > > possible for all TI processors in mach-omap2.
> > > > 
> > > > Could you enlighten me about why you'd not like it in board-generic.c?
> > > > will creating an function ti_generic_cpufreq_init() in board-generic.c
> > > > and calling it from omap_generic_init help?
> > > 
> > > I'd like to keep board-generic.c down to minimum. Can't you
> > > set it up in omap_init_cpufreq() in your second patch of this
> > > series?
> > Thanks. That seems to be a better compromise. Will do. I can sequence patch
> > [2] above the current patch[1] if there is a need to fix multi-arch builds
> > for 3.9: in that case I will probably leave the current [2] patch as
> > is, and once our clock representation discussion is done, the rev 4 of
> > the patch [1], I can do the following:
> 
> OK makes sense to me.
Kevin has picked up [2]. So, my V4 will just contain this patch :).
Will hold sending it out till we conclude on Roger's thread.
> 
> > diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> > index 8d15f9a..b250689 100644
> > --- a/arch/arm/mach-omap2/pm.c
> > +++ b/arch/arm/mach-omap2/pm.c
> > @@ -267,8 +267,14 @@ static void __init omap4_init_voltages(void)
> >  
> >  static inline void omap_init_cpufreq(void)
> >  {
> > -	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
> > -	platform_device_register_full(&devinfo);
> > +	struct platform_device_info devinfo = { .name = "omap-cpufreq", }
> > +
> > +	if (!of_have_populated_dt()) {
> > +		platform_device_register_full(&devinfo);
> > +	} else if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
> > +		devinfo.name = "cpufreq-cpu0"
> > +		platform_device_register_full(&devinfo);
> > +	}
> >  }
> 
> Maybe move platform_device_register_full(&devinfo) out of
> the if else as the different naming needed is the only
> difference?
How does the following look?
Option a) not have a dummy node if CPUFREQ_CPU0 is not configured:
static inline void omap_init_cpufreq(void)
{
	struct platform_device_info devinfo = { };

	if (!of_have_populated_dt())
		devinfo.name = "omap-cpufreq";
	else if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0))
		devinfo.name = "cpufreq-cpu0"
	
	if (devinfo.name)
		platform_device_register_full(&devinfo);
}

Option b) leave a dummy node registered
static inline void omap_init_cpufreq(void)
{
	struct platform_device_info devinfo = { };

	if (!of_have_populated_dt())
		devinfo.name = "omap-cpufreq";
	else
		devinfo.name = "cpufreq-cpu0"
	
	platform_device_register_full(&devinfo);
}

If there are no objections to (b), I dont mind it either.
-- 
Regards,
Nishanth Menon

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [130405 15:15]:
> How does the following look?
> Option a) not have a dummy node if CPUFREQ_CPU0 is not configured:
> static inline void omap_init_cpufreq(void)
> {
> 	struct platform_device_info devinfo = { };
> 
> 	if (!of_have_populated_dt())
> 		devinfo.name = "omap-cpufreq";
> 	else if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0))
> 		devinfo.name = "cpufreq-cpu0"
> 	
> 	if (devinfo.name)
> 		platform_device_register_full(&devinfo);
> }
> 
> Option b) leave a dummy node registered
> static inline void omap_init_cpufreq(void)
> {
> 	struct platform_device_info devinfo = { };
> 
> 	if (!of_have_populated_dt())
> 		devinfo.name = "omap-cpufreq";
> 	else
> 		devinfo.name = "cpufreq-cpu0"
> 	
> 	platform_device_register_full(&devinfo);
> }
> 
> If there are no objections to (b), I dont mind it either.

To me option (b) looks better as it's if else :)

Tony

Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

On 15:17-20130405, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [130405 15:15]:
> > Option b) leave a dummy node registered
> > static inline void omap_init_cpufreq(void)
> > {
> > 	struct platform_device_info devinfo = { };
> > 
> > 	if (!of_have_populated_dt())
> > 		devinfo.name = "omap-cpufreq";
> > 	else
> > 		devinfo.name = "cpufreq-cpu0"
> > 	
> > 	platform_device_register_full(&devinfo);
> > }
> > 
> > If there are no objections to (b), I dont mind it either.
> 
> To me option (b) looks better as it's if else :)
Alrity.. Going once...twice...sold! All Nay-sayers will now be branded with
if-else braces ;)

I will now wait for conclusion of  https://lkml.org/lkml/2013/4/2/84
-- 
Regards,
Nishanth Menon