[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <510B6FC5.8030309@ti.com>
Date: Fri, 1 Feb 2013 13:03:25 +0530
From: Santosh Shilimkar <santosh.shilimkar@...com>
To: Viresh Kumar <viresh.kumar@...aro.org>
CC: <rjw@...k.pl>, <cpufreq@...r.kernel.org>,
<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linaro-dev@...ts.linaro.org>, <robin.randhawa@....com>,
<Steve.Bannister@....com>, <Liviu.Dudau@....com>,
Linus Walleij <linus.walleij@...aro.org>,
Stephen Warren <swarren@...dia.com>,
Shawn Guo <shawn.guo@...aro.org>
Subject: Re: [PATCH 3/3] cpufreq: Remove unnecessary use of policy->shared_type
On Friday 01 February 2013 12:43 PM, Viresh Kumar wrote:
> On 1 February 2013 12:17, Santosh Shilimkar <santosh.shilimkar@...com> wrote:
>> I haven't looked at the cpufreq code recently but remember
>> that it was needed to ensure that all the CPU which
>> share clock/voltage gets updated (affected cpus) on
>> freq change. The CPUs which needs SW co-ordination, should
>> have this flag enabled and OMAP was falling in that category.
>
> Freq change are done by the target routines of platform cpufreq drivers
> and they do something like:
>
> for_each_cpu(freqs.cpu, policy->cpus)
> cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
>
> The only requirement from cpufreq core is to keep cpus sharing clock
> in policy->cpus.
>
I am not talking about just notifiers. This is for external users who
has subscribed for notifiers. The point is whether the core CPUFReq
gets updated without that flag for all affected CPU.
>> May be I miss-understood its use, but can you confirm that
>> SW co-ordination logic continues to work without this flag ?
>
> I believe it should work. It works for the systems i worked on:
>
> SPEAr13xx: Dual Cortex A9
> ARM TC2: two clusters of A15s and A7s.
>
I will give a try some time next week on OMAP.
Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists