Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer

[Gautham R Shenoy <ego@linux.vnet.ibm.com>]

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.