spurious bL cpufreq driver messages

spurious bL cpufreq driver messages

[Rob Herring]

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

spurious bL cpufreq driver messages

[Rob Herring]

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

Re: spurious bL cpufreq driver messages

[Viresh Kumar]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

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.

[-- Attachment #2: 0001-cpufreq-arm_big_little_dt-Register-driver-only-if-DT.patch --]
[-- Type: application/octet-stream, Size: 3967 bytes --]

From 94a514cbf8edab0f253e0adb1ae0e2e761203ba6 Mon Sep 17 00:00:00 2001
Message-Id: <94a514cbf8edab0f253e0adb1ae0e2e761203ba6.1368842612.git.viresh.kumar@linaro.org>
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Thu, 16 May 2013 19:19:37 +0530
Subject: [PATCH] cpufreq: arm_big_little_dt: Register driver only if DT has
 valid data

If arm_big_little_dt driver is enabled, then it will always try to register with
big LITTLE cpufreq core driver. In case DT doesn't have relevant data for cpu
nodes, i.e. operating points aren't present, then we should exit early and
shouldn't register with big LITTLE cpufreq core driver. Otherwise we will fail
continuously from the driver->init() routine.

This patch fixes this issue.

Reported-by: Jon Medhurst <tixy@linaro.org>
Reviewed-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/cpufreq/arm_big_little_dt.c | 73 +++++++++++++++++++++----------------
 1 file changed, 42 insertions(+), 31 deletions(-)

diff --git a/drivers/cpufreq/arm_big_little_dt.c b/drivers/cpufreq/arm_big_little_dt.c
index 173ed05..27e2f45 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -19,6 +19,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/device.h>
 #include <linux/export.h>
@@ -29,60 +30,63 @@
 #include <linux/types.h>
 #include "arm_big_little.h"
 
-static int dt_init_opp_table(struct device *cpu_dev)
+/* get cpu node with valid operating-points */
+static struct device_node *get_cpu_node_with_valid_op(int cpu)
 {
-	struct device_node *np, *parent;
-	int count = 0, ret;
+	struct device_node *np = NULL, *parent;
+	int count = 0;
 
 	parent = of_find_node_by_path("/cpus");
 	if (!parent) {
 		pr_err("failed to find OF /cpus\n");
-		return -ENOENT;
+		return NULL;
 	}
 
 	for_each_child_of_node(parent, np) {
-		if (count++ != cpu_dev->id)
+		if (count++ != cpu)
 			continue;
 		if (!of_get_property(np, "operating-points", NULL)) {
-			ret = -ENODATA;
-		} else {
-			cpu_dev->of_node = np;
-			ret = of_init_opp_table(cpu_dev);
+			of_node_put(np);
+			np = NULL;
 		}
-		of_node_put(np);
-		of_node_put(parent);
 
-		return ret;
+		break;
 	}
 
-	return -ENODEV;
+	of_node_put(parent);
+	return np;
+}
+
+static int dt_init_opp_table(struct device *cpu_dev)
+{
+	struct device_node *np;
+	int ret;
+
+	np = get_cpu_node_with_valid_op(cpu_dev->id);
+	if (!np)
+		return -ENODATA;
+
+	cpu_dev->of_node = np;
+	ret = of_init_opp_table(cpu_dev);
+	of_node_put(np);
+
+	return ret;
 }
 
 static int dt_get_transition_latency(struct device *cpu_dev)
 {
-	struct device_node *np, *parent;
+	struct device_node *np;
 	u32 transition_latency = CPUFREQ_ETERNAL;
-	int count = 0;
 
-	parent = of_find_node_by_path("/cpus");
-	if (!parent) {
-		pr_info("Failed to find OF /cpus. Use CPUFREQ_ETERNAL transition latency\n");
+	np = get_cpu_node_with_valid_op(cpu_dev->id);
+	if (!np)
 		return CPUFREQ_ETERNAL;
-	}
-
-	for_each_child_of_node(parent, np) {
-		if (count++ != cpu_dev->id)
-			continue;
-
-		of_property_read_u32(np, "clock-latency", &transition_latency);
-		of_node_put(np);
-		of_node_put(parent);
 
-		return transition_latency;
-	}
+	of_property_read_u32(np, "clock-latency", &transition_latency);
+	of_node_put(np);
 
-	pr_info("clock-latency isn't found, use CPUFREQ_ETERNAL transition latency\n");
-	return CPUFREQ_ETERNAL;
+	pr_debug("%s: clock-latency: %d\n", __func__, transition_latency);
+	return transition_latency;
 }
 
 static struct cpufreq_arm_bL_ops dt_bL_ops = {
@@ -93,6 +97,13 @@ static struct cpufreq_arm_bL_ops dt_bL_ops = {
 
 static int generic_bL_init(void)
 {
+	struct device_node *np;
+
+	np = get_cpu_node_with_valid_op(0);
+	if (!np)
+		return -ENODEV;
+
+	of_node_put(np);
 	return bL_cpufreq_register(&dt_bL_ops);
 }
 module_init(generic_bL_init);
-- 
1.7.12.rc2.18.g61b472e

spurious bL cpufreq driver messages

[Viresh Kumar]

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>

Re: spurious bL cpufreq driver messages

[Rob Herring]

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@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

spurious bL cpufreq driver messages

[Rob Herring]

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

Re: spurious bL cpufreq driver messages

[Viresh Kumar]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]

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");

[-- Attachment #2: 0001-cpufreq-arm_big_little_dt-Instantiate-as-platform_dr.patch --]
[-- Type: application/octet-stream, Size: 2494 bytes --]

From a0b7d38fbb3a34611723534d7976c61895b4f01a Mon Sep 17 00:00:00 2001
Message-Id: <a0b7d38fbb3a34611723534d7976c61895b4f01a.1369024302.git.viresh.kumar@linaro.org>
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");
-- 
1.7.12.rc2.18.g61b472e

spurious bL cpufreq driver messages

[Viresh Kumar]

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>

Re: spurious bL cpufreq driver messages

[Rob Herring]

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>

spurious bL cpufreq driver messages

[Rob Herring]

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>

Re: spurious bL cpufreq driver messages

[Rafael J. Wysocki]

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.

spurious bL cpufreq driver messages

[Rafael J. Wysocki]

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.

Re: spurious bL cpufreq driver messages

[Viresh Kumar]

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

spurious bL cpufreq driver messages

[Viresh Kumar]

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

Re: spurious bL cpufreq driver messages

[Viresh Kumar]

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.

spurious bL cpufreq driver messages

[Viresh Kumar]

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.

Re: spurious bL cpufreq driver messages

[Rafael J. Wysocki]

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.

spurious bL cpufreq driver messages

[Rafael J. Wysocki]

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.