linux cpufreq framework(3)

1. 前言

前文（Linux cpufreq framework(2)_cpufreq driver）从平台驱动工程师的角度，简单的介绍了编写一个cpufreq driver的大概步骤。但要更深入理解、更灵活的使用，必须理解其内部的实现逻辑。

因此，本文将从cpufreq framework core的角度，对cpufreq framework的内部实现做一个简单的分析。

2. 提供给用户空间的接口

cpufreq core的内部实现，比较繁杂，因此我们需要一个分析的突破口，而cpufreq framework提供的API是一个不错的选择。因为API抽象了cpufreq的功能，而所有的cpufreq core、cpufreq driver等模块，都是为这些功能服务的。

由“linux cpufreq framework(1)_概述”的介绍可知，cpufreq framework通过sysfs向用户空间提供接口，具体如下：

/sys/devices/system/cpu/cpu0/cpufreq/
|-- affected_cpus
|-- cpuinfo_cur_freq
|-- cpuinfo_max_freq
|-- cpuinfo_min_freq
|-- cpuinfo_transition_latency
|-- related_cpus
|-- scaling_available_frequencies
|-- scaling_available_governors
|-- scaling_cur_freq
|-- scaling_driver
|-- scaling_governor
|-- scaling_max_freq
|-- scaling_min_freq
|-- scaling_setspeed
`—stats
    |-- time_in_state
    |-- total_trans
    `-- trans_table

1）“cpufreq”目录

在kernel的模型中，cpufreq被抽象为cpu device的一个interface，因此它位于对应的cpu目录（/sys/devices/system/cpu/cpuX）下面。

有些平台，所有cpu core的频率和电压时统一控制的，即改变某个core上的频率，其它core同样受影响。此时只需要实现其中一个core（通常为cpu0）的cpufreq即可，其它core的cpufreq直接是cpu0的符号链接。因此，使用这些API时，随便进入某一个cpu下面的cpufreq目录即可。

而另一些些平台，不同core可以单独控制，这时不同cpu目录下的cpufreq就不一样了。

到底某一个cpufreq可以控制多少cpu core呢？可以通过cpufreq/affected_cpus和cpufreq/related_cpus两个文件查看，其中的区别是：affected_cpus表示该cpufreq影响到哪些cpu core（没有显示处于offline状态的cpu），related_cpus则包括了online+offline的所有core。

2）cpuinfo相关的信息

由“Linux cpufreq framework(2)_cpufreq driver”的描述可知，cpufreq driver初始化时，会根据frequency table等信息，填充struct cpufreq_policy变量中的struct cpufreq_cpuinfo变量，该变量保存了CPU调频有关的固定信息（不可以在运行过程中修改，主要包括：最大频率（cpuinfo_max_freq）、最小频率（cpuinfo_min_freq）、频率转换延迟（cpuinfo_transition_latency ）。

另外，通过cpuinfo_cur_freq ，可以获取cpu core的当前频率（真实的、cpu的当前运行频率，会通过cpufreq_driver->get回调读取）。

当前，这四个“cpuinfo_”开头的sysfs API，都是只读的。

3）scaling_available_frequencies，获取当前可以配置的频率列表，从frequency table直接读取。readonly。

4） scaling_driver，当前加载的cpufreq driver名称，readonly。

5）scaling_available_governors和scaling_governor，系统中可用的governor列表，以及当前使用的governor。governor相关的内容会在后续详细描述。readonly。

6）scaling_cur_freq，从cpufreq core或者governor的角度，看到的当前频率，和cpuinfo_cur_freq的意义不相同，后面的分析中根据实例在描述。readonly。

7）scaling_max_freq、scaling_min_freq和scaling_setspeed

scaling_max_freq和scaling_min_freq表示调频策略所允许的最大和最小频率，对于可以自动调整频率的cpu，修改它们，就是最终的频率调整。

对不能自动调整频率的cpu，则需要通过其它方式，主动的设置cpu频率，这些都是由具体的governor完成。其中有一个特例：

如果使用的governor是“userspace” governor，则可以通过scaling_setspeed节点，直接修改cpu频率。

3. 频率调整的步骤

开始分析之前，我们先以“userspace” governor为例，介绍一下频率调整的步骤。“userspace”governor是所有governor中最简单的一个，同时又是驱动工程师比较常用的一个，借助它，可以从用户空间修改cpu的频率，操作方法如下（为了简单，以shell脚本的形式给出）：

cd /sys/devices/system/cpu/cpu0/cpufreq/

