On 04-02-16, 00:22, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > > If the ondemand and conservative governors cannot use per-policy > tunables (CPUFREQ_HAVE_GOVERNOR_PER_POLICY is not set in the cpufreq > driver), all policy objects point to the same single dbs_data object. > Additionally, that object is pointed to by a global pointer hidden in > the governor's data structures. > > There is no reason for that pointer to be buried in those > data structures, though, so make it explicitly global. > > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c > =================================================================== > --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c > +++ linux-pm/drivers/cpufreq/cpufreq_governor.c > @@ -22,6 +22,9 @@ > > #include "cpufreq_governor.h" > > +struct dbs_data *global_dbs_data; > +EXPORT_SYMBOL_GPL(global_dbs_data); Oh man, please save me from Rafael's Rant :) I think, this is simply wrong. Believe me its very difficult for me to say this to you :). You are way better than me, and I am sure that I haven't understood cupfreq after so many years :) Consider a two policy system, who is stopping us from setting ondemand for one of them and conservative for the other one ? And so, we will have two gdbs_data .. Sorry for the noise, if I am being utterly stupid :( -- viresh
