* [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot @ 2013-03-28 21:52 ` Nishanth Menon 0 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-03-28 21:52 UTC (permalink / raw) To: linux-omap Cc: Rob Herring, cpufreq, linux-pm, Nishanth Menon, Kevin Hilman, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot @ 2013-03-28 21:52 ` Nishanth Menon 0 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-03-28 21:52 UTC (permalink / raw) To: linux-omap Cc: Rob Herring, cpufreq, linux-pm, Nishanth Menon, Kevin Hilman, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-03-28 21:52 ` Nishanth Menon @ 2013-03-28 21:52 ` Nishanth Menon -1 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-03-28 21:52 UTC (permalink / raw) To: linux-omap Cc: Rob Herring, cpufreq, linux-pm, Nishanth Menon, Kevin Hilman, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot @ 2013-03-28 21:52 ` Nishanth Menon 0 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-03-28 21:52 UTC (permalink / raw) To: linux-omap Cc: Rob Herring, cpufreq, linux-pm, Nishanth Menon, Kevin Hilman, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-03-28 21:52 ` Nishanth Menon @ 2013-04-03 18:47 ` Kevin Hilman -1 siblings, 0 replies; 32+ messages in thread From: Kevin Hilman @ 2013-04-03 18:47 UTC (permalink / raw) To: Nishanth Menon Cc: linux-omap, Rob Herring, cpufreq, linux-pm, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot @ 2013-04-03 18:47 ` Kevin Hilman 0 siblings, 0 replies; 32+ messages in thread From: Kevin Hilman @ 2013-04-03 18:47 UTC (permalink / raw) To: Nishanth Menon Cc: linux-omap, Rob Herring, cpufreq, linux-pm, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-03 18:47 ` Kevin Hilman (?) @ 2013-04-04 2:52 ` Nishanth Menon 2013-04-04 5:13 ` Rajendra Nayak -1 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-04 2:52 UTC (permalink / raw) To: Kevin Hilman Cc: linux-omap, Rob Herring, cpufreq, linux-pm, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-04 2:52 ` Nishanth Menon @ 2013-04-04 5:13 ` Rajendra Nayak 2013-04-04 19:00 ` Nishanth Menon 0 siblings, 1 reply; 32+ messages in thread From: Rajendra Nayak @ 2013-04-04 5:13 UTC (permalink / raw) To: Nishanth Menon Cc: Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 */ >>> }; > [...] > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-04 5:13 ` Rajendra Nayak @ 2013-04-04 19:00 ` Nishanth Menon 2013-04-05 9:50 ` Rajendra Nayak 0 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-04 19:00 UTC (permalink / raw) To: Rajendra Nayak Cc: Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-04 19:00 ` Nishanth Menon @ 2013-04-05 9:50 ` Rajendra Nayak 2013-04-05 11:26 ` Nishanth Menon 0 siblings, 1 reply; 32+ messages in thread From: Rajendra Nayak @ 2013-04-05 9:50 UTC (permalink / raw) To: Nishanth Menon Cc: Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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; > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 9:50 ` Rajendra Nayak @ 2013-04-05 11:26 ` Nishanth Menon 2013-04-05 16:13 ` Tony Lindgren 0 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 11:26 UTC (permalink / raw) To: Rajendra Nayak Cc: Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 11:26 ` Nishanth Menon @ 2013-04-05 16:13 ` Tony Lindgren 2013-04-05 16:32 ` Nishanth Menon 0 siblings, 1 reply; 32+ messages in thread From: Tony Lindgren @ 2013-04-05 16:13 UTC (permalink / raw) To: Nishanth Menon Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo * 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 16:13 ` Tony Lindgren @ 2013-04-05 16:32 ` Nishanth Menon 2013-04-05 17:05 ` Tony Lindgren 0 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 16:32 UTC (permalink / raw) To: Tony Lindgren Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 16:32 ` Nishanth Menon @ 2013-04-05 17:05 ` Tony Lindgren 2013-04-05 17:17 ` Nishanth Menon 0 siblings, 1 reply; 32+ messages in thread From: Tony Lindgren @ 2013-04-05 17:05 UTC (permalink / raw) To: Nishanth Menon Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo * 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 17:05 ` Tony Lindgren @ 2013-04-05 17:17 ` Nishanth Menon 2013-04-05 19:28 ` Tony Lindgren 0 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 17:17 UTC (permalink / raw) To: Tony Lindgren Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 17:17 ` Nishanth Menon @ 2013-04-05 19:28 ` Tony Lindgren 2013-04-05 20:02 ` Nishanth Menon 0 siblings, 1 reply; 32+ messages in thread From: Tony Lindgren @ 2013-04-05 19:28 UTC (permalink / raw) To: Nishanth Menon Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo * 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 19:28 ` Tony Lindgren @ 2013-04-05 20:02 ` Nishanth Menon 2013-04-05 21:10 ` Tony Lindgren 0 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 20:02 UTC (permalink / raw) To: Tony Lindgren Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 20:02 ` Nishanth Menon @ 2013-04-05 21:10 ` Tony Lindgren 2013-04-05 21:32 ` Nishanth Menon 0 siblings, 1 reply; 32+ messages in thread From: Tony Lindgren @ 2013-04-05 21:10 UTC (permalink / raw) To: Nishanth Menon Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo * 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 21:10 ` Tony Lindgren @ 2013-04-05 21:32 ` Nishanth Menon 2013-04-05 21:40 ` Tony Lindgren 0 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 21:32 UTC (permalink / raw) To: Tony Lindgren Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 21:32 ` Nishanth Menon @ 2013-04-05 21:40 ` Tony Lindgren 2013-04-05 22:10 ` Nishanth Menon 0 siblings, 1 reply; 32+ messages in thread From: Tony Lindgren @ 2013-04-05 21:40 UTC (permalink / raw) To: Nishanth Menon Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo * 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 21:40 ` Tony Lindgren @ 2013-04-05 22:10 ` Nishanth Menon 2013-04-05 22:17 ` Tony Lindgren 0 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 22:10 UTC (permalink / raw) To: Tony Lindgren Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 22:10 ` Nishanth Menon @ 2013-04-05 22:17 ` Tony Lindgren 2013-04-05 22:23 ` Nishanth Menon 0 siblings, 1 reply; 32+ messages in thread From: Tony Lindgren @ 2013-04-05 22:17 UTC (permalink / raw) To: Nishanth Menon Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo * 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot 2013-04-05 22:17 ` Tony Lindgren @ 2013-04-05 22:23 ` Nishanth Menon 0 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 22:23 UTC (permalink / raw) To: Tony Lindgren Cc: Rajendra Nayak, Kevin Hilman, linux-omap, Rob Herring, cpufreq, linux-pm, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver 2013-03-28 21:52 ` Nishanth Menon @ 2013-03-28 21:52 ` Nishanth Menon -1 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-03-28 21:52 UTC (permalink / raw) To: linux-omap Cc: Rob Herring, cpufreq, linux-pm, Nishanth Menon, Kevin Hilman, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver @ 2013-03-28 21:52 ` Nishanth Menon 0 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-03-28 21:52 UTC (permalink / raw) To: linux-omap Cc: Rob Herring, cpufreq, linux-pm, Nishanth Menon, Kevin Hilman, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver 2013-03-28 21:52 ` Nishanth Menon (?) @ 2013-03-29 2:59 ` Viresh Kumar 2013-04-05 17:07 ` Nishanth Menon -1 siblings, 1 reply; 32+ messages in thread From: Viresh Kumar @ 2013-03-29 2:59 UTC (permalink / raw) To: Nishanth Menon Cc: linux-omap, Rob Herring, cpufreq, linux-pm, Kevin Hilman, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver 2013-03-29 2:59 ` Viresh Kumar @ 2013-04-05 17:07 ` Nishanth Menon 2013-04-05 21:34 ` Kevin Hilman 0 siblings, 1 reply; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 17:07 UTC (permalink / raw) To: Viresh Kumar Cc: linux-omap, Rob Herring, cpufreq, linux-pm, Kevin Hilman, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver 2013-04-05 17:07 ` Nishanth Menon @ 2013-04-05 21:34 ` Kevin Hilman 0 siblings, 0 replies; 32+ messages in thread From: Kevin Hilman @ 2013-04-05 21:34 UTC (permalink / raw) To: Nishanth Menon Cc: Viresh Kumar, linux-omap, Rob Herring, cpufreq, linux-pm, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver @ 2013-04-05 21:34 ` Kevin Hilman 0 siblings, 0 replies; 32+ messages in thread From: Kevin Hilman @ 2013-04-05 21:34 UTC (permalink / raw) To: Nishanth Menon Cc: Viresh Kumar, linux-omap, Rob Herring, cpufreq, linux-pm, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver 2013-04-05 21:34 ` Kevin Hilman (?) @ 2013-04-05 21:36 ` Nishanth Menon -1 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-04-05 21:36 UTC (permalink / raw) To: Kevin Hilman Cc: Viresh Kumar, linux-omap, Rob Herring, cpufreq, linux-pm, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot 2013-03-28 21:52 ` Nishanth Menon ` (2 preceding siblings ...) (?) @ 2013-04-03 17:47 ` Kevin Hilman 2013-04-03 18:22 ` Nishanth Menon -1 siblings, 1 reply; 32+ messages in thread From: Kevin Hilman @ 2013-04-03 17:47 UTC (permalink / raw) To: Nishanth Menon Cc: linux-omap, Rob Herring, cpufreq, linux-pm, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot 2013-04-03 17:47 ` [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot Kevin Hilman @ 2013-04-03 18:22 ` Nishanth Menon 0 siblings, 0 replies; 32+ messages in thread From: Nishanth Menon @ 2013-04-03 18:22 UTC (permalink / raw) To: Kevin Hilman Cc: linux-omap, Rob Herring, cpufreq, linux-pm, Rajendra Nayak, Paul Walmsley, Benoît Cousson, Jon Hunter, Keerthy, Santosh Shilimkar, Shawn Guo 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2013-04-05 22:23 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-03-28 21:52 [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot Nishanth Menon 2013-03-28 21:52 ` Nishanth Menon 2013-03-28 21:52 ` [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot Nishanth Menon 2013-03-28 21:52 ` Nishanth Menon 2013-04-03 18:47 ` Kevin Hilman 2013-04-03 18:47 ` Kevin Hilman 2013-04-04 2:52 ` Nishanth Menon 2013-04-04 5:13 ` Rajendra Nayak 2013-04-04 19:00 ` Nishanth Menon 2013-04-05 9:50 ` Rajendra Nayak 2013-04-05 11:26 ` Nishanth Menon 2013-04-05 16:13 ` Tony Lindgren 2013-04-05 16:32 ` Nishanth Menon 2013-04-05 17:05 ` Tony Lindgren 2013-04-05 17:17 ` Nishanth Menon 2013-04-05 19:28 ` Tony Lindgren 2013-04-05 20:02 ` Nishanth Menon 2013-04-05 21:10 ` Tony Lindgren 2013-04-05 21:32 ` Nishanth Menon 2013-04-05 21:40 ` Tony Lindgren 2013-04-05 22:10 ` Nishanth Menon 2013-04-05 22:17 ` Tony Lindgren 2013-04-05 22:23 ` Nishanth Menon 2013-03-28 21:52 ` [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver Nishanth Menon 2013-03-28 21:52 ` Nishanth Menon 2013-03-29 2:59 ` Viresh Kumar 2013-04-05 17:07 ` Nishanth Menon 2013-04-05 21:34 ` Kevin Hilman 2013-04-05 21:34 ` Kevin Hilman 2013-04-05 21:36 ` Nishanth Menon 2013-04-03 17:47 ` [PATCH V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot Kevin Hilman 2013-04-03 18:22 ` Nishanth Menon
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.