cat cpuinfo_max_freq; cat cpuinfo_min_freq            #获取“物理”上的频率范围

cat scaling_available_frequencies                          #获取可用的频率列表
cat scaling_available_governors                             #获取可用的governors
cat scaling_governor                                             #当前的governor
cat cpuinfo_cur_freq; cat scaling_cur_freq              #获取当前的频率信息，可以比较一下是否不同

cat scaling_max_freq; cat scaling_min_freq           #获取当前调频策略所限定的频率范围

#假设CPU不可以自动调整频率
echo userspace > scaling_governor                      #governor切换为userspace

#如果需要切换的频率值在scaling_available_frequencies内，且在cpuinfo_max_freq/cpuinfo_min_freq的范围内。

#如果需要切换的频率不在scaling_max_freq/scaling_min_freq的范围内，修改这两个值
echo xxx > scaling_max_freq; echo xxx > scaling_min_freq

#最后，设置频率值
echo xxx > scaling_setspeed

4. 内部逻辑分析

4.1 初始化

基于linux设备模型的思想，kernel会使用device和driver两个实体，抽象设备及其驱动，当这两个实体同时存在时，则执行driver的初始化接口（即driver开始运行）。cpufreq也不例外，基本遵循了上面的思路。但由于cpufreq是一类比较特殊的设备（它只是cpu device的一个功能，本身并不以任何形式存在），在实现上，就有点迂回。

首先，driver的抽象比较容易理解，就是我们在“Linux cpufreq framework(2)_cpufreq driver”中描述的struct cpufreq_driver结构。那device呢？先看看下面的图片：

注1：该图片不包括CPU hotplug的情况，hotplug时，会走两外一个流程，大概原理类似，本文就不详细介绍这种情况了。

1）cpufreq_interface

前面讲过，cpufreq driver注册时，会调用subsys_interface_register接口，注册一个subsystem interface，该interface的定义如下：

  1: /* drivers/cpufreq/cpufreq.c */

  2: static struct subsys_interface cpufreq_interface = {

  3:     .name       = "cpufreq",

  4:     .subsys     = &cpu_subsys,

  5:     .add_dev    = cpufreq_add_dev,

  6:     .remove_dev = cpufreq_remove_dev,

  7: };

该interface的subsys是“cpu_subsys”，就是cpu bus（struct bus_type cpu_subsys），提供了add_dev和remove_dev两个回调函数。

由“Linux设备模型(6)_Bus”中的描述可知，当bus下有设备probe的时候（此处为cpu device的probe），会调用其下所有interface的add_dev回调函数。物理意义是什么呢？

cpufreq是cpu device的一个功能，当cpu device开始枚举时，当然要创建代表该功能（cpufreq）的设备。而这个设备的具体形态，只有该功能相关的代码（cpufreq core）知道，因此就只能交给它了。

2）__cpufreq_add_dev

