Re: [pm-wip/cpufreq][PATCH 3/3] OMAP2+: cpufreq: do lateinit

[Kevin Hilman <khilman@ti.com>]

"Menon, Nishanth" <nm@ti.com> writes:

> On Wed, Jun 8, 2011 at 13:51, Kevin Hilman <khilman@ti.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html