"Menon, Nishanth" <nm@xxxxxx> writes:
> On Wed, Jun 8, 2011 at 13:51, Kevin Hilman <khilman@xxxxxx> wrote:
> [..]
>>> 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.
>
> The tricky part ofcourse is for the registration - if we do the
> registration, omap_cpu_init will get called once the registration
> happens - no reason to stop it, which in turn triggers omap_target the
> moment the governors are ready to do their thing.
Yes.
> Is the following what you are talking about? I am not completely sure
> how this helps..
No. I was thinking of doing registration as it is today, but have a
late hook that is called in the driver's->target() callback that checks
if the other frameworks are ready.
But now I see now that ->target() is called right after ->init(), so I
don't think this helps. Sheesh. The PM init sequence/dependencies
right now are a complete mess.
Probably a better solution to this, would be to actually create a
platform driver out of our CPUfreq driver. Then, PM core late init
would just register the platform device when it's ready. This would
also work if/when the CPUfreq driver is a module.
Kevin
> diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
> b/arch/arm/mach-omap2/omap2plus-cpufreq.c
> index 77efcb0..8586df8 100644
> --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
> +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
> @@ -253,6 +253,11 @@ static struct cpufreq_driver omap_driver = {
> .attr = omap_cpufreq_attr,
> };
>
> +static int __init omap_cpufreq_lateinit(void)
> +{
> + return cpufreq_register_driver(&omap_driver);
> +}
> +
> static int __init omap_cpufreq_init(void)
> {
> if (cpu_is_omap24xx()) {
> @@ -277,8 +282,7 @@ static int __init omap_cpufreq_init(void)
> pr_warning("%s: unable to get the mpu device\n", __func__);
> return -EINVAL;
> }
> -
> - return cpufreq_register_driver(&omap_driver);
> + return 0;
> }
>
> static void __exit omap_cpufreq_exit(void)
> @@ -288,5 +292,6 @@ static void __exit omap_cpufreq_exit(void)
>
> MODULE_DESCRIPTION("cpufreq driver for OMAP2PLUS SOCs");
> MODULE_LICENSE("GPL");
> +late_initcall(omap_cpufreq_lateinit);
> module_init(omap_cpufreq_init);
> module_exit(omap_cpufreq_exit);
>
>
> Regards,
> Nishanth Menon
--
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
