"Menon, Nishanth" <nm@xxxxxx> writes: > On Tue, Jun 7, 2011 at 16:49, Kevin Hilman <khilman@xxxxxx> wrote: >> Nishanth Menon <nm@xxxxxx> 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@xxxxxx> >> >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
