| Message ID | 1307412330-25798-4-git-send-email-nm@ti.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Kevin Hilman |
| Headers | show |
On 6/7/2011 7:35 AM, Nishanth Menon wrote: > Since we do module_init, cpufreq initializes before power late_init > where many of the required data structures are registered. Move > cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ > on which the build depends is bool and does'nt support modules yet. > You might want to fix sequence instead of this change considering we want to make OMAP CPUFReq as a loadable module. > Signed-off-by: Nishanth Menon<nm@ti.com> > --- > arch/arm/mach-omap2/omap2plus-cpufreq.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c > index 2177381..07c2ab9 100644 > --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c > +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c > @@ -273,5 +273,5 @@ static void __exit omap_cpufreq_exit(void) > > MODULE_DESCRIPTION("cpufreq driver for OMAP2PLUS SOCs"); > MODULE_LICENSE("GPL"); > -module_init(omap_cpufreq_init); > +late_initcall(omap_cpufreq_init); > module_exit(omap_cpufreq_exit); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 7, 2011 at 03:15, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: > On 6/7/2011 7:35 AM, Nishanth Menon wrote: >> >> Since we do module_init, cpufreq initializes before power late_init >> where many of the required data structures are registered. Move >> cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ >> on which the build depends is bool and does'nt support modules yet. >> > You might want to fix sequence instead of this change > considering we want to make OMAP CPUFReq as a loadable module. Unless I add a is_omap_pm_ready() in omap_target() - it is not really safe. but smartreflex.c has a similar issue as well - I am open to suggestions on how we should fix this in a clean manner. Current omap2-cpufreq.c does not do dvfs - so it has dependency only on clocks - but the moment it depends on anything PM code does,we'd be dead as, for instance, dvfs requires a lot of those pieces to fall in place before we can execute omap_target. Regards, Nishanth Menon > > >> Signed-off-by: Nishanth Menon<nm@ti.com> >> --- >> arch/arm/mach-omap2/omap2plus-cpufreq.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c >> b/arch/arm/mach-omap2/omap2plus-cpufreq.c >> index 2177381..07c2ab9 100644 >> --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c >> +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c >> @@ -273,5 +273,5 @@ static void __exit omap_cpufreq_exit(void) >> >> MODULE_DESCRIPTION("cpufreq driver for OMAP2PLUS SOCs"); >> MODULE_LICENSE("GPL"); >> -module_init(omap_cpufreq_init); >> +late_initcall(omap_cpufreq_init); >> module_exit(omap_cpufreq_exit); > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: > Since we do module_init, cpufreq initializes before power late_init > where many of the required data structures are registered. What exactly are the dependencies here? The only thing I see is the dependency on omap2_get_mpuss_device(), and those devices should be created as a postcore_initcall. If there are other dependencies, they're probably created a side effect of your earlier patches where you moved stuff from the ->init hook (which happens much later) into the initcall function. Maybe that needs a rethink? > Move cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ on > which the build depends is bool and does'nt support modules yet. > > Signed-off-by: Nishanth Menon <nm@ti.com> If this works, it's only because of the link order defined by the Makefile ordering since both are the same level of initcall. When I move this driver to drivers/cpufreq, then the link order is less obvious. Kevin > --- > arch/arm/mach-omap2/omap2plus-cpufreq.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c > index 2177381..07c2ab9 100644 > --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c > +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c > @@ -273,5 +273,5 @@ static void __exit omap_cpufreq_exit(void) > > MODULE_DESCRIPTION("cpufreq driver for OMAP2PLUS SOCs"); > MODULE_LICENSE("GPL"); > -module_init(omap_cpufreq_init); > +late_initcall(omap_cpufreq_init); > module_exit(omap_cpufreq_exit); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 7, 2011 at 16:49, Kevin Hilman <khilman@ti.com> wrote: > Nishanth Menon <nm@ti.com> writes: > >> Since we do module_init, cpufreq initializes before power late_init >> where many of the required data structures are registered. > > What exactly are the dependencies here? The only thing I see is the > dependency on omap2_get_mpuss_device(), and those devices should be > created as a postcore_initcall. > > If there are other dependencies, they're probably created a side effect > of your earlier patches where you moved stuff from the ->init hook > (which happens much later) into the initcall function. Maybe that needs > a rethink? > >> Move cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ on >> which the build depends is bool and does'nt support modules yet. >> >> Signed-off-by: Nishanth Menon <nm@ti.com> > > If this works, it's only because of the link order defined by the > Makefile ordering since both are the same level of initcall. > > When I move this driver to drivers/cpufreq, then the link order is less > obvious. the issue is as follows: currently we dont do voltage transitions. when we do that eventually(and my current code has an forked implementation of dvfs, the following steps happen): late_initcall(omap2_common_pm_late_init); does pmic inits, omap_voltage_late_init, init_voltages and SR dev initialization without these, there is no way to transition MPU to proper voltage, frequency combination. The requirement will have to be that omap2-cpufreq.c allows for cpufreq transitions only after voltage and clk layers are ready for transitions - if we ever want to do dvfs - which we will eventually need to. Regards, Nishanth Menon > > Kevin > >> --- >> arch/arm/mach-omap2/omap2plus-cpufreq.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c >> index 2177381..07c2ab9 100644 >> --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c >> +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c >> @@ -273,5 +273,5 @@ static void __exit omap_cpufreq_exit(void) >> >> MODULE_DESCRIPTION("cpufreq driver for OMAP2PLUS SOCs"); >> MODULE_LICENSE("GPL"); >> -module_init(omap_cpufreq_init); >> +late_initcall(omap_cpufreq_init); >> module_exit(omap_cpufreq_exit); > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"Menon, Nishanth" <nm@ti.com> writes: > On Tue, Jun 7, 2011 at 16:49, Kevin Hilman <khilman@ti.com> wrote: >> Nishanth Menon <nm@ti.com> writes: >> >>> Since we do module_init, cpufreq initializes before power late_init >>> where many of the required data structures are registered. >> >> What exactly are the dependencies here? The only thing I see is the >> dependency on omap2_get_mpuss_device(), and those devices should be >> created as a postcore_initcall. >> >> If there are other dependencies, they're probably created a side effect >> of your earlier patches where you moved stuff from the ->init hook >> (which happens much later) into the initcall function. Maybe that needs >> a rethink? >> >>> Move cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ on >>> which the build depends is bool and does'nt support modules yet. >>> >>> Signed-off-by: Nishanth Menon <nm@ti.com> >> >> If this works, it's only because of the link order defined by the >> Makefile ordering since both are the same level of initcall. >> >> When I move this driver to drivers/cpufreq, then the link order is less >> obvious. > > the issue is as follows: > currently we dont do voltage transitions. when we do that > eventually(and my current code has an forked implementation of dvfs, > the following steps happen): > late_initcall(omap2_common_pm_late_init); > does pmic inits, omap_voltage_late_init, init_voltages and SR dev initialization > > without these, there is no way to transition MPU to proper voltage, > frequency combination. The requirement will have to be that > omap2-cpufreq.c allows for cpufreq transitions only after voltage and > clk layers are ready for transitions - if we ever want to do dvfs - > which we will eventually need to. Yes, I understand. But $SUBJECT patch is fixing this as an _init_ time ordering problem, What you're describing is a runtime requirement that doesn't exist until a DVFS transition is done. IOW, the requirement is that the voltage etc. layers have to be init'd before the first transition. So, rather than fix this with initcall ordering (which will have to be redone as things git moved and converted to modules), just create a type of late init function in this driver, which gets called on the first transition. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c index 2177381..07c2ab9 100644 --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c @@ -273,5 +273,5 @@ static void __exit omap_cpufreq_exit(void) MODULE_DESCRIPTION("cpufreq driver for OMAP2PLUS SOCs"); MODULE_LICENSE("GPL"); -module_init(omap_cpufreq_init); +late_initcall(omap_cpufreq_init); module_exit(omap_cpufreq_exit);
Since we do module_init, cpufreq initializes before power late_init where many of the required data structures are registered. Move cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ on which the build depends is bool and does'nt support modules yet. Signed-off-by: Nishanth Menon <nm@ti.com> --- arch/arm/mach-omap2/omap2plus-cpufreq.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)