Linux cpuidle framework(3)_ARM64 generic CPU idle driver

作者：wowo 发布于：2015-1-6 23:13 分类：电源管理子系统

1. 前言

本文以ARM64平台下的cpuidle driver为例，说明怎样在cpuidle framework的框架下，编写cpuidle driver。另外，本文在描述cpuidle driver的同时，会涉及到CPU hotplug的概念，因此也可作为CPU hotplug的引子。

2. arm64_idle_init

ARM64 generic CPU idle driver的代码位于“drivers/cpuidle/cpuidle-arm64.c”中，它的入口函数是arm64_idle_init，如下：

   1: static int __init arm64_idle_init(void)
   2: {
   3:         int cpu, ret;
   4:         struct cpuidle_driver *drv = &arm64_idle_driver;
   5:  
   6:         /*
   7:          * Initialize idle states data, starting at index 1.
   8:          * This driver is DT only, if no DT idle states are detected (ret == 0)
   9:          * let the driver initialization fail accordingly since there is no
  10:          * reason to initialize the idle driver if only wfi is supported.
  11:          */
  12:         ret = dt_init_idle_driver(drv, arm64_idle_state_match, 1);
  13:         if (ret <= 0) {
  14:                 if (ret)
  15:                         pr_err("failed to initialize idle states\n");
  16:                 return ret ? : -ENODEV;
  17:         }
  18:  
  19:         /*
  20:          * Call arch CPU operations in order to initialize
  21:          * idle states suspend back-end specific data
  22:          */
  23:         for_each_possible_cpu(cpu) {
  24:                 ret = cpu_init_idle(cpu);
  25:                 if (ret) {
  26:                         pr_err("CPU %d failed to init idle CPU ops\n", cpu);
  27:                         return ret;
  28:                 }
  29:         }
  30:  
  31:         ret = cpuidle_register(drv, NULL);
  32:         if (ret) {
  33:                 pr_err("failed to register cpuidle driver\n");
  34:                 return ret;
  35:         }
  36:  
  37:         return 0;
  38: }
  39: device_initcall(arm64_idle_init);

由该函数的执行过程，可以看出cpuidle driver的实现过程，包括：

1）静态定义一个struct cpuidle_driver变量（这里为arm64_idle_driver）并填充必要的字段，如下

   1: static struct cpuidle_driver arm64_idle_driver = {
   2:         .name = "arm64_idle",
   3:         .owner = THIS_MODULE,
   4:         /*
   5:          * State at index 0 is standby wfi and considered standard
   6:          * on all ARM platforms. If in some platforms simple wfi
   7:          * can't be used as "state 0", DT bindings must be implemented
   8:          * to work around this issue and allow installing a special
   9:          * handler for idle state index 0.
  10:          */
  11:         .states[0] = {
  12:                 .enter                  = arm64_enter_idle_state,
  13:                 .exit_latency           = 1,
  14:                 .target_residency       = 1,
  15:                 .power_usage            = UINT_MAX,
  16:                 .flags                  = CPUIDLE_FLAG_TIME_VALID,
  17:                 .name                   = "WFI",
  18:                 .desc                   = "ARM64 WFI",
  19:         }
  20: };

该driver的名称为“arm64_idle”，会体现在sysfs（如/sys/devices/system/cpu/cpuidle/current_driver）中；

稍微留意一下上面的注释，所有的ARM平台，都应提供默认的WFI standby状态，作为idle state 0，如果有例外，则需要在DTS中另行处理；

对于state0，driver将其初始化为：exit latency和target residency均为1（最小值），power usage为整数中的最大值。由此可以看出，这些信息不是实际信息（因为driver不可能知道所有ARM平台的WFI相关的信息），而是相对信息，其中的含义是：所有其它的state，exit latency和target residency都会比state0大，power usage都会比state0小，够用了！多么巧妙地设计！

2）初始化其它的idle states（从state1开始），必须通过DTS操作，否则返回失败。具体可参考后续的描述。

3）对每一个cpu，调用cpu_init_idle接口，初始化用于支持cpuidle的、和cpu suspend有关的后端数据。后面会详细介绍。

4）调用cpuidle_register，将cpuidle driver注册到cpuidle core中（具体可参考“Linux cpuidle framework(2)_cpuidle core”）。

3. dt_init_idle_driver

