Re: [PATCH 07/14] cpufreq: cpu0: OPPs can be populated at runtime

Re: [PATCH 07/14] cpufreq: cpu0: OPPs can be populated at runtime

[Nishanth Menon]

On Thu, Jul 10, 2014 at 6:19 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 9 July 2014 20:14, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>> Assuming you are updating bidnings as suggested by Stephen,
>> patch looks good to me.
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Why do you still have a separate cpufreq driver for omap?
> Would this patch help getting that out?
>
> I see this for omap:
>
> static inline void omap_init_cpufreq(void)
> {
>         struct platform_device_info devinfo = { };
>
>         if (!of_have_populated_dt())
>                 devinfo.name = "omap-cpufreq";
>         else
>                 devinfo.name = "cpufreq-generic";
>         platform_device_register_full(&devinfo);
> }
>
> and it makes me believe that you were just waiting for this patch?

Sorry, am away on vacation and slow on emails. The plan was to kill
omap cpufreq once all platforms convert to device tree only boot. Only
platform left is OMAP3 based platforms - though the date for removing
non-dt support has changed a couple of kernel revisions - but we
should be able to remove that entire file with this change.

We will need this support to go with the solution recommended for opp
modifier series[1] - where platform code will populate or add OPPs
based on "speed grade" sample detection.

[1]http://comments.gmane.org/gmane.linux.ports.arm.kernel/309466

---
Regards,
Nishanth Menon

Re: [PATCH 07/14] cpufreq: cpu0: OPPs can be populated at runtime

[Santosh Shilimkar]

On Thursday 10 July 2014 08:39 AM, Nishanth Menon wrote:
> On Thu, Jul 10, 2014 at 6:19 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> On 9 July 2014 20:14, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>>> Assuming you are updating bidnings as suggested by Stephen,
>>> patch looks good to me.
>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>
>> Why do you still have a separate cpufreq driver for omap?
>> Would this patch help getting that out?
>>
>> I see this for omap:
>>
>> static inline void omap_init_cpufreq(void)
>> {
>>         struct platform_device_info devinfo = { };
>>
>>         if (!of_have_populated_dt())
>>                 devinfo.name = "omap-cpufreq";
>>         else
>>                 devinfo.name = "cpufreq-generic";
>>         platform_device_register_full(&devinfo);
>> }
>>
>> and it makes me believe that you were just waiting for this patch?
> 
> Sorry, am away on vacation and slow on emails. The plan was to kill
> omap cpufreq once all platforms convert to device tree only boot. Only
> platform left is OMAP3 based platforms - though the date for removing
> non-dt support has changed a couple of kernel revisions - but we
> should be able to remove that entire file with this change.
> 
> We will need this support to go with the solution recommended for opp
> modifier series[1] - where platform code will populate or add OPPs
> based on "speed grade" sample detection.
>
Yep. Last time I blocked the series because all the DT conversions
were not done. Considering now the cpufreq-generic can work on non
DT platforms, I am ok to remove the omap-cpufreq.

Regards,
Santosh

 

Re: [PATCH 07/14] cpufreq: cpu0: OPPs can be populated at runtime

[Viresh Kumar]

On 10 July 2014 19:01, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> Yep. Last time I blocked the series because all the DT conversions
> were not done. Considering now the cpufreq-generic can work on non
> DT platforms, I am ok to remove the omap-cpufreq.

Great.