由上面图片所示的流程可知，cpufreq设备的添加，最终是由__cpufreq_add_dev接口完成的，该接口的主要功能，是创建一个代表该cpufreq的设备（struct cpufreq_policy类型的变量），并以它为参数，调用cpufreq_driver的init接口（可参考“Linux cpufreq framework(2)_cpufreq driver”），对它进行初始化。如下：

  1: static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)

  2: {

  3:     unsigned int j, cpu = dev->id;

  4:     int ret = -ENOMEM;

  5:     struct cpufreq_policy *policy;

  6:     unsigned long flags;

  7:     bool recover_policy = cpufreq_suspended;

  8: #ifdef CONFIG_HOTPLUG_CPU

  9:     struct cpufreq_policy *tpolicy;

 10: #endif

11:

 12:     if (cpu_is_offline(cpu))

 13:         return 0;

14:

 15:     pr_debug("adding CPU %u\n", cpu);

16:

 17: #ifdef CONFIG_SMP

 18:     /* check whether a different CPU already registered this

 19:      * CPU because it is in the same boat. */

 20:     policy = cpufreq_cpu_get(cpu);

 21:     if (unlikely(policy)) {

 22:         cpufreq_cpu_put(policy);

 23:         return 0;

 24:     }

 25: #endif

26:

 27:     if (!down_read_trylock(&cpufreq_rwsem))

 28:         return 0;

29:

 30: #ifdef CONFIG_HOTPLUG_CPU

 31:     /* Check if this cpu was hot-unplugged earlier and has siblings */

 32:     read_lock_irqsave(&cpufreq_driver_lock, flags);

 33:     list_for_each_entry(tpolicy, &cpufreq_policy_list, policy_list) {

 34:         if (cpumask_test_cpu(cpu, tpolicy->related_cpus)) {

 35:             read_unlock_irqrestore(&cpufreq_driver_lock, flags);

 36:             ret = cpufreq_add_policy_cpu(tpolicy, cpu, dev);

 37:             up_read(&cpufreq_rwsem);

 38:             return ret;

 39:         }

 40:     }

 41:     read_unlock_irqrestore(&cpufreq_driver_lock, flags);

 42: #endif

43:

 44:     /*

 45:      * Restore the saved policy when doing light-weight init and fall back

 46:      * to the full init if that fails.

 47:      */

 48:     policy = recover_policy ? cpufreq_policy_restore(cpu) : NULL;

 49:     if (!policy) {

 50:         recover_policy = false;

 51:         policy = cpufreq_policy_alloc();

 52:         if (!policy)

 53:             goto nomem_out;

 54:     }

55:

 56:     /*

 57:      * In the resume path, since we restore a saved policy, the assignment

 58:      * to policy->cpu is like an update of the existing policy, rather than

 59:      * the creation of a brand new one. So we need to perform this update

 60:      * by invoking update_policy_cpu().

 61:      */

 62:     if (recover_policy && cpu != policy->cpu)

 63:         WARN_ON(update_policy_cpu(policy, cpu, dev));

 64:     else

 65:         policy->cpu = cpu;

66:

 67:     cpumask_copy(policy->cpus, cpumask_of(cpu));

68:

 69:     init_completion(&policy->kobj_unregister);

 70:     INIT_WORK(&policy->update, handle_update);

71:

 72:     /* call driver. From then on the cpufreq must be able

 73:      * to accept all calls to ->verify and ->setpolicy for this CPU

 74:      */

 75:     ret = cpufreq_driver->init(policy);

 76:     if (ret) {

 77:         pr_debug("initialization failed\n");

 78:         goto err_set_policy_cpu;

 79:     }

80:

 81:     /* related cpus should atleast have policy->cpus */

 82:     cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);

83:

 84:     /*

 85:      * affected cpus must always be the one, which are online. We aren't

 86:      * managing offline cpus here.

 87:      */

 88:     cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);

89:

 90:     if (!recover_policy) {

 91:         policy->user_policy.min = policy->min;

 92:         policy->user_policy.max = policy->max;

 93:     }

94:

 95:     down_write(&policy->rwsem);

 96:     write_lock_irqsave(&cpufreq_driver_lock, flags);

 97:     for_each_cpu(j, policy->cpus)

 98:         per_cpu(cpufreq_cpu_data, j) = policy;

 99:     write_unlock_irqrestore(&cpufreq_driver_lock, flags);

100:

101:     if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {

102:         policy->cur = cpufreq_driver->get(policy->cpu);

103:         if (!policy->cur) {

104:             pr_err("%s: ->get() failed\n", __func__);

105:             goto err_get_freq;

106:         }

107:     }

108:

109:     /*

110:      * Sometimes boot loaders set CPU frequency to a value outside of

111:      * frequency table present with cpufreq core. In such cases CPU might be

112:      * unstable if it has to run on that frequency for long duration of time

113:      * and so its better to set it to a frequency which is specified in

114:      * freq-table. This also makes cpufreq stats inconsistent as

115:      * cpufreq-stats would fail to register because current frequency of CPU

116:      * isn't found in freq-table.

117:      *

118:      * Because we don't want this change to effect boot process badly, we go

119:      * for the next freq which is >= policy->cur ('cur' must be set by now,

120:      * otherwise we will end up setting freq to lowest of the table as 'cur'

121:      * is initialized to zero).

122:      *

123:      * We are passing target-freq as "policy->cur - 1" otherwise

124:      * __cpufreq_driver_target() would simply fail, as policy->cur will be

125:      * equal to target-freq.

126:      */

127:     if ((cpufreq_driver->flags & CPUFREQ_NEED_INITIAL_FREQ_CHECK)

128:         && has_target()) {

129:         /* Are we running at unknown frequency ? */

130:         ret = cpufreq_frequency_table_get_index(policy, policy->cur);

131:         if (ret == -EINVAL) {

132:             /* Warn user and fix it */

133:             pr_warn("%s: CPU%d: Running at unlisted freq: %u KHz\n",

134:                 __func__, policy->cpu, policy->cur);

135:             ret = __cpufreq_driver_target(policy, policy->cur - 1,

136:                 CPUFREQ_RELATION_L);

137:

138:             /*

139:              * Reaching here after boot in a few seconds may not

140:              * mean that system will remain stable at "unknown"

141:              * frequency for longer duration. Hence, a BUG_ON().

142:              */

143:             BUG_ON(ret);

144:             pr_warn("%s: CPU%d: Unlisted initial frequency changed to: %u KHz\n",

145:                 __func__, policy->cpu, policy->cur);

146:         }

147:     }