dt_init_idle_driver函数用于从DTS中解析出cpuidle states的信息，并初始化arm64_idle_driver中的states数组。在分析这个函数之前，我们先来看一下cpuidle相关的DTS源文件是怎么写的：

注：写这篇文章所参考的kernel（3.18-rc4）中，没有ARM64平台使用了cpuidle功能，因此这里给不出ARM64平台下的参考文件。好在ARM和ARM64在cpuidle dts解析上面的流程是一样的，我们可以借用ARM中的例子。

   1: /* arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts */
   2: cpus {
   3:         #address-cells = <1>;
   4:         #size-cells = <0>;
   5:  
   6:         cpu0: cpu@0 {
   7:                 device_type = "cpu";
   8:                 compatible = "arm,cortex-a15";
   9:                 reg = <0>;
  10:                 cci-control-port = <&cci_control1>;
  11:                 cpu-idle-states = <&CLUSTER_SLEEP_BIG>;
  12:         };
  13:  
  14:         cpu1: cpu@1 {
  15:                 device_type = "cpu";
  16:                 compatible = "arm,cortex-a15";
  17:                 reg = <1>;
  18:                 cci-control-port = <&cci_control1>;
  19:                 cpu-idle-states = <&CLUSTER_SLEEP_BIG>;
  20:         };
  21:  
  22:         cpu2: cpu@2 {
  23:                 device_type = "cpu";
  24:                 compatible = "arm,cortex-a7";
  25:                 reg = <0x100>;
  26:                 cci-control-port = <&cci_control2>;
  27:                 cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
  28:         };
  29:  
  30:         cpu3: cpu@3 {
  31:                 device_type = "cpu";
  32:                 compatible = "arm,cortex-a7";
  33:                 reg = <0x101>;
  34:                 cci-control-port = <&cci_control2>;
  35:                 cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
  36:         };
  37:  
  38:         cpu4: cpu@4 {
  39:                 device_type = "cpu";
  40:                 compatible = "arm,cortex-a7";
  41:                 reg = <0x102>;
  42:                 cci-control-port = <&cci_control2>;
  43:                 cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
  44:         };
  45:         idle-states {
  46:             CLUSTER_SLEEP_BIG: cluster-sleep-big {
  47:                 compatible = "arm,idle-state";
  48:                 local-timer-stop;
  49:                 entry-latency-us = <1000>;
  50:                 exit-latency-us = <700>;
  51:                 min-residency-us = <2000>;
  52:             };
  53:  
  54:             CLUSTER_SLEEP_LITTLE: cluster-sleep-little {
  55:                 compatible = "arm,idle-state";
  56:                 local-timer-stop;
  57:                 entry-latency-us = <1000>;
  58:                 exit-latency-us = <500>;
  59:                 min-residency-us = <2500>;
  60:             };
  61: };

cpuidle有关的DTS信息，从属于cpus node中，先看最后面的idle-states node，它负责定义该ARM平台支持的所有的idle states，每个子node就是一个state：
        各个state定义都以“arm,idle-state”标识；
        entry-latency-us、exit-latency-us、min-residency-us分别定义了改idle state的几个重要参数，local-timer-stop对应CPUIDLE_FLAG_TIMER_STOP flag（具体含义可参考“Linux cpuidle framework(2)_cpuidle core”中的描述）；
        这些信息会被dt_init_idle_driver解析出来，并保存在arm64_idle_driver的state数组中。

在每个cpu的node中，通过cpu-idle-states字段，指明该CPU支持的idle states，可以有多个。        

结合上面的DTS信息，dt_init_idle_driver函数的执行过程如下。

   1: /* drivers/cpuidle/dt_idle_states.c */
   2: int dt_init_idle_driver(struct cpuidle_driver *drv,
   3:             const struct of_device_id *matches,
   4:             unsigned int start_idx)
   5: {
   6:     struct cpuidle_state *idle_state;
   7:     struct device_node *state_node, *cpu_node;
   8:     int i, err = 0;
   9:     const cpumask_t *cpumask;
  10:     unsigned int state_idx = start_idx;
  11:  
  12:     if (state_idx >= CPUIDLE_STATE_MAX)
  13:         return -EINVAL;
  14:     /*
  15:      * We get the idle states for the first logical cpu in the
  16:      * driver mask (or cpu_possible_mask if the driver cpumask is not set)
  17:      * and we check through idle_state_valid() if they are uniform
  18:      * across CPUs, otherwise we hit a firmware misconfiguration.
  19:      */
  20:     cpumask = drv->cpumask ? : cpu_possible_mask;
  21:     cpu_node = of_cpu_device_node_get(cpumask_first(cpumask));
  22:  
  23:     for (i = 0; ; i++) {
  24:         state_node = of_parse_phandle(cpu_node, "cpu-idle-states", i);
  25:         if (!state_node)
  26:             break;
  27:  
  28:         if (!idle_state_valid(state_node, i, cpumask)) {
  29:             pr_warn("%s idle state not valid, bailing out\n",
  30:                 state_node->full_name);
  31:             err = -EINVAL;
  32:             break;
  33:         }
  34:  
  35:         if (state_idx == CPUIDLE_STATE_MAX) {
  36:             pr_warn("State index reached static CPU idle driver states array size\n");
  37:             break;
  38:         }
  39:  
  40:         idle_state = &drv->states[state_idx++];
  41:         err = init_state_node(idle_state, matches, state_node);
  42:         if (err) {
  43:             pr_err("Parsing idle state node %s failed with err %d\n",
  44:                    state_node->full_name, err);
  45:             err = -EINVAL;
  46:             break;
  47:         }
  48:         of_node_put(state_node);
  49:     }
  50:  
  51:     of_node_put(state_node);
  52:     of_node_put(cpu_node);
  53:     if (err)
  54:         return err;
  55:     /*
  56:      * Update the driver state count only if some valid DT idle states
  57:      * were detected
  58:      */
  59:     if (i)
  60:         drv->state_count = state_idx;
  61:  
  62:     /*
  63:      * Return the number of present and valid DT idle states, which can
  64:      * also be 0 on platforms with missing DT idle states or legacy DT
  65:      * configuration predating the DT idle states bindings.
  66:      */
  67:     return i;
  68: }
  69: EXPORT_SYMBOL_GPL(dt_init_idle_driver);

1）14~21、28~33行，获取第一个cpu的node，通过其中的“cpu-idle-states”字段，解析出该cpu支持的cpuidle states。同时通过idle_state_valid接口，检查其它CPU是否同样支持这些states，如果不支持，返回错误。也就是说，ARM64 generic CPU idle driver，只支持那些所有cpuidle state都相同的ARM64平台。

2）40~47行，针对每一个支持的state，调用init_state_node接口，解析cpuidle state相关的信息，并保存在drv->state数组的指定index中。解析的过程中，会为每个state指定enter回调函数，对ARM64而言，统一使用arm64_enter_idle_state接口。其它的解析过程，比较简单，不再详细说明了。

4. cpu_init_idle

cpuidle功能的支持，需要依赖CPU的、和电源管理有关的底层代码实现。对ARM64来说，kernel将这些底层代码抽象为一系列的操作函数集（struct cpu_operations，具体可参考arch/arm64/kernel/cpu_ops.c）。对同一个ARM平台，可能有多种类型的操作函数集，设计者可以根据需要选择一种使用（具体可参考本站后续的文档）。

以ARM64为例，ARM document规定了一种PSCI（Power State Coordination Interface）接口，它由firmware实现，用于电源管理有关的操作，如IDLE相关的、SMP相关的、Hotplug相关的、等等。

对cpuidle来说，需要在cpuidle driver注册之前，调用cpu_init_idle，该函数会根据当前使用的操作函数集，调用其中的cpu_init_idle回调函数，进行idle相关的初始化操作。具体的内容，蜗蜗会在其它文章中说明，这里就暂停了。

5. arm64_enter_idle_state

idle state的enter函数用于使CPU进入指定的idle state，如下：

   1: static int arm64_enter_idle_state(struct cpuidle_device *dev,
   2:                                   struct cpuidle_driver *drv, int idx)
   3: {
   4:         int ret;
   5:  
   6:         if (!idx) {
   7:                 cpu_do_idle();
   8:                 return idx;
   9:         }
  10:  
  11:         ret = cpu_pm_enter();
  12:         if (!ret) {
  13:                 /*
  14:                  * Pass idle state index to cpu_suspend which in turn will
  15:                  * call the CPU ops suspend protocol with idle index as a
  16:                  * parameter.
  17:                  */
  18:                 ret = cpu_suspend(idx);
  19:  
  20:                 cpu_pm_exit();
  21:         }
  22:  
  23:         return ret ? -1 : idx;
  24: }

如果是idle state0（即WFI），调用传统cpu_do_idle接口，该接口的实现，可参照“Linux cpuidle framework(1)_概述和软件架构”中第2章ARM9的例子，在kernel source code中跟踪；

对于其它的state，首先调用cpu_pm_enter，发出CPU即将进入low power state的通知。如果成功，则调用cpu_suspend接口，让cpu进入指定的idle状态。最后，从idle返回时，发送退出low power state的通知；

cpu_pm_enter/cpu_pm_exit位于kernel/cpu_pm.c中，会在其它文章介绍；

cpu_suspend位于arch/arm64/kernel/suspend.c中，直接调用操作函数集（struct cpu_operations，如PSCI）中的cpu_suspend回调函数。具体会在其它文章中描述。

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

标签: driver arm64 dts cpuidle

« Linux cpuidle framework(4)_menu governor | Linux时间子系统之（五）：POSIX Clock»

评论：

伊斯科明
2019-10-14 19:55
您好，请教一个问题，我现在手上的kernel是4.9.113版本，dts文件中有关idle-state的参数如下：
idle-states {
    entry-method = "arm,psci";
    SYSTEM_SLEEP_0: system-sleep-0 {
        compatible = "arm,idle-state";
        arm,psci-suspend-param = <0x0010000>;
        local-timer-stop;
        entry-latency-us = <0x3fffffff>;
        exit-latency-us = <0x40000000>;
        min-residency-us = <0xffffffff>;
    };
};
我之前遇到一个suspend的问题是和arm,psci-suspend-param有关的，请问一下，这个参数具体是有什么作用的呢？
回复
fengmiao
2018-01-26 18:40
@wowo
请教下您，我看到有些平台实现了好多cpuidleDriver，比如：cps_driver、little_idle之类的。系统运行的时候是把CPU与特定的cpudile Driver联系起来，是通过DTS配置吗？
回复
wowo
2018-01-30 08:48
@fengmiao：正常的driver（例如本文的例子），应该是这样。具体你可以看看driver的的实现。
回复
bsp
2020-08-24 09:18
@fengmiao：kernel-4.19,通过dts中的enable-method配置
回复
bsp
2020-08-24 09:18
@fengmiao：kernel-4.19,通过dts中的enable-method配置
回复
fengmiao
2018-01-26 18:26
我看到有些平台实现了好多cpuidleDriver，比如：cps_driver、little_idle之类的。系统运行的时候是把CPU与特定的cpudile Driver联系起来，是通过DTS配置吗？
回复
jiffy
2017-12-25 11:32
@wowo
例如:entry-latency-us = <1000>;exit-latency-us = <500>;min-residency-us = <2500>;我的理解是这三个参数在系统起来之前已经配置好的,那么它们的值是怎么确定的,配置的依据是什么?
回复
hello-world
2017-12-25 12:03
@jiffy：每个平台都不一样，那些数据需要实际测试才能得出的
回复
jiffy
2018-01-03 00:45
@hello-world：@wowo
能否讲解下idle-states dts结构中关于min-residency参数的计算过程，现在有个项目需要调试这个参数，谢谢！
回复
wowo
2018-01-04 08:58
@jiffy：这个参数的含义是：cpu在idle状态最少停留多少时间才是划得来的。
如果CPU很快（小于这个时间）就会从idle状态回来，就没必要idle了。
至于怎么计算的，应该是跟平台的特性有关（没做过CPU核，不是很清楚）。
你可以根据进、出所需的时间和功耗，idle状态所节省的功耗，换算一下，看看多久合适。或者设计一个测试场景，实际测试一下也行。
回复
Layman
2016-11-29 11:18
@wowo,

请教两个问题：
1.suspend和idle的终极状态都是WFI，请问他们之间有何异同？
2.WFI“put the core in a low-power state by disabling the clocks in the core while keeping the core powered up”，那请问处于WFI的cpu功耗大概会是什么数量级的？

谢谢
回复
wowo
2016-11-29 13:22
@Layman：1. 你指的终极状态，都是所cpu core的状态，而在进入这个终极状态之前，做了什么事情，就是它们的区别。
2. 这个问题不太好回答啊，因为和具体的CPU有关，建议既可以在自己的CPU上测试一下。对比一下WFI前后的电流，应该可以看出来。
回复
王语双
2015-01-14 13:37
满满的，全是技术。
技术创造美。
回复

发表评论：

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog