lkml.org 
[lkml]   [2016]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer
    On 04-02-16, 00:22, Rafael J. Wysocki wrote:
    > From: Rafael J. Wysocki <rafael.j.wysocki@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.wysocki@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

    \
     
     \ /
      Last update: 2016-02-04 06:41    [W:2.562 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site