* omap cpufreq driver in multi-platform kernels
@ 2013-03-27 13:32 ` Nishanth Menon
0 siblings, 0 replies; 30+ 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] 30+ messages in thread* Re: omap cpufreq driver in multi-platform kernels
2013-03-27 13:32 ` Nishanth Menon
@ 2013-03-27 16:38 ` Rob Herring
-1 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2013-03-27 16:38 UTC (permalink / raw)
To: Nishanth Menon
Cc: Paul Walmsley, Kevin Hilman, Tony Lindgren,
linux-arm-kernel@lists.infradead.org, Shawn Guo, linux-pm,
Mark Langsdorf
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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 30+ messages in thread* omap cpufreq driver in multi-platform kernels
@ 2013-03-27 16:38 ` Rob Herring
0 siblings, 0 replies; 30+ 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] 30+ messages in thread* Re: omap cpufreq driver in multi-platform kernels
2013-03-27 16:38 ` Rob Herring
@ 2013-03-27 17:02 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2013-03-27 17:02 UTC (permalink / raw)
To: Rob Herring
Cc: Paul Walmsley, Kevin Hilman, Tony Lindgren,
linux-arm-kernel@lists.infradead.org, Shawn Guo, linux-pm,
Mark Langsdorf
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-03-27 17:02 ` Nishanth Menon
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-03-27 17:02 ` Nishanth Menon
@ 2013-03-27 17:53 ` Kevin Hilman
-1 siblings, 0 replies; 30+ messages in thread
From: Kevin Hilman @ 2013-03-27 17:53 UTC (permalink / raw)
To: Nishanth Menon
Cc: Rob Herring, Paul Walmsley, Tony Lindgren,
linux-arm-kernel@lists.infradead.org, Shawn Guo, linux-pm,
Mark Langsdorf
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-03-27 17:53 ` Kevin Hilman
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-03-27 17:53 ` Kevin Hilman
@ 2013-03-27 17:56 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2013-03-27 17:56 UTC (permalink / raw)
To: Kevin Hilman
Cc: Rob Herring, Paul Walmsley, Tony Lindgren,
linux-arm-kernel@lists.infradead.org, Shawn Guo, linux-pm,
Mark Langsdorf
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-03-27 17:56 ` Nishanth Menon
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-03-27 17:56 ` Nishanth Menon
@ 2013-03-30 22:21 ` Paul Walmsley
-1 siblings, 0 replies; 30+ messages in thread
From: Paul Walmsley @ 2013-03-30 22:21 UTC (permalink / raw)
To: Nishanth Menon, Kevin Hilman, Mark Langsdorf, Shawn Guo,
Rob Herring
Cc: Tony Lindgren, linux-arm-kernel@lists.infradead.org, linux-pm
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-03-30 22:21 ` Paul Walmsley
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-03-30 22:21 ` Paul Walmsley
@ 2013-04-01 17:20 ` Eduardo Valentin
-1 siblings, 0 replies; 30+ messages in thread
From: Eduardo Valentin @ 2013-04-01 17:20 UTC (permalink / raw)
To: Paul Walmsley
Cc: Nishanth Menon, Kevin Hilman, Mark Langsdorf, Shawn Guo,
Rob Herring, Tony Lindgren, linux-arm-kernel@lists.infradead.org,
linux-pm, eduardo.valentin
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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-04-01 17:20 ` Eduardo Valentin
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-04-01 17:20 ` Eduardo Valentin
@ 2013-04-01 19:14 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2013-04-01 19:14 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Paul Walmsley, Kevin Hilman, Mark Langsdorf, linux-pm,
Tony Lindgren, Shawn Guo, linux-arm-kernel@lists.infradead.org,
cpufreq
+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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-04-01 19:14 ` Nishanth Menon
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-04-01 17:20 ` Eduardo Valentin
@ 2013-04-01 19:27 ` Paul Walmsley
-1 siblings, 0 replies; 30+ messages in thread
From: Paul Walmsley @ 2013-04-01 19:27 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Nishanth Menon, Kevin Hilman, Mark Langsdorf, Shawn Guo,
Rob Herring, Tony Lindgren, linux-arm-kernel@lists.infradead.org,
linux-pm, cpufreq
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-04-01 19:27 ` Paul Walmsley
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-03-30 22:21 ` Paul Walmsley
@ 2013-04-01 19:46 ` Rob Herring
-1 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2013-04-01 19:46 UTC (permalink / raw)
To: Paul Walmsley
Cc: Nishanth Menon, Kevin Hilman, Mark Langsdorf, Shawn Guo,
Tony Lindgren, linux-arm-kernel@lists.infradead.org, linux-pm
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-04-01 19:46 ` Rob Herring
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-04-01 19:46 ` Rob Herring
@ 2013-04-01 21:58 ` Paul Walmsley
-1 siblings, 0 replies; 30+ messages in thread
From: Paul Walmsley @ 2013-04-01 21:58 UTC (permalink / raw)
To: Rob Herring
Cc: Nishanth Menon, Kevin Hilman, Mark Langsdorf, Shawn Guo,
Tony Lindgren, linux-arm-kernel@lists.infradead.org, linux-pm,
cpufreq
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-04-01 21:58 ` Paul Walmsley
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-03-27 13:32 ` Nishanth Menon
@ 2013-03-27 17:48 ` Paul Walmsley
-1 siblings, 0 replies; 30+ messages in thread
From: Paul Walmsley @ 2013-03-27 17:48 UTC (permalink / raw)
To: Nishanth Menon
Cc: Rob Herring, Kevin Hilman, Tony Lindgren,
linux-arm-kernel@lists.infradead.org, Shawn Guo, linux-pm,
Mark Langsdorf
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-03-27 17:48 ` Paul Walmsley
0 siblings, 0 replies; 30+ 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] 30+ messages in thread
* Re: omap cpufreq driver in multi-platform kernels
2013-03-27 17:48 ` Paul Walmsley
@ 2013-03-27 18:02 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2013-03-27 18:02 UTC (permalink / raw)
To: Paul Walmsley
Cc: Rob Herring, Kevin Hilman, Tony Lindgren,
linux-arm-kernel@lists.infradead.org, Shawn Guo, linux-pm,
Mark Langsdorf
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] 30+ messages in thread
* omap cpufreq driver in multi-platform kernels
@ 2013-03-27 18:02 ` Nishanth Menon
0 siblings, 0 replies; 30+ 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] 30+ messages in thread