| Message ID | 1359208550-16402-1-git-send-email-shawn.guo@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Saturday, January 26, 2013 09:55:50 PM Shawn Guo wrote: > As multiplatform build is being adopted by more and more ARM platforms, > initcall function should be used very carefully. For example, when > GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() > will be called on all the platforms to initialize cpufreq-cpu0 driver. > > To eliminate this undesired the effect, the patch changes cpufreq-cpu0 > driver to have it instantiated as a platform_driver. Then it will only > run on platforms that create the platform_device "cpufreq-cpu0". > > Along with the change, it also changes cpu_dev to be &pdev->dev, > so that managed functions can start working, and module build gets > supported too. > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > --- > Rafael, > > The patch depends patch "power: export opp cpufreq functions". > https://patchwork.kernel.org/patch/1847261/ That one should use EXPORT_SYMBOL_GPL() for exporting symbols, though. Care to add a fixed version to the patch set along with the $subject one? > AnilKumar, > > Unfortunately, the change will require some platform level adoption > to have cpufreq-cpu0 driver continue working for am33xx. But it should > be as simple as something like below. > > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", }; > platform_device_register_full(&devinfo); That should be included in your patch, then. Thanks, Rafael > drivers/cpufreq/Kconfig | 2 +- > drivers/cpufreq/cpufreq-cpu0.c | 35 +++++++++++++++++++++++------------ > 2 files changed, 24 insertions(+), 13 deletions(-) > > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index ea512f4..774dc1c 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -180,7 +180,7 @@ config CPU_FREQ_GOV_CONSERVATIVE > If in doubt, say N. > > config GENERIC_CPUFREQ_CPU0 > - bool "Generic CPU0 cpufreq driver" > + tristate "Generic CPU0 cpufreq driver" > depends on HAVE_CLK && REGULATOR && PM_OPP && OF > select CPU_FREQ_TABLE > help > diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c > index debc5a7..dae0667 100644 > --- a/drivers/cpufreq/cpufreq-cpu0.c > +++ b/drivers/cpufreq/cpufreq-cpu0.c > @@ -12,12 +12,12 @@ > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > #include <linux/clk.h> > -#include <linux/cpu.h> > #include <linux/cpufreq.h> > #include <linux/err.h> > #include <linux/module.h> > #include <linux/of.h> > #include <linux/opp.h> > +#include <linux/platform_device.h> > #include <linux/regulator/consumer.h> > #include <linux/slab.h> > > @@ -177,7 +177,7 @@ static struct cpufreq_driver cpu0_cpufreq_driver = { > .attr = cpu0_cpufreq_attr, > }; > > -static int cpu0_cpufreq_driver_init(void) > +static int cpu0_cpufreq_probe(struct platform_device *pdev) > { > struct device_node *np; > int ret; > @@ -188,23 +188,17 @@ static int cpu0_cpufreq_driver_init(void) > return -ENOENT; > } > > - cpu_dev = get_cpu_device(0); > - if (!cpu_dev) { > - pr_err("failed to get cpu0 device\n"); > - ret = -ENODEV; > - goto out_put_node; > - } > - > + cpu_dev = &pdev->dev; > cpu_dev->of_node = np; > > - cpu_clk = clk_get(cpu_dev, NULL); > + cpu_clk = devm_clk_get(cpu_dev, NULL); > if (IS_ERR(cpu_clk)) { > ret = PTR_ERR(cpu_clk); > pr_err("failed to get cpu0 clock: %d\n", ret); > goto out_put_node; > } > > - cpu_reg = regulator_get(cpu_dev, "cpu0"); > + cpu_reg = devm_regulator_get(cpu_dev, "cpu0"); > if (IS_ERR(cpu_reg)) { > pr_warn("failed to get cpu0 regulator\n"); > cpu_reg = NULL; > @@ -267,7 +261,24 @@ out_put_node: > of_node_put(np); > return ret; > } > -late_initcall(cpu0_cpufreq_driver_init); > + > +static int cpu0_cpufreq_remove(struct platform_device *pdev) > +{ > + cpufreq_unregister_driver(&cpu0_cpufreq_driver); > + opp_free_cpufreq_table(cpu_dev, &freq_table); > + > + return 0; > +} > + > +static struct platform_driver cpu0_cpufreq_platdrv = { > + .driver = { > + .name = "cpufreq-cpu0", > + .owner = THIS_MODULE, > + }, > + .probe = cpu0_cpufreq_probe, > + .remove = cpu0_cpufreq_remove, > +}; > +module_platform_driver(cpu0_cpufreq_platdrv); > > MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>"); > MODULE_DESCRIPTION("Generic CPU0 cpufreq driver"); >
On Sat, Jan 26, 2013 at 7:25 PM, Shawn Guo <shawn.guo@linaro.org> wrote: > As multiplatform build is being adopted by more and more ARM platforms, > initcall function should be used very carefully. For example, when > GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() > will be called on all the platforms to initialize cpufreq-cpu0 driver. > > To eliminate this undesired the effect, the patch changes cpufreq-cpu0 > driver to have it instantiated as a platform_driver. Then it will only > run on platforms that create the platform_device "cpufreq-cpu0". > > Along with the change, it also changes cpu_dev to be &pdev->dev, > so that managed functions can start working, and module build gets > supported too. > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > --- > Rafael, > > The patch depends patch "power: export opp cpufreq functions". > https://patchwork.kernel.org/patch/1847261/ > > AnilKumar, > > Unfortunately, the change will require some platform level adoption > to have cpufreq-cpu0 driver continue working for am33xx. But it should > be as simple as something like below. > > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", }; > platform_device_register_full(&devinfo); Something similar was being discussed with Andrew (cc'd) on his patch for kikwood cpufreq driver. We shouldn't encourage addition of above as we are moving towards DT. So, i would except an compatible array too in your patch and then driver can be probed based on compatible string being present in cpu node. What do you say? -- viresh
On Mon, Jan 28, 2013 at 09:42:29AM +0530, Viresh Kumar wrote: > > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", }; > > platform_device_register_full(&devinfo); > > Something similar was being discussed with Andrew (cc'd) on his patch > for kikwood cpufreq driver. > > We shouldn't encourage addition of above as we are moving towards DT. Moving towards DT does not really mean that we should never register platform_device from platform code. DT is designed to present physical devices, while what I'm adding here is somewhat a virtual one. I'm just using the platform_device/platform_driver mechanism to instantiate the driver on particular platform. > So, i would except an compatible array too in your patch and then driver > can be probed based on compatible string being present in cpu node. I believe device tree maintainer already stated that we should not have node/compatible for cpuidle/cpufreq such stuff in DT merely for asking DT core to create platform_device for them. Shawn
On 28 January 2013 12:32, Shawn Guo <shawn.guo@linaro.org> wrote: > On Mon, Jan 28, 2013 at 09:42:29AM +0530, Viresh Kumar wrote: >> > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", }; >> > platform_device_register_full(&devinfo); >> >> Something similar was being discussed with Andrew (cc'd) on his patch >> for kikwood cpufreq driver. >> >> We shouldn't encourage addition of above as we are moving towards DT. > > Moving towards DT does not really mean that we should never register > platform_device from platform code. DT is designed to present physical > devices, while what I'm adding here is somewhat a virtual one. I'm > just using the platform_device/platform_driver mechanism to instantiate > the driver on particular platform. > >> So, i would except an compatible array too in your patch and then driver >> can be probed based on compatible string being present in cpu node. > > I believe device tree maintainer already stated that we should not > have node/compatible for cpuidle/cpufreq such stuff in DT merely for > asking DT core to create platform_device for them. I see. I am really not sure if the alternative of DT node (i.e. platform_device) is good enough. @Arnd: What do you say?
On Sat, Jan 26, 2013 at 11:21:27PM +0100, Rafael J. Wysocki wrote: > On Saturday, January 26, 2013 09:55:50 PM Shawn Guo wrote: > > As multiplatform build is being adopted by more and more ARM platforms, > > initcall function should be used very carefully. For example, when > > GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() > > will be called on all the platforms to initialize cpufreq-cpu0 driver. > > > > To eliminate this undesired the effect, the patch changes cpufreq-cpu0 > > driver to have it instantiated as a platform_driver. Then it will only > > run on platforms that create the platform_device "cpufreq-cpu0". > > > > Along with the change, it also changes cpu_dev to be &pdev->dev, > > so that managed functions can start working, and module build gets > > supported too. > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > --- > > Rafael, > > > > The patch depends patch "power: export opp cpufreq functions". > > https://patchwork.kernel.org/patch/1847261/ > > That one should use EXPORT_SYMBOL_GPL() for exporting symbols, though. > When commit 80126ce (PM / OPP: Export symbols for module usage.) already exported a few symbols with EXPORT_SYMBOL()? > Care to add a fixed version to the patch set along with the $subject one? > > > AnilKumar, > > > > Unfortunately, the change will require some platform level adoption > > to have cpufreq-cpu0 driver continue working for am33xx. But it should > > be as simple as something like below. > > > > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", }; > > platform_device_register_full(&devinfo); > > That should be included in your patch, then. > Fair enough. Will do. Shawn
On Monday, January 28, 2013 04:32:01 PM Shawn Guo wrote: > On Sat, Jan 26, 2013 at 11:21:27PM +0100, Rafael J. Wysocki wrote: > > On Saturday, January 26, 2013 09:55:50 PM Shawn Guo wrote: > > > As multiplatform build is being adopted by more and more ARM platforms, > > > initcall function should be used very carefully. For example, when > > > GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() > > > will be called on all the platforms to initialize cpufreq-cpu0 driver. > > > > > > To eliminate this undesired the effect, the patch changes cpufreq-cpu0 > > > driver to have it instantiated as a platform_driver. Then it will only > > > run on platforms that create the platform_device "cpufreq-cpu0". > > > > > > Along with the change, it also changes cpu_dev to be &pdev->dev, > > > so that managed functions can start working, and module build gets > > > supported too. > > > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > > --- > > > Rafael, > > > > > > The patch depends patch "power: export opp cpufreq functions". > > > https://patchwork.kernel.org/patch/1847261/ > > > > That one should use EXPORT_SYMBOL_GPL() for exporting symbols, though. > > > When commit 80126ce (PM / OPP: Export symbols for module usage.) > already exported a few symbols with EXPORT_SYMBOL()? Yes, even then. All symbols in new patches that I apply have to be exported with _GPL. Thanks, Rafael
On 16:32-20130128, Shawn Guo wrote: > On Sat, Jan 26, 2013 at 11:21:27PM +0100, Rafael J. Wysocki wrote: > > On Saturday, January 26, 2013 09:55:50 PM Shawn Guo wrote: > > > As multiplatform build is being adopted by more and more ARM platforms, > > > initcall function should be used very carefully. For example, when > > > GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() > > > will be called on all the platforms to initialize cpufreq-cpu0 driver. > > > > > > To eliminate this undesired the effect, the patch changes cpufreq-cpu0 > > > driver to have it instantiated as a platform_driver. Then it will only > > > run on platforms that create the platform_device "cpufreq-cpu0". > > > > > > Along with the change, it also changes cpu_dev to be &pdev->dev, > > > so that managed functions can start working, and module build gets > > > supported too. > > > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > > --- > > > Rafael, > > > > > > The patch depends patch "power: export opp cpufreq functions". > > > https://patchwork.kernel.org/patch/1847261/ > > > > That one should use EXPORT_SYMBOL_GPL() for exporting symbols, though. > > > When commit 80126ce (PM / OPP: Export symbols for module usage.) > already exported a few symbols with EXPORT_SYMBOL()? I have split this out as a separate OPP series with a variant of https://patchwork.kernel.org/patch/1847261/ added at last. Will post this out in a few mins.
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index ea512f4..774dc1c 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -180,7 +180,7 @@ config CPU_FREQ_GOV_CONSERVATIVE If in doubt, say N. config GENERIC_CPUFREQ_CPU0 - bool "Generic CPU0 cpufreq driver" + tristate "Generic CPU0 cpufreq driver" depends on HAVE_CLK && REGULATOR && PM_OPP && OF select CPU_FREQ_TABLE help diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index debc5a7..dae0667 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -12,12 +12,12 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <linux/clk.h> -#include <linux/cpu.h> #include <linux/cpufreq.h> #include <linux/err.h> #include <linux/module.h> #include <linux/of.h> #include <linux/opp.h> +#include <linux/platform_device.h> #include <linux/regulator/consumer.h> #include <linux/slab.h> @@ -177,7 +177,7 @@ static struct cpufreq_driver cpu0_cpufreq_driver = { .attr = cpu0_cpufreq_attr, }; -static int cpu0_cpufreq_driver_init(void) +static int cpu0_cpufreq_probe(struct platform_device *pdev) { struct device_node *np; int ret; @@ -188,23 +188,17 @@ static int cpu0_cpufreq_driver_init(void) return -ENOENT; } - cpu_dev = get_cpu_device(0); - if (!cpu_dev) { - pr_err("failed to get cpu0 device\n"); - ret = -ENODEV; - goto out_put_node; - } - + cpu_dev = &pdev->dev; cpu_dev->of_node = np; - cpu_clk = clk_get(cpu_dev, NULL); + cpu_clk = devm_clk_get(cpu_dev, NULL); if (IS_ERR(cpu_clk)) { ret = PTR_ERR(cpu_clk); pr_err("failed to get cpu0 clock: %d\n", ret); goto out_put_node; } - cpu_reg = regulator_get(cpu_dev, "cpu0"); + cpu_reg = devm_regulator_get(cpu_dev, "cpu0"); if (IS_ERR(cpu_reg)) { pr_warn("failed to get cpu0 regulator\n"); cpu_reg = NULL; @@ -267,7 +261,24 @@ out_put_node: of_node_put(np); return ret; } -late_initcall(cpu0_cpufreq_driver_init); + +static int cpu0_cpufreq_remove(struct platform_device *pdev) +{ + cpufreq_unregister_driver(&cpu0_cpufreq_driver); + opp_free_cpufreq_table(cpu_dev, &freq_table); + + return 0; +} + +static struct platform_driver cpu0_cpufreq_platdrv = { + .driver = { + .name = "cpufreq-cpu0", + .owner = THIS_MODULE, + }, + .probe = cpu0_cpufreq_probe, + .remove = cpu0_cpufreq_remove, +}; +module_platform_driver(cpu0_cpufreq_platdrv); MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>"); MODULE_DESCRIPTION("Generic CPU0 cpufreq driver");
As multiplatform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() will be called on all the platforms to initialize cpufreq-cpu0 driver. To eliminate this undesired the effect, the patch changes cpufreq-cpu0 driver to have it instantiated as a platform_driver. Then it will only run on platforms that create the platform_device "cpufreq-cpu0". Along with the change, it also changes cpu_dev to be &pdev->dev, so that managed functions can start working, and module build gets supported too. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> --- Rafael, The patch depends patch "power: export opp cpufreq functions". https://patchwork.kernel.org/patch/1847261/ AnilKumar, Unfortunately, the change will require some platform level adoption to have cpufreq-cpu0 driver continue working for am33xx. But it should be as simple as something like below. struct platform_device_info devinfo = { .name = "cpufreq-cpu0", }; platform_device_register_full(&devinfo); Shawn drivers/cpufreq/Kconfig | 2 +- drivers/cpufreq/cpufreq-cpu0.c | 35 +++++++++++++++++++++++------------ 2 files changed, 24 insertions(+), 13 deletions(-)