diff mbox

[V2,8/8] cpufreq: OMAP: donot allow to be used with device tree

Message ID 1363715590-5131-9-git-send-email-nm@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Nishanth Menon March 19, 2013, 5:53 p.m. UTC
We now use Soc generic cpufreq-cpu0 driver using DT entries.
However to allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist,
we need to ensure the following using the same image:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the DT, to ensure that omap-cpufreq and cpufreq-cpu0 don't
conflict in managing the frequency of the same cpu, we should not
permit init to pass in omap-cpufreq.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

So, to acommodate both these usage conditions, we fail init of
omap-cpufreq when we boot with device tree.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in V2:
	- donot remove support for omap-cpufreq in non-DT boot
	- little more verbose commit log
V1: https://patchwork.kernel.org/patch/2273641/

 drivers/cpufreq/omap-cpufreq.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

Comments

Santosh Shilimkar March 20, 2013, 6:17 a.m. UTC | #1
On Tuesday 19 March 2013 11:23 PM, Nishanth Menon wrote:
> We now use Soc generic cpufreq-cpu0 driver using DT entries.
> However to allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist,
> we need to ensure the following using the same image:
> 1. With device tree boot, we use cpufreq-cpu0
> 2. With non device tree boot, we use omap-cpufreq
> 
> In the case of (1), we will have cpu OPPs and regulator registered
> as part of the DT, to ensure that omap-cpufreq and cpufreq-cpu0 don't
> conflict in managing the frequency of the same cpu, we should not
> permit init to pass in omap-cpufreq.
> 
> In the case of (2), we will not have the cpufreq-cpu0 device, hence
> only omap-cpufreq will be active.
> 
> So, to acommodate both these usage conditions, we fail init of
> omap-cpufreq when we boot with device tree.
> 
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Cc: "Benoît Cousson" <b-cousson@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Keerthy <j-keerthy@ti.com>
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: cpufreq@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
> 
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
I haven't followed all the DT binding for opp discussion but
this patch is inline to keep non-DT cpufreq working till we
move to DT only build.
So FWIW,
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Kevin Hilman March 27, 2013, 6:39 p.m. UTC | #2
Nishanth Menon <nm@ti.com> writes:

> We now use Soc generic cpufreq-cpu0 driver using DT entries.
> However to allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist,
> we need to ensure the following using the same image:
> 1. With device tree boot, we use cpufreq-cpu0
> 2. With non device tree boot, we use omap-cpufreq
>
> In the case of (1), we will have cpu OPPs and regulator registered
> as part of the DT, to ensure that omap-cpufreq and cpufreq-cpu0 don't
> conflict in managing the frequency of the same cpu, we should not
> permit init to pass in omap-cpufreq.
>
> In the case of (2), we will not have the cpufreq-cpu0 device, hence
> only omap-cpufreq will be active.
>
> So, to acommodate both these usage conditions, we fail init of
> omap-cpufreq when we boot with device tree.
>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Cc: "Benoît Cousson" <b-cousson@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Keerthy <j-keerthy@ti.com>
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: cpufreq@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Changes in V2:
> 	- donot remove support for omap-cpufreq in non-DT boot
> 	- little more verbose commit log
> V1: https://patchwork.kernel.org/patch/2273641/
>
>  drivers/cpufreq/omap-cpufreq.c |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
> index 9128c07..9382ed0 100644
> --- a/drivers/cpufreq/omap-cpufreq.c
> +++ b/drivers/cpufreq/omap-cpufreq.c
> @@ -22,6 +22,7 @@
>  #include <linux/err.h>
>  #include <linux/clk.h>
>  #include <linux/io.h>
> +#include <linux/of.h>
>  #include <linux/opp.h>
>  #include <linux/cpu.h>
>  #include <linux/module.h>
> @@ -174,6 +175,19 @@ static inline void freq_table_free(void)
>  static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
>  {
>  	int result = 0;
> +	struct device_node *np;
> +
> +	/*
> +	 * If we have a device tree node describing OPPs,
> +	 * we will NOT permit usage of omap-cpufreq driver.
> +	 * use cpufreq-cpu0 driver to manage.
> +	 */
> +	if (of_have_populated_dt()) {
> +		for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
> +			if (of_get_property(np, "operating-points", NULL))
> +				return -EPERM;
> +		}
> +	}

I think it's much cleaner to just convert this to a platform_driver like
was done for the generic driver[1].  Then the registration in the
previous patch can register the omap driver when needed.

Kevin

[1] https://patchwork.kernel.org/patch/2067751/
Nishanth Menon March 27, 2013, 8:59 p.m. UTC | #3
On 11:39-20130327, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
> >  #include <linux/module.h>
> > @@ -174,6 +175,19 @@ static inline void freq_table_free(void)
> >  static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
> >  {
> >  	int result = 0;
> > +	struct device_node *np;
> > +
> > +	/*
> > +	 * If we have a device tree node describing OPPs,
> > +	 * we will NOT permit usage of omap-cpufreq driver.
> > +	 * use cpufreq-cpu0 driver to manage.
> > +	 */
> > +	if (of_have_populated_dt()) {
> > +		for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
> > +			if (of_get_property(np, "operating-points", NULL))
> > +				return -EPERM;
> > +		}
> > +	}
> 
> I think it's much cleaner to just convert this to a platform_driver like
> was done for the generic driver[1].  Then the registration in the
> previous patch can register the omap driver when needed.
Thanks for the review.
Yes. I agree. Will wait for any further comments on the DT angle before
I send out an V3.
diff mbox

Patch

diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..9382ed0 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -22,6 +22,7 @@ 
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/opp.h>
 #include <linux/cpu.h>
 #include <linux/module.h>
@@ -174,6 +175,19 @@  static inline void freq_table_free(void)
 static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
 {
 	int result = 0;
+	struct device_node *np;
+
+	/*
+	 * If we have a device tree node describing OPPs,
+	 * we will NOT permit usage of omap-cpufreq driver.
+	 * use cpufreq-cpu0 driver to manage.
+	 */
+	if (of_have_populated_dt()) {
+		for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
+			if (of_get_property(np, "operating-points", NULL))
+				return -EPERM;
+		}
+	}
 
 	mpu_clk = clk_get(NULL, "cpufreq_ck");
 	if (IS_ERR(mpu_clk))