148:

149:     blocking_notifier_call_chain(&cpufreq_policy_notifier_list,

150:                      CPUFREQ_START, policy);

151:

152:     if (!recover_policy) {

153:         ret = cpufreq_add_dev_interface(policy, dev);

154:         if (ret)

155:             goto err_out_unregister;

156:         blocking_notifier_call_chain(&cpufreq_policy_notifier_list,

157:                 CPUFREQ_CREATE_POLICY, policy);

158:     }

159:

160:     write_lock_irqsave(&cpufreq_driver_lock, flags);

161:     list_add(&policy->policy_list, &cpufreq_policy_list);

162:     write_unlock_irqrestore(&cpufreq_driver_lock, flags);

163:

164:     cpufreq_init_policy(policy);

165:

166:     if (!recover_policy) {

167:         policy->user_policy.policy = policy->policy;

168:         policy->user_policy.governor = policy->governor;

169:     }

170:     up_write(&policy->rwsem);

171:

172:     kobject_uevent(&policy->kobj, KOBJ_ADD);

173:     up_read(&cpufreq_rwsem);

174:

175:     pr_debug("initialization complete\n");

176:

177:     return 0;

178:

179: err_out_unregister:

180: err_get_freq:

181:     write_lock_irqsave(&cpufreq_driver_lock, flags);

182:     for_each_cpu(j, policy->cpus)

183:         per_cpu(cpufreq_cpu_data, j) = NULL;

184:     write_unlock_irqrestore(&cpufreq_driver_lock, flags);

185:

186:     up_write(&policy->rwsem);

187:

188:     if (cpufreq_driver->exit)

189:         cpufreq_driver->exit(policy);

190: err_set_policy_cpu:

191:     if (recover_policy) {

192:         /* Do not leave stale fallback data behind. */

193:         per_cpu(cpufreq_cpu_data_fallback, cpu) = NULL;

194:         cpufreq_policy_put_kobj(policy);

195:     }

196:     cpufreq_policy_free(policy);

197:

198: nomem_out:

199:     up_read(&cpufreq_rwsem);

200:

201:     return ret;

202: }

12~13行：如果cpu处于offline状态，则直接返回。

17~25行：对于SMP系统，可能存在所有的CPU core，使用相同的cpufreq policy的情况。此时，当primary CPU枚举时，调用__cpufreq_add_dev接口创建cpufreq policy时，会同时将该policy提供给其它CPU使用。当其他CPU枚举时，它需要判断是否已经有人代劳了，如果有，则直接返回。这就是这几行代码的逻辑。

30~40行：这几行是处理具有hotplug功能的CPU的。有前面的逻辑可知，如果系统中多个CPU共用一个cpufreq policy，primary CPU在枚举时，会帮忙添加其它CPU的cpufreq policy。但这有一个条件：它只帮忙处理那些处于online状态的CPU，而那些offline状态的CPU，则需要在online的时候，自行判断，并将自身的cpufreq policy添加到系统。

注2：有关上面的两段实现，后面会专门用一个章节介绍。

44~54行：分配cpufreq policy。根据是否是suspend & resume的过程，会有不同的处理方式，我们先不去纠结这些细节。

55~65行：将当前cpu保存在policy的cpu字段。

67行：初始化policy->cpus变量，由“Linux cpufreq framework(2)_cpufreq driver”可知，该变量是一个cpumask类型的变量，记录该policy可以控制哪些online的cpu（毫无疑问，至少会包含当前的cpu）。

75行：调用driver的init接口，相当于设备模型中的driver probe。此时cpufreq deice（policy）和cpufreq driver已经成功会和，driver开始执行。具体行为，请参考“Linux cpufreq framework(2)_cpufreq driver”。

82行：初始化policy->related_cpus，至少包含所有的online CPUs（policy->cpus，由cpufreq_driver->init初始化）。

88行：根据当前CPU online状态，将policy->cpus中处于offline状态的CPU剔除。

