* spurious bL cpufreq driver messages
@ 2013-05-17 19:36 Rob Herring
2013-05-18 2:03 ` Viresh Kumar
0 siblings, 1 reply; 9+ messages in thread
From: Rob Herring @ 2013-05-17 19:36 UTC (permalink / raw)
To: linux-arm-kernel
The bL cpufreq driver appears to collide with the cpufreq-cpu0 driver.
There doesn't appear to be a functional problem, but just spurious
prints which indicate it is trying to do something. I think it needs
better checking whether the chip is actually multi-cluster. This is what
I get when I hotplug cpus:
[ 909.372319] CPU1: Booted secondary processor
[ 909.372616] cpu cpu1: get_cluster_clk_and_freq_table: init_opp_table
failed, cpu: 1, err: -61
[ 909.385411] cpu cpu1: get_cluster_clk_and_freq_table: Failed to get
data for cluster: 9
[ 909.394161] CPU2: shutdown
[ 909.400957] CPU2: Booted secondary processor
[ 909.401253] cpu cpu2: get_cluster_clk_and_freq_table: init_opp_table
failed, cpu: 2, err: -61
[ 909.414044] cpu cpu2: get_cluster_clk_and_freq_table: Failed to get
data for cluster: 9
Rob
^ permalink raw reply [flat|nested] 9+ messages in thread
* spurious bL cpufreq driver messages
2013-05-17 19:36 spurious bL cpufreq driver messages Rob Herring
@ 2013-05-18 2:03 ` Viresh Kumar
2013-05-18 19:51 ` Rob Herring
0 siblings, 1 reply; 9+ messages in thread
From: Viresh Kumar @ 2013-05-18 2:03 UTC (permalink / raw)
To: linux-arm-kernel
On 18 May 2013 01:06, Rob Herring <robherring2@gmail.com> wrote:
> The bL cpufreq driver appears to collide with the cpufreq-cpu0 driver.
> There doesn't appear to be a functional problem, but just spurious
> prints which indicate it is trying to do something. I think it needs
> better checking whether the chip is actually multi-cluster. This is what
> I get when I hotplug cpus:
>
> [ 909.372319] CPU1: Booted secondary processor
> [ 909.372616] cpu cpu1: get_cluster_clk_and_freq_table: init_opp_table
> failed, cpu: 1, err: -61
> [ 909.385411] cpu cpu1: get_cluster_clk_and_freq_table: Failed to get
> data for cluster: 9
> [ 909.394161] CPU2: shutdown
> [ 909.400957] CPU2: Booted secondary processor
> [ 909.401253] cpu cpu2: get_cluster_clk_and_freq_table: init_opp_table
> failed, cpu: 2, err: -61
> [ 909.414044] cpu cpu2: get_cluster_clk_and_freq_table: Failed to get
> data for cluster: 9
See if this fixes your issue.
https://groups.google.com/forum/?fromgroups#!topic/linux.kernel/XJF-82rad4o
Attached too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cpufreq-arm_big_little_dt-Register-driver-only-if-DT.patch
Type: application/octet-stream
Size: 3967 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130518/88214fa6/attachment.obj>
^ permalink raw reply [flat|nested] 9+ messages in thread
* spurious bL cpufreq driver messages
2013-05-18 2:03 ` Viresh Kumar
@ 2013-05-18 19:51 ` Rob Herring
2013-05-20 4:36 ` Viresh Kumar
0 siblings, 1 reply; 9+ messages in thread
From: Rob Herring @ 2013-05-18 19:51 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 17, 2013 at 9:03 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 18 May 2013 01:06, Rob Herring <robherring2@gmail.com> wrote:
>> The bL cpufreq driver appears to collide with the cpufreq-cpu0 driver.
>> There doesn't appear to be a functional problem, but just spurious
>> prints which indicate it is trying to do something. I think it needs
>> better checking whether the chip is actually multi-cluster. This is what
>> I get when I hotplug cpus:
>>
>> [ 909.372319] CPU1: Booted secondary processor
>> [ 909.372616] cpu cpu1: get_cluster_clk_and_freq_table: init_opp_table
>> failed, cpu: 1, err: -61
>> [ 909.385411] cpu cpu1: get_cluster_clk_and_freq_table: Failed to get
>> data for cluster: 9
>> [ 909.394161] CPU2: shutdown
>> [ 909.400957] CPU2: Booted secondary processor
>> [ 909.401253] cpu cpu2: get_cluster_clk_and_freq_table: init_opp_table
>> failed, cpu: 2, err: -61
>> [ 909.414044] cpu cpu2: get_cluster_clk_and_freq_table: Failed to get
>> data for cluster: 9
>
> See if this fixes your issue.
>
> https://groups.google.com/forum/?fromgroups#!topic/linux.kernel/XJF-82rad4o
>
> Attached too.
No, it still registers the bL driver. The problem is not that DT data
is missing, but it is present on a single cluster system. This is what
my 1st cpu node looks like:
$ ls /proc/device-tree/cpus/cpu at 900/
clock-latency clocks device_type next-level-cache reg
clock-names compatible name operating-points transition-latency
This is the boot log:
[ 1.192186] cpu cpu0: get_cluster_clk_and_freq_table: Failed to get
clk for cpu: 0, cluster: 9
[ 1.200804] cpu cpu0: get_cluster_clk_and_freq_table: Failed to get
data for cluster: 9
[ 1.208815] cpu cpu1: get_cluster_clk_and_freq_table:
init_opp_table failed, cpu: 1, err: -61
[ 1.217345] cpu cpu1: get_cluster_clk_and_freq_table: Failed to get
data for cluster: 9
[ 1.225354] cpu cpu2: get_cluster_clk_and_freq_table:
init_opp_table failed, cpu: 2, err: -61
[ 1.233879] cpu cpu2: get_cluster_clk_and_freq_table: Failed to get
data for cluster: 9
[ 1.241880] cpu cpu3: get_cluster_clk_and_freq_table:
init_opp_table failed, cpu: 3, err: -61
[ 1.250403] cpu cpu3: get_cluster_clk_and_freq_table: Failed to get
data for cluster: 9
[ 1.258406] arm_big_little: bL_cpufreq_register: Registered
platform driver: dt-bl
[ 1.266123] cpufreq_cpu0: failed to get cpu0 regulator: -19
[ 1.271704] cpufreq_cpu0: failed register driver: -16
[ 1.276764] cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -16
Rob
^ permalink raw reply [flat|nested] 9+ messages in thread
* spurious bL cpufreq driver messages
2013-05-18 19:51 ` Rob Herring
@ 2013-05-20 4:36 ` Viresh Kumar
2013-05-21 16:42 ` Rob Herring
2013-05-21 23:45 ` Rafael J. Wysocki
0 siblings, 2 replies; 9+ messages in thread
From: Viresh Kumar @ 2013-05-20 4:36 UTC (permalink / raw)
To: linux-arm-kernel
On 19 May 2013 01:21, Rob Herring <robherring2@gmail.com> wrote:
> No, it still registers the bL driver. The problem is not that DT data
> is missing, but it is present on a single cluster system.
I misread your mail.. I got the problem now.. Below should fix your
issue (It is rebased on the patch I pointed to you earlier):
Attached too for testing as gmail copy-paste will break it.
@Rafael: Once Rob gives his Tested-by, please queue it for 3.10-rcs
------------x-----------------x-----------------
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Mon, 20 May 2013 09:57:17 +0530
Subject: [PATCH] cpufreq: arm_big_little_dt: Instantiate as platform_driver
As multiplatform build is being adopted by more and more ARM platforms, initcall
function should be used very carefully. For example, when both arm_big_little_dt
and cpufreq-cpu0 drivers are compiled in, arm_big_little_dt driver may try to
register even if we had platform device for cpufreq-cpu0 registered.
To eliminate this undesired the effect, the patch changes arm_big_little_dt
driver to have it instantiated as a platform_driver. Then it will only run on
platforms that create the platform_device "arm-bL-cpufreq-dt".
Reported-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/arm_big_little_dt.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little_dt.c
b/drivers/cpufreq/arm_big_little_dt.c
index 27e2f45..fd9e3ea 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -26,6 +26,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/opp.h>
+#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/types.h>
#include "arm_big_little.h"
@@ -95,7 +96,7 @@ static struct cpufreq_arm_bL_ops dt_bL_ops = {
.init_opp_table = dt_init_opp_table,
};
-static int generic_bL_init(void)
+static int generic_bL_probe(struct platform_device *pdev)
{
struct device_node *np;
@@ -106,13 +107,22 @@ static int generic_bL_init(void)
of_node_put(np);
return bL_cpufreq_register(&dt_bL_ops);
}
-module_init(generic_bL_init);
-static void generic_bL_exit(void)
+static int generic_bL_remove(struct platform_device *pdev)
{
- return bL_cpufreq_unregister(&dt_bL_ops);
+ bL_cpufreq_unregister(&dt_bL_ops);
+ return 0;
}
-module_exit(generic_bL_exit);
+
+static struct platform_driver generic_bL_platdrv = {
+ .driver = {
+ .name = "arm-bL-cpufreq-dt",
+ .owner = THIS_MODULE,
+ },
+ .probe = generic_bL_probe,
+ .remove = generic_bL_remove,
+};
+module_platform_driver(generic_bL_platdrv);
MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
MODULE_DESCRIPTION("Generic ARM big LITTLE cpufreq driver via DT");
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cpufreq-arm_big_little_dt-Instantiate-as-platform_dr.patch
Type: application/octet-stream
Size: 2494 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130520/e3af1072/attachment.obj>
^ permalink raw reply related [flat|nested] 9+ messages in thread
* spurious bL cpufreq driver messages
2013-05-20 4:36 ` Viresh Kumar
@ 2013-05-21 16:42 ` Rob Herring
2013-05-21 23:45 ` Rafael J. Wysocki
1 sibling, 0 replies; 9+ messages in thread
From: Rob Herring @ 2013-05-21 16:42 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, May 19, 2013 at 11:36 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 19 May 2013 01:21, Rob Herring <robherring2@gmail.com> wrote:
>> No, it still registers the bL driver. The problem is not that DT data
>> is missing, but it is present on a single cluster system.
>
> I misread your mail.. I got the problem now.. Below should fix your
> issue (It is rebased on the patch I pointed to you earlier):
>
> Attached too for testing as gmail copy-paste will break it.
>
> @Rafael: Once Rob gives his Tested-by, please queue it for 3.10-rcs
>
> ------------x-----------------x-----------------
>
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Date: Mon, 20 May 2013 09:57:17 +0530
> Subject: [PATCH] cpufreq: arm_big_little_dt: Instantiate as platform_driver
>
> As multiplatform build is being adopted by more and more ARM platforms, initcall
> function should be used very carefully. For example, when both arm_big_little_dt
> and cpufreq-cpu0 drivers are compiled in, arm_big_little_dt driver may try to
> register even if we had platform device for cpufreq-cpu0 registered.
>
> To eliminate this undesired the effect, the patch changes arm_big_little_dt
> driver to have it instantiated as a platform_driver. Then it will only run on
> platforms that create the platform_device "arm-bL-cpufreq-dt".
>
> Reported-by: Rob Herring <robherring2@gmail.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
That works. Thanks.
Tested-by: Rob Herring <rob.herring@calxeda.com>
^ permalink raw reply [flat|nested] 9+ messages in thread
* spurious bL cpufreq driver messages
2013-05-20 4:36 ` Viresh Kumar
2013-05-21 16:42 ` Rob Herring
@ 2013-05-21 23:45 ` Rafael J. Wysocki
2013-05-22 1:14 ` Viresh Kumar
1 sibling, 1 reply; 9+ messages in thread
From: Rafael J. Wysocki @ 2013-05-21 23:45 UTC (permalink / raw)
To: linux-arm-kernel
On Monday, May 20, 2013 10:06:49 AM Viresh Kumar wrote:
> On 19 May 2013 01:21, Rob Herring <robherring2@gmail.com> wrote:
> > No, it still registers the bL driver. The problem is not that DT data
> > is missing, but it is present on a single cluster system.
>
> I misread your mail.. I got the problem now.. Below should fix your
> issue (It is rebased on the patch I pointed to you earlier):
>
> Attached too for testing as gmail copy-paste will break it.
>
> @Rafael: Once Rob gives his Tested-by, please queue it for 3.10-rcs
>
> ------------x-----------------x-----------------
>
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Date: Mon, 20 May 2013 09:57:17 +0530
> Subject: [PATCH] cpufreq: arm_big_little_dt: Instantiate as platform_driver
>
> As multiplatform build is being adopted by more and more ARM platforms, initcall
> function should be used very carefully. For example, when both arm_big_little_dt
> and cpufreq-cpu0 drivers are compiled in, arm_big_little_dt driver may try to
> register even if we had platform device for cpufreq-cpu0 registered.
>
> To eliminate this undesired the effect, the patch changes arm_big_little_dt
> driver to have it instantiated as a platform_driver. Then it will only run on
> platforms that create the platform_device "arm-bL-cpufreq-dt".
>
> Reported-by: Rob Herring <robherring2@gmail.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
The patch (from the attachment) didn't apply for me. Please check the
bleeding-edge branch.
Thanks,
Rafael
> ---
> drivers/cpufreq/arm_big_little_dt.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/arm_big_little_dt.c
> b/drivers/cpufreq/arm_big_little_dt.c
> index 27e2f45..fd9e3ea 100644
> --- a/drivers/cpufreq/arm_big_little_dt.c
> +++ b/drivers/cpufreq/arm_big_little_dt.c
> @@ -26,6 +26,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/opp.h>
> +#include <linux/platform_device.h>
> #include <linux/slab.h>
> #include <linux/types.h>
> #include "arm_big_little.h"
> @@ -95,7 +96,7 @@ static struct cpufreq_arm_bL_ops dt_bL_ops = {
> .init_opp_table = dt_init_opp_table,
> };
>
> -static int generic_bL_init(void)
> +static int generic_bL_probe(struct platform_device *pdev)
> {
> struct device_node *np;
>
> @@ -106,13 +107,22 @@ static int generic_bL_init(void)
> of_node_put(np);
> return bL_cpufreq_register(&dt_bL_ops);
> }
> -module_init(generic_bL_init);
>
> -static void generic_bL_exit(void)
> +static int generic_bL_remove(struct platform_device *pdev)
> {
> - return bL_cpufreq_unregister(&dt_bL_ops);
> + bL_cpufreq_unregister(&dt_bL_ops);
> + return 0;
> }
> -module_exit(generic_bL_exit);
> +
> +static struct platform_driver generic_bL_platdrv = {
> + .driver = {
> + .name = "arm-bL-cpufreq-dt",
> + .owner = THIS_MODULE,
> + },
> + .probe = generic_bL_probe,
> + .remove = generic_bL_remove,
> +};
> +module_platform_driver(generic_bL_platdrv);
>
> MODULE_AUTHOR("Viresh Kumar <viresh.kumar@linaro.org>");
> MODULE_DESCRIPTION("Generic ARM big LITTLE cpufreq driver via DT");
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 9+ messages in thread
* spurious bL cpufreq driver messages
2013-05-21 23:45 ` Rafael J. Wysocki
@ 2013-05-22 1:14 ` Viresh Kumar
2013-05-22 10:54 ` Rafael J. Wysocki
0 siblings, 1 reply; 9+ messages in thread
From: Viresh Kumar @ 2013-05-22 1:14 UTC (permalink / raw)
To: linux-arm-kernel
On 22 May 2013 05:15, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday, May 20, 2013 10:06:49 AM Viresh Kumar wrote:
>> On 19 May 2013 01:21, Rob Herring <robherring2@gmail.com> wrote:
>> > No, it still registers the bL driver. The problem is not that DT data
>> > is missing, but it is present on a single cluster system.
>>
>> I misread your mail.. I got the problem now.. Below should fix your
>> issue (It is rebased on the patch I pointed to you earlier):
>>
>> Attached too for testing as gmail copy-paste will break it.
>>
>> @Rafael: Once Rob gives his Tested-by, please queue it for 3.10-rcs
>>
>> ------------x-----------------x-----------------
>>
>> From: Viresh Kumar <viresh.kumar@linaro.org>
>> Date: Mon, 20 May 2013 09:57:17 +0530
>> Subject: [PATCH] cpufreq: arm_big_little_dt: Instantiate as platform_driver
>>
>> As multiplatform build is being adopted by more and more ARM platforms, initcall
>> function should be used very carefully. For example, when both arm_big_little_dt
>> and cpufreq-cpu0 drivers are compiled in, arm_big_little_dt driver may try to
>> register even if we had platform device for cpufreq-cpu0 registered.
>>
>> To eliminate this undesired the effect, the patch changes arm_big_little_dt
>> driver to have it instantiated as a platform_driver. Then it will only run on
>> platforms that create the platform_device "arm-bL-cpufreq-dt".
>>
>> Reported-by: Rob Herring <robherring2@gmail.com>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> The patch (from the attachment) didn't apply for me. Please check the
> bleeding-edge branch.
Have you tried applying this before it (As written in my last mail)?
https://groups.google.com/forum/?fromgroups#!topic/linux.kernel/XJF-82rad4o
Above is also required fix for 3.10-rc3
^ permalink raw reply [flat|nested] 9+ messages in thread
* spurious bL cpufreq driver messages
2013-05-22 10:54 ` Rafael J. Wysocki
@ 2013-05-22 10:52 ` Viresh Kumar
0 siblings, 0 replies; 9+ messages in thread
From: Viresh Kumar @ 2013-05-22 10:52 UTC (permalink / raw)
To: linux-arm-kernel
On 22 May 2013 16:24, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Please check the bleeding-edge branch now and see if anything for-3.10-rc is
> still missing.
You have picked all my pending patches for current rc release.. All pending
are targeted for 3.11 or linux-next. So all good.
thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* spurious bL cpufreq driver messages
2013-05-22 1:14 ` Viresh Kumar
@ 2013-05-22 10:54 ` Rafael J. Wysocki
2013-05-22 10:52 ` Viresh Kumar
0 siblings, 1 reply; 9+ messages in thread
From: Rafael J. Wysocki @ 2013-05-22 10:54 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, May 22, 2013 06:44:20 AM Viresh Kumar wrote:
> On 22 May 2013 05:15, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Monday, May 20, 2013 10:06:49 AM Viresh Kumar wrote:
> >> On 19 May 2013 01:21, Rob Herring <robherring2@gmail.com> wrote:
> >> > No, it still registers the bL driver. The problem is not that DT data
> >> > is missing, but it is present on a single cluster system.
> >>
> >> I misread your mail.. I got the problem now.. Below should fix your
> >> issue (It is rebased on the patch I pointed to you earlier):
> >>
> >> Attached too for testing as gmail copy-paste will break it.
> >>
> >> @Rafael: Once Rob gives his Tested-by, please queue it for 3.10-rcs
> >>
> >> ------------x-----------------x-----------------
> >>
> >> From: Viresh Kumar <viresh.kumar@linaro.org>
> >> Date: Mon, 20 May 2013 09:57:17 +0530
> >> Subject: [PATCH] cpufreq: arm_big_little_dt: Instantiate as platform_driver
> >>
> >> As multiplatform build is being adopted by more and more ARM platforms, initcall
> >> function should be used very carefully. For example, when both arm_big_little_dt
> >> and cpufreq-cpu0 drivers are compiled in, arm_big_little_dt driver may try to
> >> register even if we had platform device for cpufreq-cpu0 registered.
> >>
> >> To eliminate this undesired the effect, the patch changes arm_big_little_dt
> >> driver to have it instantiated as a platform_driver. Then it will only run on
> >> platforms that create the platform_device "arm-bL-cpufreq-dt".
> >>
> >> Reported-by: Rob Herring <robherring2@gmail.com>
> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > The patch (from the attachment) didn't apply for me. Please check the
> > bleeding-edge branch.
>
> Have you tried applying this before it (As written in my last mail)?
No and I'm not sure which mail you're referring to. There's been quite
a number of them recently. :-)
> https://groups.google.com/forum/?fromgroups#!topic/linux.kernel/XJF-82rad4o
>
> Above is also required fix for 3.10-rc3
OK, that worked.
Please check the bleeding-edge branch now and see if anything for-3.10-rc is
still missing.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-05-22 10:54 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-17 19:36 spurious bL cpufreq driver messages Rob Herring
2013-05-18 2:03 ` Viresh Kumar
2013-05-18 19:51 ` Rob Herring
2013-05-20 4:36 ` Viresh Kumar
2013-05-21 16:42 ` Rob Herring
2013-05-21 23:45 ` Rafael J. Wysocki
2013-05-22 1:14 ` Viresh Kumar
2013-05-22 10:54 ` Rafael J. Wysocki
2013-05-22 10:52 ` Viresh Kumar
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).