Hello Viresh, On Thu, Feb 04, 2016 at 01:55:38PM +0530, Viresh Kumar wrote: > On 04-02-16, 13:44, Gautham R Shenoy wrote: > > In a a two policy system, to run ondemand on one and conservative on the > > other, > > won't the driver have CPUFREQ_HAVE_GOVERNOR_PER_POLICY set? > > No. > > CPUFREQ_HAVE_GOVERNOR_PER_POLICY is not about the facility of using > separate governor-type for each policy, that is always available to > the user. > > CPUFREQ_HAVE_GOVERNOR_PER_POLICY was initially added for platforms > with different type of CPUs on the same chip, though others can > benefit from it as well. > > For example, on a 4 core ARM big LITTLE platform, we will have: > - 2 A7 (low performance/low power) > - 2 A15 (high performance/high power) > > The A7's share a policy and A15's share another one. > > Without CPUFREQ_HAVE_GOVERNOR_PER_POLICY, if ondemand is selected for > both the policies, the we used to get a single directory (and a set of > tunables) at /sys/devices/system/cpu/cpufreq/ondemand/ . > > That used to force us to use same tunables, like sampling rate, etc > for both the policies. > > But because the CPUs were so different, we really wanted independent > control. > > So, we designed CPUFREQ_HAVE_GOVERNOR_PER_POLICY, so that in such > cases, each policy will have a set of tunables for the same governor > type. > > Hope that makes it clear.
Yes it does! Thank you for the explanation. So, the CPUFREQ_HAVE_GOVERNOR_PER_POLICY is really CPUFREQ_HAVE_GOVERNOR_TUNERS_PER_POLICY. Can we change the name to reflect the intent? > > If the below questionnaire is still valid, please let me know :) No, it is no longer valid! > > viresh -- Thanks and Regards gautham.