97~98行：初始化所有其它共用cpufreq policy的、处于online状态的CPU（policy->cpus）的cpufreq_cpu_data变量，表明它们也都已经有了cpufreq policy（回到17~25行的逻辑，其中的判断，就是依据该变量）。

109~147行：如果cpufreq driver定义了CPUFREQ_NEED_INITIAL_FREQ_CHECK flag，则要求cpufreq core在启动时检查当前频率（policy->cur）是否在frequency table范围内，如果不在，调用__cpufreq_driver_target重新设置频率。

152~158行：对于不是suspend&resume的场景，调用cpufreq_add_dev_interface接口，在该cpu的目录下，创建cpufreq的sysfs目录，以及相应的attribute文件（可参考本文第2章的内容），并为其它共用policy的、处于online状态的cpu，创建指向该cpufreq目录的符号链接。

161行：将新创建的policy，挂到一个全局链表中（cpufreq_policy_list）。

164行：调用cpufreq_init_policy，为该policy分配一个governor，并调用cpufreq_set_policy接口，为该cpu设置一个默认的cpufreq policy。这一段的逻辑有点纠结，我们后面再细讲。

166~-169：更新policy->user_policy，后面再细讲。

3）SMP、Hotplug等场景下，多个CPU共用cpufreq policy的情况总结

前面多次提到，在SMP系统中，多个CPU core可能会由相同的调频机制（其实大多数平台都是这样的）控制，也就是说，所有CPU core的频率和电压，是同时调节的。这种情况下，只需要创建一个cpufreq policy即可，涉及到的代码逻辑包括：

a）primary CPU枚举时，__cpufreq_add_dev会调用cpufreq driver的init接口（cpufreq_driver->init），driver需要根据当前的系统情况，设置policy->cpus，告诉cpufreq core哪些CPU共用同一个cpufreq policy。

b）primary CPU的__cpufreq_add_dev继续执行，初始化policy->related_cpus，并将policy->cpus中处于offline状态的CPU剔除。具体可参考上面的代码分析。

c）primary CPU的__cpufreq_add_dev继续执行，创建sysfs接口，同时为policy->cpus中的其它CPU创建相应的符号链接。

d）secondary CPUs枚举，执行__cpufreq_add_dev，判断primary CPU已经代劳之后，直接退出。

e）对于hotplugable的CPU，hotplug in时，由于primary CPU没有帮忙创建sysfs的符号链接，或者hotplug out的时候符号链接被删除，因此需要重新创建。

4.2 频率调整

cpufreq framework的频率调整逻辑，总结如下：

通过调整policy（struct cpufreq_policy），确定CPU频率调整的一个大方向，主要是由min_freq和max_freq组成的频率范围；

通过cpufreq governor，确定最终的频率值。

下面结合代码，做进一步的阐述。

1）cpufreq_set_policy

cpufreq_set_policy用来设置一个新的cpufreq policy，调用的时机包括：

a）初始化时（__cpufreq_add_dev->cpufreq_init_policy->cpufreq_set_policy），将cpufreq_driver->init时提供的基础policy，设置生效。

b）修改scaling_max_freq或scaling_min_freq时（store_one->cpufreq_set_policy），将用户空间设置的新的频率范围，设置生效。

c）修改cpufreq governor时（scaling_governor->store_scaling_governor->cpufreq_set_policy），更新governor。

