[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[Shawn Guo]

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(-)

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

[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[Rafael J. Wysocki]

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");
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[Viresh Kumar]

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

[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[Shawn Guo]

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

[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[Viresh Kumar]

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?

[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[Shawn Guo]

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

[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[Rafael J. Wysocki]

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


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver

[Nishanth Menon]

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.

-- 
Regards,
Nishanth Menon