* 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 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
* 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
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).