来看一下cpufreq_set_policy都做了什么事情。

  1: static int cpufreq_set_policy(struct cpufreq_policy *policy,

  2:                 struct cpufreq_policy *new_policy)

  3: {

  4:     struct cpufreq_governor *old_gov;

  5:     int ret;

6:

  7:     pr_debug("setting new policy for CPU %u: %u - %u kHz\n",

  8:          new_policy->cpu, new_policy->min, new_policy->max);

9:

 10:     memcpy(&new_policy->cpuinfo, &policy->cpuinfo, sizeof(policy->cpuinfo));

11:

 12:     if (new_policy->min > policy->max || new_policy->max < policy->min)

 13:         return -EINVAL;

14:

 15:     /* verify the cpu speed can be set within this limit */

 16:     ret = cpufreq_driver->verify(new_policy);

 17:     if (ret)

 18:         return ret;

19:

 20:     /* adjust if necessary - all reasons */

 21:     blocking_notifier_call_chain(&cpufreq_policy_notifier_list,

 22:             CPUFREQ_ADJUST, new_policy);

23:

 24:     /* adjust if necessary - hardware incompatibility*/

 25:     blocking_notifier_call_chain(&cpufreq_policy_notifier_list,

 26:             CPUFREQ_INCOMPATIBLE, new_policy);

27:

 28:     /*

 29:      * verify the cpu speed can be set within this limit, which might be

 30:      * different to the first one

 31:      */

 32:     ret = cpufreq_driver->verify(new_policy);

 33:     if (ret)

 34:         return ret;

35:

 36:     /* notification of the new policy */

 37:     blocking_notifier_call_chain(&cpufreq_policy_notifier_list,

 38:             CPUFREQ_NOTIFY, new_policy);

39:

 40:     policy->min = new_policy->min;

 41:     policy->max = new_policy->max;

42:

 43:     pr_debug("new min and max freqs are %u - %u kHz\n",

 44:          policy->min, policy->max);

45:

 46:     if (cpufreq_driver->setpolicy) {

 47:         policy->policy = new_policy->policy;

 48:         pr_debug("setting range\n");

 49:         return cpufreq_driver->setpolicy(new_policy);

 50:     }

51:

 52:     if (new_policy->governor == policy->governor)

 53:         goto out;

54:

 55:     pr_debug("governor switch\n");

56:

 57:     /* save old, working values */

 58:     old_gov = policy->governor;

 59:     /* end old governor */

 60:     if (old_gov) {

 61:         __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

 62:         up_write(&policy->rwsem);

 63:         __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT);

 64:         down_write(&policy->rwsem);

 65:     }

66:

 67:     /* start new governor */

 68:     policy->governor = new_policy->governor;

 69:     if (!__cpufreq_governor(policy, CPUFREQ_GOV_POLICY_INIT)) {

 70:         if (!__cpufreq_governor(policy, CPUFREQ_GOV_START))

 71:             goto out;

72:

 73:         up_write(&policy->rwsem);

 74:         __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT);

 75:         down_write(&policy->rwsem);

 76:     }

77:

 78:     /* new governor failed, so re-start old one */

 79:     pr_debug("starting governor %s failed\n", policy->governor->name);

 80:     if (old_gov) {

 81:         policy->governor = old_gov;

 82:         __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_INIT);

 83:         __cpufreq_governor(policy, CPUFREQ_GOV_START);

 84:     }

85:

 86:     return -EINVAL;

87:

 88:  out:

 89:     pr_debug("governor: change or update limits\n");

 90:     return __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);

 91: }

15~18行：调用driver的verify接口，判断新的policy是否有效。

20~26行：notifier接口用于policy的调整，如果有其它模块对新的policy不满意，可以通过这样的机制修正，具体不再描述，感兴趣的读者可以自行研究。

28~34行：修正后，再交给driver进行verify。

46~50行：如果driver提供了setpolicy回调（回忆一下“Linux cpufreq framework(2)_cpufreq driver”），则说明硬件有能力根据policy所指定的范围，自行调节频率，其它机制就不需要了，调用该回调，将新的policy配置给硬件后，退出。

否则（后面的代码），则需要由governor执行具体的频率调整动作，调用governor的接口，切换governor。有关cpufreq governor的描述，请参考下一篇文章。

2）scaling_setspeed

上面提到了，policy只规定了频率调整的一个范围，如果driver不支持setpolicy操作，则需要由cpufreq governor确定具体的频率值，并调用driver的target或者target_index接口，修改CPU的频率值。

有关cpufreq governor的介绍，请参考后续的文章（“linux cpufreq framework(4)_cpufreq governor”）。不过这其中有一个例外，就是当governor为“userspace”时（参考第3章的描述），可以直接通过scaling_setspeed文件，从用户空间修改频率值，代码如下：

  1: static ssize_t store_scaling_setspeed(struct cpufreq_policy *policy,

  2:                                         const char *buf, size_t count)

  3: {

  4:         unsigned int freq = 0;

  5:         unsigned int ret;

6:

  7:         if (!policy->governor || !policy->governor->store_setspeed)

  8:                 return -EINVAL;

9:

 10:         ret = sscanf(buf, "%u", &freq);

 11:         if (ret != 1)

 12:                 return -EINVAL;

13:

 14:         policy->governor->store_setspeed(policy, freq);

15:

 16:         return count;

 17: }

由此可以猜到，“userspace” governor具有store_setspeed函数，该函数应该可以直接修改频率值。留到（“linux cpufreq framework(4)_cpufreq governor”）再欣赏吧。

原创文章，转发请注明出处。蜗窝科技，www.wowotech.net。