* omap cpufreq driver in multi-platform kernels @ 2013-03-27 1:49 Rob Herring 2013-03-27 2:23 ` Paul Walmsley 0 siblings, 1 reply; 15+ messages in thread From: Rob Herring @ 2013-03-27 1:49 UTC (permalink / raw) To: linux-arm-kernel Kevin, Tony, Paul, The omap cpufreq driver causes problems in multi-platform kernels because it unconditionally registers with the cpufreq core and does not check sufficiently that it is running on an omap platform. So on a kernel with highbank and omap drivers booted on highbank, the cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For DT this could just be several of_machine_is_compatible checks, but I'm not really sure for non-DT. Converting the driver to a platform driver would be another option. This will also affect other cpufreq-cpu0 users like iMX. And I'd guess there may be other ARM cpufreq drivers that will cause the same issue. Rob ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 1:49 omap cpufreq driver in multi-platform kernels Rob Herring @ 2013-03-27 2:23 ` Paul Walmsley 2013-03-27 13:32 ` Nishanth Menon 0 siblings, 1 reply; 15+ messages in thread From: Paul Walmsley @ 2013-03-27 2:23 UTC (permalink / raw) To: linux-arm-kernel Hi On Tue, 26 Mar 2013, Rob Herring wrote: > The omap cpufreq driver causes problems in multi-platform kernels > because it unconditionally registers with the cpufreq core and does not > check sufficiently that it is running on an omap platform. So on a > kernel with highbank and omap drivers booted on highbank, the > cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For > DT this could just be several of_machine_is_compatible checks, but I'm > not really sure for non-DT. Converting the driver to a platform driver > would be another option. We could move the mpu_clk = clk_get(NULL, "cpufreq_ck"); down to omap_cpufreq_init(), and bail out early if the clock alias doesn't exist. (Presumably we'd also want to change the clock role name if we did that, to something like "omap_cpufreq_ck".) Experimental patch follows, comments welcome. - Paul >From c1b4374d9cdcf59e0cbe93aa5a23335cb3e60798 Mon Sep 17 00:00:00 2001 From: Paul Walmsley <paul@pwsan.com> Date: Tue, 26 Mar 2013 20:16:39 -0600 Subject: [PATCH] EXPERIMENTAL: cpufreq: avoid loading the OMAP driver on non-OMAP multiplatform targets etc. etc. --- arch/arm/mach-omap2/cclock2420_data.c | 2 +- arch/arm/mach-omap2/cclock2430_data.c | 2 +- arch/arm/mach-omap2/cclock3xxx_data.c | 2 +- arch/arm/mach-omap2/cclock44xx_data.c | 2 +- drivers/cpufreq/omap-cpufreq.c | 8 ++++---- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/cclock2420_data.c b/arch/arm/mach-omap2/cclock2420_data.c index 0f0a97c..d4316e9 100644 --- a/arch/arm/mach-omap2/cclock2420_data.c +++ b/arch/arm/mach-omap2/cclock2420_data.c @@ -1885,7 +1885,7 @@ static struct omap_clk omap2420_clks[] = { CLK(NULL, "timer_32k_ck", &func_32k_ck, CK_242X), CLK(NULL, "timer_sys_ck", &sys_ck, CK_242X), CLK(NULL, "timer_ext_ck", &alt_ck, CK_242X), - CLK(NULL, "cpufreq_ck", &virt_prcm_set, CK_242X), + CLK(NULL, "omap_cpufreq_ck", &virt_prcm_set, CK_242X), }; diff --git a/arch/arm/mach-omap2/cclock2430_data.c b/arch/arm/mach-omap2/cclock2430_data.c index aed8f74..7c855b9 100644 --- a/arch/arm/mach-omap2/cclock2430_data.c +++ b/arch/arm/mach-omap2/cclock2430_data.c @@ -2001,7 +2001,7 @@ static struct omap_clk omap2430_clks[] = { CLK(NULL, "timer_32k_ck", &func_32k_ck, CK_243X), CLK(NULL, "timer_sys_ck", &sys_ck, CK_243X), CLK(NULL, "timer_ext_ck", &alt_ck, CK_243X), - CLK(NULL, "cpufreq_ck", &virt_prcm_set, CK_243X), + CLK(NULL, "omap_cpufreq_ck", &virt_prcm_set, CK_243X), }; static const char *enable_init_clks[] = { diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c index 4579c3c..17dd82c 100644 --- a/arch/arm/mach-omap2/cclock3xxx_data.c +++ b/arch/arm/mach-omap2/cclock3xxx_data.c @@ -3501,7 +3501,7 @@ 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, "omap_cpufreq_ck", &dpll1_ck, CK_3XXX), }; 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..66b85e5 100644 --- a/arch/arm/mach-omap2/cclock44xx_data.c +++ b/arch/arm/mach-omap2/cclock44xx_data.c @@ -1660,7 +1660,7 @@ 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, "omap_cpufreq_ck", &dpll_mpu_ck, CK_443X), }; int __init omap4xxx_clk_init(void) diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c index 9128c07..d46caa5 100644 --- a/drivers/cpufreq/omap-cpufreq.c +++ b/drivers/cpufreq/omap-cpufreq.c @@ -175,10 +175,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy) { int result = 0; - mpu_clk = clk_get(NULL, "cpufreq_ck"); - if (IS_ERR(mpu_clk)) - return PTR_ERR(mpu_clk); - if (policy->cpu >= NR_CPUS) { result = -EINVAL; goto fail_ck; @@ -254,6 +250,10 @@ static struct cpufreq_driver omap_driver = { static int __init omap_cpufreq_init(void) { + mpu_clk = clk_get(NULL, "omap_cpufreq_ck"); + if (IS_ERR(mpu_clk)) + return PTR_ERR(mpu_clk); + mpu_dev = get_cpu_device(0); if (!mpu_dev) { pr_warning("%s: unable to get the mpu device\n", __func__); -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 2:23 ` Paul Walmsley @ 2013-03-27 13:32 ` Nishanth Menon 2013-03-27 16:38 ` Rob Herring 2013-03-27 17:48 ` Paul Walmsley 0 siblings, 2 replies; 15+ messages in thread From: Nishanth Menon @ 2013-03-27 13:32 UTC (permalink / raw) To: linux-arm-kernel On 02:23-20130327, Paul Walmsley wrote: > Hi > > On Tue, 26 Mar 2013, Rob Herring wrote: > > > The omap cpufreq driver causes problems in multi-platform kernels > > because it unconditionally registers with the cpufreq core and does not > > check sufficiently that it is running on an omap platform. So on a > > kernel with highbank and omap drivers booted on highbank, the > > cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For > > DT this could just be several of_machine_is_compatible checks, but I'm > > not really sure for non-DT. Converting the driver to a platform driver > > would be another option. > > We could move the > > mpu_clk = clk_get(NULL, "cpufreq_ck"); > > down to omap_cpufreq_init(), and bail out early if the clock alias doesn't > exist. (Presumably we'd also want to change the clock role name if we did > that, to something like "omap_cpufreq_ck".) > > Experimental patch follows, comments welcome. We should deprecate usage on omap-cpufreq driver eventually, instead go towards embracing the SoC generic implementation of cpufreq-cpu0 driver IMHO. http://marc.info/?l=linux-omap&m=136371580826031&w=2 is the series to support cpufreq_cpu0 driver in DT based boot. Would you think this approach is sane? > > > - Paul > > From c1b4374d9cdcf59e0cbe93aa5a23335cb3e60798 Mon Sep 17 00:00:00 2001 > From: Paul Walmsley <paul@pwsan.com> > Date: Tue, 26 Mar 2013 20:16:39 -0600 > Subject: [PATCH] EXPERIMENTAL: cpufreq: avoid loading the OMAP driver on > non-OMAP multiplatform targets > > etc. etc. > --- > arch/arm/mach-omap2/cclock2420_data.c | 2 +- > arch/arm/mach-omap2/cclock2430_data.c | 2 +- > arch/arm/mach-omap2/cclock3xxx_data.c | 2 +- > arch/arm/mach-omap2/cclock44xx_data.c | 2 +- > drivers/cpufreq/omap-cpufreq.c | 8 ++++---- > 5 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/mach-omap2/cclock2420_data.c b/arch/arm/mach-omap2/cclock2420_data.c > index 0f0a97c..d4316e9 100644 > --- a/arch/arm/mach-omap2/cclock2420_data.c > +++ b/arch/arm/mach-omap2/cclock2420_data.c > @@ -1885,7 +1885,7 @@ static struct omap_clk omap2420_clks[] = { > CLK(NULL, "timer_32k_ck", &func_32k_ck, CK_242X), > CLK(NULL, "timer_sys_ck", &sys_ck, CK_242X), > CLK(NULL, "timer_ext_ck", &alt_ck, CK_242X), > - CLK(NULL, "cpufreq_ck", &virt_prcm_set, CK_242X), > + CLK(NULL, "omap_cpufreq_ck", &virt_prcm_set, CK_242X), > }; > > > diff --git a/arch/arm/mach-omap2/cclock2430_data.c b/arch/arm/mach-omap2/cclock2430_data.c > index aed8f74..7c855b9 100644 > --- a/arch/arm/mach-omap2/cclock2430_data.c > +++ b/arch/arm/mach-omap2/cclock2430_data.c > @@ -2001,7 +2001,7 @@ static struct omap_clk omap2430_clks[] = { > CLK(NULL, "timer_32k_ck", &func_32k_ck, CK_243X), > CLK(NULL, "timer_sys_ck", &sys_ck, CK_243X), > CLK(NULL, "timer_ext_ck", &alt_ck, CK_243X), > - CLK(NULL, "cpufreq_ck", &virt_prcm_set, CK_243X), > + CLK(NULL, "omap_cpufreq_ck", &virt_prcm_set, CK_243X), > }; > > static const char *enable_init_clks[] = { > diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c > index 4579c3c..17dd82c 100644 > --- a/arch/arm/mach-omap2/cclock3xxx_data.c > +++ b/arch/arm/mach-omap2/cclock3xxx_data.c > @@ -3501,7 +3501,7 @@ 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, "omap_cpufreq_ck", &dpll1_ck, CK_3XXX), > }; > > 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..66b85e5 100644 > --- a/arch/arm/mach-omap2/cclock44xx_data.c > +++ b/arch/arm/mach-omap2/cclock44xx_data.c > @@ -1660,7 +1660,7 @@ 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, "omap_cpufreq_ck", &dpll_mpu_ck, CK_443X), > }; > > int __init omap4xxx_clk_init(void) > diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c > index 9128c07..d46caa5 100644 > --- a/drivers/cpufreq/omap-cpufreq.c > +++ b/drivers/cpufreq/omap-cpufreq.c > @@ -175,10 +175,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy) > { > int result = 0; > > - mpu_clk = clk_get(NULL, "cpufreq_ck"); > - if (IS_ERR(mpu_clk)) > - return PTR_ERR(mpu_clk); > - > if (policy->cpu >= NR_CPUS) { > result = -EINVAL; > goto fail_ck; > @@ -254,6 +250,10 @@ static struct cpufreq_driver omap_driver = { > > static int __init omap_cpufreq_init(void) > { > + mpu_clk = clk_get(NULL, "omap_cpufreq_ck"); > + if (IS_ERR(mpu_clk)) > + return PTR_ERR(mpu_clk); > + > mpu_dev = get_cpu_device(0); > if (!mpu_dev) { > pr_warning("%s: unable to get the mpu device\n", __func__); > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 13:32 ` Nishanth Menon @ 2013-03-27 16:38 ` Rob Herring 2013-03-27 17:02 ` Nishanth Menon 2013-03-27 17:48 ` Paul Walmsley 1 sibling, 1 reply; 15+ messages in thread From: Rob Herring @ 2013-03-27 16:38 UTC (permalink / raw) To: linux-arm-kernel On 03/27/2013 08:32 AM, Nishanth Menon wrote: > On 02:23-20130327, Paul Walmsley wrote: >> Hi >> >> On Tue, 26 Mar 2013, Rob Herring wrote: >> >>> The omap cpufreq driver causes problems in multi-platform kernels >>> because it unconditionally registers with the cpufreq core and does not >>> check sufficiently that it is running on an omap platform. So on a >>> kernel with highbank and omap drivers booted on highbank, the >>> cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For >>> DT this could just be several of_machine_is_compatible checks, but I'm >>> not really sure for non-DT. Converting the driver to a platform driver >>> would be another option. >> >> We could move the >> >> mpu_clk = clk_get(NULL, "cpufreq_ck"); >> >> down to omap_cpufreq_init(), and bail out early if the clock alias doesn't >> exist. (Presumably we'd also want to change the clock role name if we did >> that, to something like "omap_cpufreq_ck".) >> >> Experimental patch follows, comments welcome. > We should deprecate usage on omap-cpufreq driver eventually, instead go > towards embracing the SoC generic implementation of cpufreq-cpu0 driver > IMHO. > http://marc.info/?l=linux-omap&m=136371580826031&w=2 > is the series to support cpufreq_cpu0 driver in DT based boot. > Would you think this approach is sane? That only solves the problem for DT, but not non-DT. My understanding is non-DT omap platforms will be around for some time. Rob >> >> >> - Paul >> >> From c1b4374d9cdcf59e0cbe93aa5a23335cb3e60798 Mon Sep 17 00:00:00 2001 >> From: Paul Walmsley <paul@pwsan.com> >> Date: Tue, 26 Mar 2013 20:16:39 -0600 >> Subject: [PATCH] EXPERIMENTAL: cpufreq: avoid loading the OMAP driver on >> non-OMAP multiplatform targets >> >> etc. etc. >> --- >> arch/arm/mach-omap2/cclock2420_data.c | 2 +- >> arch/arm/mach-omap2/cclock2430_data.c | 2 +- >> arch/arm/mach-omap2/cclock3xxx_data.c | 2 +- >> arch/arm/mach-omap2/cclock44xx_data.c | 2 +- >> drivers/cpufreq/omap-cpufreq.c | 8 ++++---- >> 5 files changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/cclock2420_data.c b/arch/arm/mach-omap2/cclock2420_data.c >> index 0f0a97c..d4316e9 100644 >> --- a/arch/arm/mach-omap2/cclock2420_data.c >> +++ b/arch/arm/mach-omap2/cclock2420_data.c >> @@ -1885,7 +1885,7 @@ static struct omap_clk omap2420_clks[] = { >> CLK(NULL, "timer_32k_ck", &func_32k_ck, CK_242X), >> CLK(NULL, "timer_sys_ck", &sys_ck, CK_242X), >> CLK(NULL, "timer_ext_ck", &alt_ck, CK_242X), >> - CLK(NULL, "cpufreq_ck", &virt_prcm_set, CK_242X), >> + CLK(NULL, "omap_cpufreq_ck", &virt_prcm_set, CK_242X), >> }; >> >> >> diff --git a/arch/arm/mach-omap2/cclock2430_data.c b/arch/arm/mach-omap2/cclock2430_data.c >> index aed8f74..7c855b9 100644 >> --- a/arch/arm/mach-omap2/cclock2430_data.c >> +++ b/arch/arm/mach-omap2/cclock2430_data.c >> @@ -2001,7 +2001,7 @@ static struct omap_clk omap2430_clks[] = { >> CLK(NULL, "timer_32k_ck", &func_32k_ck, CK_243X), >> CLK(NULL, "timer_sys_ck", &sys_ck, CK_243X), >> CLK(NULL, "timer_ext_ck", &alt_ck, CK_243X), >> - CLK(NULL, "cpufreq_ck", &virt_prcm_set, CK_243X), >> + CLK(NULL, "omap_cpufreq_ck", &virt_prcm_set, CK_243X), >> }; >> >> static const char *enable_init_clks[] = { >> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c >> index 4579c3c..17dd82c 100644 >> --- a/arch/arm/mach-omap2/cclock3xxx_data.c >> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c >> @@ -3501,7 +3501,7 @@ 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, "omap_cpufreq_ck", &dpll1_ck, CK_3XXX), >> }; >> >> 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..66b85e5 100644 >> --- a/arch/arm/mach-omap2/cclock44xx_data.c >> +++ b/arch/arm/mach-omap2/cclock44xx_data.c >> @@ -1660,7 +1660,7 @@ 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, "omap_cpufreq_ck", &dpll_mpu_ck, CK_443X), >> }; >> >> int __init omap4xxx_clk_init(void) >> diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c >> index 9128c07..d46caa5 100644 >> --- a/drivers/cpufreq/omap-cpufreq.c >> +++ b/drivers/cpufreq/omap-cpufreq.c >> @@ -175,10 +175,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy) >> { >> int result = 0; >> >> - mpu_clk = clk_get(NULL, "cpufreq_ck"); >> - if (IS_ERR(mpu_clk)) >> - return PTR_ERR(mpu_clk); >> - >> if (policy->cpu >= NR_CPUS) { >> result = -EINVAL; >> goto fail_ck; >> @@ -254,6 +250,10 @@ static struct cpufreq_driver omap_driver = { >> >> static int __init omap_cpufreq_init(void) >> { >> + mpu_clk = clk_get(NULL, "omap_cpufreq_ck"); >> + if (IS_ERR(mpu_clk)) >> + return PTR_ERR(mpu_clk); >> + >> mpu_dev = get_cpu_device(0); >> if (!mpu_dev) { >> pr_warning("%s: unable to get the mpu device\n", __func__); >> -- >> 1.7.10.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pm" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 16:38 ` Rob Herring @ 2013-03-27 17:02 ` Nishanth Menon 2013-03-27 17:53 ` Kevin Hilman 0 siblings, 1 reply; 15+ messages in thread From: Nishanth Menon @ 2013-03-27 17:02 UTC (permalink / raw) To: linux-arm-kernel On 11:38-20130327, Rob Herring wrote: > On 03/27/2013 08:32 AM, Nishanth Menon wrote: > > On 02:23-20130327, Paul Walmsley wrote: > >> Hi > >> > >> On Tue, 26 Mar 2013, Rob Herring wrote: > >> > >>> The omap cpufreq driver causes problems in multi-platform kernels > >>> because it unconditionally registers with the cpufreq core and does not > >>> check sufficiently that it is running on an omap platform. So on a > >>> kernel with highbank and omap drivers booted on highbank, the > >>> cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For > >>> DT this could just be several of_machine_is_compatible checks, but I'm > >>> not really sure for non-DT. Converting the driver to a platform driver > >>> would be another option. > >> > >> We could move the > >> > >> mpu_clk = clk_get(NULL, "cpufreq_ck"); > >> > >> down to omap_cpufreq_init(), and bail out early if the clock alias doesn't > >> exist. (Presumably we'd also want to change the clock role name if we did > >> that, to something like "omap_cpufreq_ck".) > >> > >> Experimental patch follows, comments welcome. > > We should deprecate usage on omap-cpufreq driver eventually, instead go > > towards embracing the SoC generic implementation of cpufreq-cpu0 driver > > IMHO. > > http://marc.info/?l=linux-omap&m=136371580826031&w=2 > > is the series to support cpufreq_cpu0 driver in DT based boot. > > Would you think this approach is sane? > > That only solves the problem for DT, but not non-DT. My understanding is > non-DT omap platforms will be around for some time. > Yes, that is true. There are multiple parts of the problem: part #1: DT boot: https://patchwork.kernel.org/patch/2303471/ prevents omap-cpufreq from interfering in DT enabled boot. (seeing DT entries for highbank it probably might help in the specific platform) part #2: non DT boot: you would not have cpu DT nodes in the system. So, cpufreq-cpu0 wont come into play[1] Now the conflict between omap-cpufreq Vs non-dt platform cpufreq driver: other than registering an dummy device and moving omap_cpufreq_init to it (similar to what was done in cpufreq-cpu0[2]) I dont see how we can continue to keep multiple platforms sane in mult-arch non-dt boot. [1] https://patchwork.kernel.org/patch/2351601/ [2] https://patchwork.kernel.org/patch/2067751/ -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 17:02 ` Nishanth Menon @ 2013-03-27 17:53 ` Kevin Hilman 2013-03-27 17:56 ` Nishanth Menon 0 siblings, 1 reply; 15+ messages in thread From: Kevin Hilman @ 2013-03-27 17:53 UTC (permalink / raw) To: linux-arm-kernel Hi Nishanth, Nishanth Menon <nm@ti.com> writes: > On 11:38-20130327, Rob Herring wrote: >> On 03/27/2013 08:32 AM, Nishanth Menon wrote: >> > On 02:23-20130327, Paul Walmsley wrote: >> >> Hi >> >> >> >> On Tue, 26 Mar 2013, Rob Herring wrote: >> >> >> >>> The omap cpufreq driver causes problems in multi-platform kernels >> >>> because it unconditionally registers with the cpufreq core and does not >> >>> check sufficiently that it is running on an omap platform. So on a >> >>> kernel with highbank and omap drivers booted on highbank, the >> >>> cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For >> >>> DT this could just be several of_machine_is_compatible checks, but I'm >> >>> not really sure for non-DT. Converting the driver to a platform driver >> >>> would be another option. >> >> >> >> We could move the >> >> >> >> mpu_clk = clk_get(NULL, "cpufreq_ck"); >> >> >> >> down to omap_cpufreq_init(), and bail out early if the clock alias doesn't >> >> exist. (Presumably we'd also want to change the clock role name if we did >> >> that, to something like "omap_cpufreq_ck".) >> >> >> >> Experimental patch follows, comments welcome. >> > We should deprecate usage on omap-cpufreq driver eventually, instead go >> > towards embracing the SoC generic implementation of cpufreq-cpu0 driver >> > IMHO. >> > http://marc.info/?l=linux-omap&m=136371580826031&w=2 >> > is the series to support cpufreq_cpu0 driver in DT based boot. >> > Would you think this approach is sane? >> >> That only solves the problem for DT, but not non-DT. My understanding is >> non-DT omap platforms will be around for some time. >> > Yes, that is true. There are multiple parts of the problem: > part #1: DT boot: > https://patchwork.kernel.org/patch/2303471/ prevents omap-cpufreq from > interfering in DT enabled boot. (seeing DT entries for highbank it > probably might help in the specific platform) > part #2: non DT boot: > you would not have cpu DT nodes in the system. So, cpufreq-cpu0 wont come > into play[1] > Now the conflict between omap-cpufreq Vs non-dt platform cpufreq driver: > other than registering an dummy device and moving omap_cpufreq_init to > it (similar to what was done in cpufreq-cpu0[2]) I dont see how we can > continue to keep multiple platforms sane in mult-arch non-dt boot. > > [1] https://patchwork.kernel.org/patch/2351601/ > [2] https://patchwork.kernel.org/patch/2067751/ I think the platform_device conversion is the way to go. I think you should do that instead of PATCH 8/8 of your OMAP conversion to the generic driver[1]. I'll have a closer look at that series also and comment there as well. Kevin [1] http://marc.info/?l=linux-omap&m=136371580826031&w=2 ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 17:53 ` Kevin Hilman @ 2013-03-27 17:56 ` Nishanth Menon 2013-03-30 22:21 ` Paul Walmsley 0 siblings, 1 reply; 15+ messages in thread From: Nishanth Menon @ 2013-03-27 17:56 UTC (permalink / raw) To: linux-arm-kernel Hi Kevin, On 10:53-20130327, Kevin Hilman wrote: > Nishanth Menon <nm@ti.com> writes: > > > On 11:38-20130327, Rob Herring wrote: > >> On 03/27/2013 08:32 AM, Nishanth Menon wrote: > >> > On 02:23-20130327, Paul Walmsley wrote: > >> >> Hi > >> >> > >> >> On Tue, 26 Mar 2013, Rob Herring wrote: > >> >> > >> >>> The omap cpufreq driver causes problems in multi-platform kernels > >> >>> because it unconditionally registers with the cpufreq core and does not > >> >>> check sufficiently that it is running on an omap platform. So on a > >> >>> kernel with highbank and omap drivers booted on highbank, the > >> >>> cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For > >> >>> DT this could just be several of_machine_is_compatible checks, but I'm > >> >>> not really sure for non-DT. Converting the driver to a platform driver > >> >>> would be another option. > >> >> > >> >> We could move the > >> >> > >> >> mpu_clk = clk_get(NULL, "cpufreq_ck"); > >> >> > >> >> down to omap_cpufreq_init(), and bail out early if the clock alias doesn't > >> >> exist. (Presumably we'd also want to change the clock role name if we did > >> >> that, to something like "omap_cpufreq_ck".) > >> >> > >> >> Experimental patch follows, comments welcome. > >> > We should deprecate usage on omap-cpufreq driver eventually, instead go > >> > towards embracing the SoC generic implementation of cpufreq-cpu0 driver > >> > IMHO. > >> > http://marc.info/?l=linux-omap&m=136371580826031&w=2 > >> > is the series to support cpufreq_cpu0 driver in DT based boot. > >> > Would you think this approach is sane? > >> > >> That only solves the problem for DT, but not non-DT. My understanding is > >> non-DT omap platforms will be around for some time. > >> > > Yes, that is true. There are multiple parts of the problem: > > part #1: DT boot: > > https://patchwork.kernel.org/patch/2303471/ prevents omap-cpufreq from > > interfering in DT enabled boot. (seeing DT entries for highbank it > > probably might help in the specific platform) > > part #2: non DT boot: > > you would not have cpu DT nodes in the system. So, cpufreq-cpu0 wont come > > into play[1] > > Now the conflict between omap-cpufreq Vs non-dt platform cpufreq driver: > > other than registering an dummy device and moving omap_cpufreq_init to > > it (similar to what was done in cpufreq-cpu0[2]) I dont see how we can > > continue to keep multiple platforms sane in mult-arch non-dt boot. > > > > [1] https://patchwork.kernel.org/patch/2351601/ > > [2] https://patchwork.kernel.org/patch/2067751/ > > I think the platform_device conversion is the way to go. I think you > should do that instead of PATCH 8/8 of your OMAP conversion to the > generic driver[1]. Yep, thinking about this over lunch, I came to the same conclusion that instead of checking on DT node existance, platform_device conversion will solve both parts of the puzzle. > > I'll have a closer look at that series also and comment there as well. Thanks. I will hold off posting a v3 on my series till I hear more. > > Kevin > > [1] http://marc.info/?l=linux-omap&m=136371580826031&w=2 -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 17:56 ` Nishanth Menon @ 2013-03-30 22:21 ` Paul Walmsley 2013-04-01 17:20 ` Eduardo Valentin 2013-04-01 19:46 ` Rob Herring 0 siblings, 2 replies; 15+ messages in thread From: Paul Walmsley @ 2013-03-30 22:21 UTC (permalink / raw) To: linux-arm-kernel Hi folks, On Wed, 27 Mar 2013, Nishanth Menon wrote: > On 10:53-20130327, Kevin Hilman wrote: > > Nishanth Menon <nm@ti.com> writes: > > > On 11:38-20130327, Rob Herring wrote: > > >> On 03/27/2013 08:32 AM, Nishanth Menon wrote: > > >> > On 02:23-20130327, Paul Walmsley wrote: > > >> >> On Tue, 26 Mar 2013, Rob Herring wrote: > > >> >>> > > >> >>> Converting the driver to a platform driver would be another option. > > > > I think the platform_device conversion is the way to go. I think you > > should do that instead of PATCH 8/8 of your OMAP conversion to the > > generic driver[1]. > > Yep, thinking about this over lunch, I came to the same conclusion that > instead of checking on DT node existance, platform_device conversion > will solve both parts of the puzzle. Looked at this a little today. I see that the platform_driver CPUFreq driver approach was taken with several SoCs in mainline. Could someone explain the theory behind making the CPUFreq drivers platform_drivers, rather than just modules? The part that doesn't make sense to me is that the existing CPUFreq drivers don't represent an actual hardware block. Conceptually, they aren't drivers for the CPU, nor are they drivers for a CPU frequency scaling IP block. One might as well bind a CPUIdle driver or a CPU throttling thermal driver to the CPU device. Wouldn't it be best to just make them modules? Also, noticed that the Highbank CPUFreq driver creates a virtual device in its code. That also doesn't seem right. Isn't device creation better left to DT/ACPI/whatever? regards, - Paul ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-30 22:21 ` Paul Walmsley @ 2013-04-01 17:20 ` Eduardo Valentin 2013-04-01 19:14 ` Nishanth Menon 2013-04-01 19:27 ` Paul Walmsley 2013-04-01 19:46 ` Rob Herring 1 sibling, 2 replies; 15+ messages in thread From: Eduardo Valentin @ 2013-04-01 17:20 UTC (permalink / raw) To: linux-arm-kernel Hey Paul, On 30-03-2013 18:21, Paul Walmsley wrote: > Hi folks, > > On Wed, 27 Mar 2013, Nishanth Menon wrote: > >> On 10:53-20130327, Kevin Hilman wrote: >>> Nishanth Menon <nm@ti.com> writes: >>>> On 11:38-20130327, Rob Herring wrote: >>>>> On 03/27/2013 08:32 AM, Nishanth Menon wrote: >>>>>> On 02:23-20130327, Paul Walmsley wrote: >>>>>>> On Tue, 26 Mar 2013, Rob Herring wrote: >>>>>>>> >>>>>>>> Converting the driver to a platform driver would be another option. >>> >>> I think the platform_device conversion is the way to go. I think you >>> should do that instead of PATCH 8/8 of your OMAP conversion to the >>> generic driver[1]. >> >> Yep, thinking about this over lunch, I came to the same conclusion that >> instead of checking on DT node existance, platform_device conversion >> will solve both parts of the puzzle. > > Looked at this a little today. I see that the platform_driver CPUFreq > driver approach was taken with several SoCs in mainline. Could someone > explain the theory behind making the CPUFreq drivers platform_drivers, > rather than just modules? > > The part that doesn't make sense to me is that the existing CPUFreq > drivers don't represent an actual hardware block. Conceptually, they > aren't drivers for the CPU, nor are they drivers for a CPU frequency > scaling IP block. One might as well bind a CPUIdle driver or a CPU > throttling thermal driver to the CPU device. I do agree with your point. On the other hand, I'd like to make a clarification here. CPU throttling feature not really done as a driver. The feature is exported to be used by policies built by other code. Check drivers/thermal/cpu_cooling.c. Thermal drivers are in fact drivers, as they are bound to an actual hardware block, a bandgap, a thermal sensor or a thermistor. > > Wouldn't it be best to just make them modules? Thermal policies are built as modules. > > Also, noticed that the Highbank CPUFreq driver creates a virtual device in > its code. That also doesn't seem right. Isn't device creation better > left to DT/ACPI/whatever? > > > regards, > > - Paul > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-04-01 17:20 ` Eduardo Valentin @ 2013-04-01 19:14 ` Nishanth Menon 2013-04-01 19:27 ` Paul Walmsley 1 sibling, 0 replies; 15+ messages in thread From: Nishanth Menon @ 2013-04-01 19:14 UTC (permalink / raw) To: linux-arm-kernel +cpufreq list as it seems most appropriate discussion forum. discussion thread: http://marc.info/?t=136434901900001&r=1&w=2 On Mon, Apr 1, 2013 at 12:20 PM, Eduardo Valentin <eduardo.valentin@ti.com> wrote: > Hey Paul, > > > On 30-03-2013 18:21, Paul Walmsley wrote: >> >> Hi folks, >> >> On Wed, 27 Mar 2013, Nishanth Menon wrote: >> >>> On 10:53-20130327, Kevin Hilman wrote: >>>> >>>> Nishanth Menon <nm@ti.com> writes: >>>>> >>>>> On 11:38-20130327, Rob Herring wrote: >>>>>> >>>>>> On 03/27/2013 08:32 AM, Nishanth Menon wrote: >>>>>>> >>>>>>> On 02:23-20130327, Paul Walmsley wrote: >>>>>>>> >>>>>>>> On Tue, 26 Mar 2013, Rob Herring wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Converting the driver to a platform driver would be another option. >>>> >>>> >>>> I think the platform_device conversion is the way to go. I think you >>>> should do that instead of PATCH 8/8 of your OMAP conversion to the >>>> generic driver[1]. >>> >>> >>> Yep, thinking about this over lunch, I came to the same conclusion that >>> instead of checking on DT node existance, platform_device conversion >>> will solve both parts of the puzzle. >> >> >> Looked at this a little today. I see that the platform_driver CPUFreq >> driver approach was taken with several SoCs in mainline. Could someone >> explain the theory behind making the CPUFreq drivers platform_drivers, >> rather than just modules? >> >> The part that doesn't make sense to me is that the existing CPUFreq >> drivers don't represent an actual hardware block. Conceptually, they >> aren't drivers for the CPU, nor are they drivers for a CPU frequency >> scaling IP block. One might as well bind a CPUIdle driver or a CPU >> throttling thermal driver to the CPU device. > > > I do agree with your point. On the other hand, I'd like to make a > clarification here. > > CPU throttling feature not really done as a driver. The feature is exported > to be used by policies built by other code. Check > drivers/thermal/cpu_cooling.c. > > Thermal drivers are in fact drivers, as they are bound to an actual hardware > block, a bandgap, a thermal sensor or a thermistor. > > > > >> >> Wouldn't it be best to just make them modules? > > > Thermal policies are built as modules. > > >> >> Also, noticed that the Highbank CPUFreq driver creates a virtual device in >> its code. That also doesn't seem right. Isn't device creation better >> left to DT/ACPI/whatever? >> Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-04-01 17:20 ` Eduardo Valentin 2013-04-01 19:14 ` Nishanth Menon @ 2013-04-01 19:27 ` Paul Walmsley 1 sibling, 0 replies; 15+ messages in thread From: Paul Walmsley @ 2013-04-01 19:27 UTC (permalink / raw) To: linux-arm-kernel Hi Eduardo, On Mon, 1 Apr 2013, Eduardo Valentin wrote: > On 30-03-2013 18:21, Paul Walmsley wrote: > > On Wed, 27 Mar 2013, Nishanth Menon wrote: > > > > > On 10:53-20130327, Kevin Hilman wrote: > > > > Nishanth Menon <nm@ti.com> writes: > > > > > On 11:38-20130327, Rob Herring wrote: > > > > > > On 03/27/2013 08:32 AM, Nishanth Menon wrote: > > > > > > > On 02:23-20130327, Paul Walmsley wrote: > > > > > > > > On Tue, 26 Mar 2013, Rob Herring wrote: > > > > > > > > > > > > > > > > > > Converting the driver to a platform driver would be another > > > > > > > > > option. > > > > > > > > I think the platform_device conversion is the way to go. I think you > > > > should do that instead of PATCH 8/8 of your OMAP conversion to the > > > > generic driver[1]. > > > > > > Yep, thinking about this over lunch, I came to the same conclusion that > > > instead of checking on DT node existance, platform_device conversion > > > will solve both parts of the puzzle. > > > > Looked at this a little today. I see that the platform_driver CPUFreq > > driver approach was taken with several SoCs in mainline. Could someone > > explain the theory behind making the CPUFreq drivers platform_drivers, > > rather than just modules? > > > > The part that doesn't make sense to me is that the existing CPUFreq > > drivers don't represent an actual hardware block. Conceptually, they > > aren't drivers for the CPU, nor are they drivers for a CPU frequency > > scaling IP block. One might as well bind a CPUIdle driver or a CPU > > throttling thermal driver to the CPU device. > > I do agree with your point. On the other hand, I'd like to make a > clarification here. > > CPU throttling feature not really done as a driver. The feature is exported to > be used by policies built by other code. Check drivers/thermal/cpu_cooling.c. > > Thermal drivers are in fact drivers, as they are bound to an actual hardware > block, a bandgap, a thermal sensor or a thermistor. That might be the case for some or all of what's in mainline for the thermal framework. But I've seen at least one Linux BSP for an ARM SoC implement a thermal "cooling device" that isn't directly backed by any hardware IP block. Anyway, this is kind of a tangent. - Paul ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-30 22:21 ` Paul Walmsley 2013-04-01 17:20 ` Eduardo Valentin @ 2013-04-01 19:46 ` Rob Herring 2013-04-01 21:58 ` Paul Walmsley 1 sibling, 1 reply; 15+ messages in thread From: Rob Herring @ 2013-04-01 19:46 UTC (permalink / raw) To: linux-arm-kernel On 03/30/2013 05:21 PM, Paul Walmsley wrote: > Hi folks, > > On Wed, 27 Mar 2013, Nishanth Menon wrote: > >> On 10:53-20130327, Kevin Hilman wrote: >>> Nishanth Menon <nm@ti.com> writes: >>>> On 11:38-20130327, Rob Herring wrote: >>>>> On 03/27/2013 08:32 AM, Nishanth Menon wrote: >>>>>> On 02:23-20130327, Paul Walmsley wrote: >>>>>>> On Tue, 26 Mar 2013, Rob Herring wrote: >>>>>>>> >>>>>>>> Converting the driver to a platform driver would be another option. >>> >>> I think the platform_device conversion is the way to go. I think you >>> should do that instead of PATCH 8/8 of your OMAP conversion to the >>> generic driver[1]. >> >> Yep, thinking about this over lunch, I came to the same conclusion that >> instead of checking on DT node existance, platform_device conversion >> will solve both parts of the puzzle. > > Looked at this a little today. I see that the platform_driver CPUFreq > driver approach was taken with several SoCs in mainline. Could someone > explain the theory behind making the CPUFreq drivers platform_drivers, > rather than just modules? > > The part that doesn't make sense to me is that the existing CPUFreq > drivers don't represent an actual hardware block. Conceptually, they > aren't drivers for the CPU, nor are they drivers for a CPU frequency > scaling IP block. One might as well bind a CPUIdle driver or a CPU > throttling thermal driver to the CPU device. It's not really a cpu device, but rather a virtual device. We could have multiple devices. cpuidle drivers have the same issue. > Wouldn't it be best to just make them modules? Then module auto loading doesn't work AFAIK. We will want them to be built as modules in multi-platform kernels to reduce the kernel size, but you don't want to just shift the problem to the OS to decide what modules a given platform needs. > Also, noticed that the Highbank CPUFreq driver creates a virtual device in > its code. That also doesn't seem right. Isn't device creation better > left to DT/ACPI/whatever? DT describes the h/w. Creating DT nodes that match the cpufreq drivers is not describing the h/w, but what Linux wants currently. Cpufreq drivers either touch parts of multiple h/w blocks, a single shared h/w block or don't touch h/w directly. The cpufreq-cpu0 driver is the last case and does use DT. Perhaps we will get to the point that all low-level interfaces are abstracted and we can have a single cpufreq driver. I think platform drivers are the right way to go, but I'd like to come up with a better way to instantiate the devices. The only idea I've come up with is to do some sort of automatic device creation based machine compatible property matching. Rob ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-04-01 19:46 ` Rob Herring @ 2013-04-01 21:58 ` Paul Walmsley 0 siblings, 0 replies; 15+ messages in thread From: Paul Walmsley @ 2013-04-01 21:58 UTC (permalink / raw) To: linux-arm-kernel Hi On Mon, 1 Apr 2013, Rob Herring wrote: > On 03/30/2013 05:21 PM, Paul Walmsley wrote: > > > > Looked at this a little today. I see that the platform_driver CPUFreq > > driver approach was taken with several SoCs in mainline. Could someone > > explain the theory behind making the CPUFreq drivers platform_drivers, > > rather than just modules? > > > > The part that doesn't make sense to me is that the existing CPUFreq > > drivers don't represent an actual hardware block. Conceptually, they > > aren't drivers for the CPU, nor are they drivers for a CPU frequency > > scaling IP block. One might as well bind a CPUIdle driver or a CPU > > throttling thermal driver to the CPU device. > > > > Wouldn't it be best to just make them modules? > > Then module auto loading doesn't work AFAIK. We will want them to be > built as modules in multi-platform kernels to reduce the kernel size, > but you don't want to just shift the problem to the OS to decide what > modules a given platform needs. > > > Also, noticed that the Highbank CPUFreq driver creates a virtual device in > > its code. That also doesn't seem right. Isn't device creation better > > left to DT/ACPI/whatever? > > DT describes the h/w. Creating DT nodes that match the cpufreq drivers > is not describing the h/w, but what Linux wants currently. Cpufreq > drivers either touch parts of multiple h/w blocks, a single shared h/w > block or don't touch h/w directly. The cpufreq-cpu0 driver is the last > case and does use DT. Perhaps we will get to the point that all > low-level interfaces are abstracted and we can have a single cpufreq driver. > > I think platform drivers are the right way to go, but I'd like to come > up with a better way to instantiate the devices. The only idea I've come > up with is to do some sort of automatic device creation based machine > compatible property matching. So sounds like DT is expected to be used in a Linux-specific way as a /etc/modules replacement. Why not create a Linux-specific DT node that can be used to load any module? Wouldn't that have the same effect, but avoid creating false device nodes that don't exist in the hardware? - Paul ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 13:32 ` Nishanth Menon 2013-03-27 16:38 ` Rob Herring @ 2013-03-27 17:48 ` Paul Walmsley 2013-03-27 18:02 ` Nishanth Menon 1 sibling, 1 reply; 15+ messages in thread From: Paul Walmsley @ 2013-03-27 17:48 UTC (permalink / raw) To: linux-arm-kernel Hi On Wed, 27 Mar 2013, Nishanth Menon wrote: > We should deprecate usage on omap-cpufreq driver eventually, instead go > towards embracing the SoC generic implementation of cpufreq-cpu0 driver > IMHO. > http://marc.info/?l=linux-omap&m=136371580826031&w=2 > is the series to support cpufreq_cpu0 driver in DT based boot. > Would you think this approach is sane? Haven't looked closely at the series, but the idea makes sense to me, as long as OMAP doesn't need to do anything too exotic in the CPUFreq driver. - Paul ^ permalink raw reply [flat|nested] 15+ messages in thread
* omap cpufreq driver in multi-platform kernels 2013-03-27 17:48 ` Paul Walmsley @ 2013-03-27 18:02 ` Nishanth Menon 0 siblings, 0 replies; 15+ messages in thread From: Nishanth Menon @ 2013-03-27 18:02 UTC (permalink / raw) To: linux-arm-kernel On 17:48-20130327, Paul Walmsley wrote: > Hi > > On Wed, 27 Mar 2013, Nishanth Menon wrote: > > > We should deprecate usage on omap-cpufreq driver eventually, instead go > > towards embracing the SoC generic implementation of cpufreq-cpu0 driver > > IMHO. > > http://marc.info/?l=linux-omap&m=136371580826031&w=2 > > is the series to support cpufreq_cpu0 driver in DT based boot. > > Would you think this approach is sane? > > Haven't looked closely at the series, but the idea makes sense to me, as Thanks. > long as OMAP doesn't need to do anything too exotic in the CPUFreq driver. :) I wish that were the case, from an SoC entitlement point of view, purely controlling frequency and regulator is not sufficent for most OMAPs/AM variants. We do have to deal with ABB and AVS (now a multitude of class variants to deal with) - part of the rationale for switching to generic cpufreq as part of DT steps is to force ourselves to adhere to common code and entitle required SoC feature set. If you get a chance, it would be nice to hear your views on the intermediate step(the patch series pointed above) as part of overall OMAP transition to DT. -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-04-01 21:58 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-27 1:49 omap cpufreq driver in multi-platform kernels Rob Herring 2013-03-27 2:23 ` Paul Walmsley 2013-03-27 13:32 ` Nishanth Menon 2013-03-27 16:38 ` Rob Herring 2013-03-27 17:02 ` Nishanth Menon 2013-03-27 17:53 ` Kevin Hilman 2013-03-27 17:56 ` Nishanth Menon 2013-03-30 22:21 ` Paul Walmsley 2013-04-01 17:20 ` Eduardo Valentin 2013-04-01 19:14 ` Nishanth Menon 2013-04-01 19:27 ` Paul Walmsley 2013-04-01 19:46 ` Rob Herring 2013-04-01 21:58 ` Paul Walmsley 2013-03-27 17:48 ` Paul Walmsley 2013-03-27 18:02 ` Nishanth Menon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).