| Message ID | 1363715590-5131-9-git-send-email-nm@ti.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 --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))
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(+)