Linux Regulator Framework(2)

Linux Regulator Framework(2)_regulator driver

作者：wowo 发布于：2015-4-16 22:18 分类：电源管理子系统

1. 前言

本文从regulator driver的角度，描述怎样基于regulator framework编写regulator驱动。同时，以此为契机，学习、理解regulator有关的物理特性，以便能够更好的使用它们。

2. regulator driver的实现步骤

2.1 确定系统中regulator有关的硬件组成

提起硬件，最好能有个例子，好在有device tree，一个活生生的硬件拓扑结构。这里以NVIDIA Tegra Dalmore A04开发板为例（regulator有关的device tree位于“arch\arm\boot\dts\tegra114-dalmore.dts”）：

这里的regulator结构是相当复杂的，其中彩色框代表最终的regulator抽象，它的前一级表示regulator的载体（可以是PMIC、CPU、等等）。下面将会详细说明：

a）CPU通过I2C controller，连接一个降压控制器（TI tps51632），该控制器输出名称为“vdd-cpu”的电压，就称作vdd-cpu regulator吧（因此，在kernel中，regulator是一个虚拟设备）。

b）CPU通过I2C controller，连接一个前端电源管理芯片（TI tps65090），该芯片除了具备充电管理功能外，内置了多个regulator，例如dcdc1、dcdc2等等。

c）CPU通过I2C controller，连接另一个电源管理芯片（TI tps65913），该芯片具有两个功能：GPIO输出和PMIC。PMIC内置了多个regulator，如vddio-ddr、vdd-core等等。

d）CPU内部也集成了一些regulator，如vdd_ac_bat等等。

注1：单纯从硬件的角度看，是不存在图中"regulators“、PMIC等实体的，它们的出现，已经包含了软件设计的思路。之所以画在这里，是方便后面的描述。

2.2 使用DTS，将硬件拓扑呈现出来

我们都知道，DTS的功能是描述设备的拓扑结构，并在系统初始化的时候，为被描述的设备创建并注册对应的platform device，最终和相应的platform driver相遇，执行其probe接口，实现设备的枚举功能。但是，在这些基本原则之外，还需要一些更深的思考：

DTS节点（node）怎么和设备对应？是以设备的“物理界限”为单位，还是以设备的“功能”为单位？

是不是所有的“设备”都应该在kernel中创建一个platform device？如果不是，创建的依据是什么？

这些思考在本文的例子（NVIDIA Tegra Dalmore A04的regulator）中体现尤为突出，它的本质是软件设计中的模块划分，从而决定了regulator在DTS中的呈现方式和层次。

1）tps51632

tps51632是一个简单的器件，位于i2c总线下面，包含一个regulator器件，因此其DTS比较简单，如下：

        1: /* arch\arm\boot\dts\tegra114-dalmore.dts */

       2: i2c@7000d000 {

       3:         status = "okay";

       4:         clock-frequency = <400000>;

       5:  

       6:         tps51632@43 {

       7:                 compatible = "ti,tps51632";

       8:                 reg = <0x43>;

       9:                 regulator-name = "vdd-cpu";

      10:                 regulator-min-microvolt = <500000>;

      11:                 regulator-max-microvolt = <1520000>;

      12:                 regulator-boot-on;

      13:                 regulator-always-on;

      14:         };

      15:         ...

      16: }

i2c控制器的node为“i2c@7000d000”，tps51632是其下的一个子node，名称为“tps51632@43”，compatible为“ti,tps51632”。tps51632下面以“regulator-”为前缀的字段，是regulator特有的字段，后面会统一介绍。

注2：为什么“i2c@7000d000”中没有compatible字段？其实是有的，可参考“arch\arm\boot\dts\tegra114.dtsi”，DTC在编译DTS时，会将这两个文件中的node合并。

注3：kernel在初始化时，只会为二级node（即“/”下面的节点，本文的例子是“i2c@7000d000”）创建platform设备，至于三级node（这里的“tps51632@43”），则由其bus（i2c）创建。后面我们会遇到其它的情况，到时再介绍。

2）tps65090

tps65090相对比较复杂，它位于相同的i2c总线下面，但包含两个相对复杂的功能实体，charger和PMIC，我们看看其DTS怎么写的：

       1: i2c@7000d000 {

       2:         status = "okay";

       3:         ...

       4:  

       5:         tps65090@48 {

       6:                 compatible = "ti,tps65090";

       7:                 reg = <0x48>;

       8:                 ...

       9:  

                charger: charger {

                        compatible = "ti,tps65090-charger";

                        ti,enable-low-current-chrg;

                };

                

                regulators {

                        tps65090_dcdc1_reg: dcdc1 {

                                regulator-name = "vdd-sys-5v0";

                                regulator-always-on;

                                regulator-boot-on;

                        };

                

                        tps65090_dcdc2_reg: dcdc2 {

                                regulator-name = "vdd-sys-3v3";

                                regulator-always-on;

                                regulator-boot-on;

                        };

                        ...

                }

        }

}

和tps51632类似，但它下面又包含了两个子node：charger和regulators。其中charger竟然还有compatible字段。

回忆一下上面“注3”，kernel只会为"i2c@7000d000”创建platform device，“tps65090@48”则由i2c core创建，那么它下面的子node呢？一定是tps65090 driver处理了，感兴趣的读者可以阅读“drivers/mfd/tps65090.c”、“drivers/power/tps65090-charger.c”和“drivers/regulator/tps65090-regulator.c”，这里面还涉及了MFD（multi-function device，多功能设备），很有意思。

回到本文的主题上，虽然这里的regulators没有compatible字段，也会创建相应的platform device（具体可参考“drivers/mfd/tps65090.c”），这从侧面回答了上面的一个思考：从物理范畴，tps65090是一个独立的设备，但它内部有两个功能模块，因此会存在两个platform device。

再来看regulators中子node----regulator，由于数量比较多，就没必要创建platform device了。同样，“regulator-”为前缀的字段，是regulator特有的字段，后面统一介绍。

3）tps65913，和tps65090类似，不再介绍。

4）CPU中的regulator

这一类regulator比较特殊，直接集成在CPU内部，DTS如下：

       1: regulators {

       2:         compatible = "simple-bus";

       3:         #address-cells = <1>;

       4:         #size-cells = <0>;

       5:  

       6:         vdd_ac_bat_reg: regulator@0 {

       7:                 compatible = "regulator-fixed";

       8:                 reg = <0>;

       9:                 regulator-name = "vdd_ac_bat";

      10:                 regulator-min-microvolt = <5000000>;

      11:                 regulator-max-microvolt = <5000000>;

      12:                 regulator-always-on;

      13:         };

      14:  

      15:         dvdd_ts_reg: regulator@1 {

      16:                 compatible = "regulator-fixed";

      17:                 reg = <1>;

      18:                 regulator-name = "dvdd_ts";

      19:                 regulator-min-microvolt = <1800000>;

      20:                 regulator-max-microvolt = <1800000>;

      21:                 enable-active-high;

      22:                 gpio = <&gpio TEGRA_GPIO(H, 5) GPIO_ACTIVE_HIGH>;

      23:         };

      24:         ...

      25: };

在回到刚才的话题上，kernel只为二级node创建platform device（这里的“regulators”），那三级node（一个个的regulator）呢？没有相对标准的bus帮它们创建怎么办？借助“simple-bus”，具体可以参考of_platform_bus_create（“Device Tree(三):代码分析”）。

另外，这里的例子比较简单，都是fixed regulator，regulator framework core可以帮忙实现fixed类型的regulator的驱动，后面会说明。

2.3 编写与DTS节点对应的driver

这些driver的存在形式是多种多样的，但所做的工作基本类似：

1）初始化regulator的宿主（如上面的tps5163、PMIC、等等），最终的目的是，通过宿主提供的接口，修改regulator的输出。

2）初始化用于描述regulator的静态信息（struct regulator_desc）和动态信息（struct regulator_config），并以这二者为参数，调用regulator_register接口，将regulator注册到kernel中。

3）静态信息中包含regulator的操作函数集（struct regulator_ops），后续regulator的控制，将会由regulator framework core直接调用这些回调函数完成。

4）后面的事情，例如sysfs attribute创建等，就交给regulator framework core了。

3. DTS相关的实现逻辑

3.1 DTS的内容

回忆一下“Linux Regulator Framework(1)_概述”中介绍的machine的主要功能：使用软件语言（struct regulator_init_data），静态的描述regulator在板级的物理现状。对regulator driver而言，DTS主要用于配置regulator的init data。先看一下struct regulator_init_data：

       1: /**

       2:  * struct regulator_init_data - regulator platform initialisation data.

       3:  *

       4:  * Initialisation constraints, our supply and consumers supplies.

       5:  *

       6:  * @supply_regulator: Parent regulator.  Specified using the regulator name

       7:  *                    as it appears in the name field in sysfs, which can

       8:  *                    be explicitly set using the constraints field 'name'.

       9:  *

      10:  * @constraints: Constraints.  These must be specified for the regulator to

      11:  *               be usable.

      12:  * @num_consumer_supplies: Number of consumer device supplies.

      13:  * @consumer_supplies: Consumer device supply configuration.

      14:  *

      15:  * @regulator_init: Callback invoked when the regulator has been registered.

      16:  * @driver_data: Data passed to regulator_init.

      17:  */

      18: struct regulator_init_data {

      19:         const char *supply_regulator;        /* or NULL for system supply */

      20:  

      21:         struct regulation_constraints constraints;

      22:  

      23:         int num_consumer_supplies;

      24:         struct regulator_consumer_supply *consumer_supplies;

      25:  

      26:         /* optional regulator machine specific init */

      27:         int (*regulator_init)(void *driver_data);

      28:         void *driver_data;      /* core does not touch this */

      29: };

supply_regulator，该regulator的前级regulator，一般在regulator driver中直接指定；

constraints，该regulator的使用限制，由DTS配置，并可以借助regulator core提供的辅助API（regulator_of_get_init_data）自动解析。后面会详细介绍；

num_consumer_supplies、consumer_supplies，使用该regulator的consumer的个数，及其设备名和supply名的map。用于建立consumer设备和regulator之间的关联，后面介绍consumer DTS时再详细说明；

regulator_init，regulator的init回调，由regulator driver提供，并在regulator注册时调用；

driver_data，保存driver的私有数据，并在调用regulator_init时传入。

看来DTS的内容都在struct regulation_constraints中，该结构保存了该regulator所有的物理限制，如下：

       1: struct regulation_constraints {

       2:  

       3:         const char *name;

       4:  

       5:         /* voltage output range (inclusive) - for voltage control */

       6:         int min_uV;

       7:         int max_uV;

       8:  

       9:         int uV_offset;

  

        /* current output range (inclusive) - for current control */

        int min_uA;

        int max_uA;

  

        /* valid regulator operating modes for this machine */

        unsigned int valid_modes_mask;

  

        /* valid operations for regulator on this machine */

        unsigned int valid_ops_mask;

  

        /* regulator input voltage - only if supply is another regulator */

        int input_uV;

  

        /* regulator suspend states for global PMIC STANDBY/HIBERNATE */

        struct regulator_state state_disk;

        struct regulator_state state_mem;

        struct regulator_state state_standby;

        suspend_state_t initial_state; /* suspend state to set at init */

  

        /* mode to set on startup */

        unsigned int initial_mode;

  

        unsigned int ramp_delay;

        unsigned int enable_time;

  

        /* constraint flags */

        unsigned always_on:1;   /* regulator never off when system is on */

        unsigned boot_on:1;     /* bootloader/firmware enabled regulator */

        unsigned apply_uV:1;    /* apply uV constraint if min == max */

        unsigned ramp_disable:1; /* disable ramp delay */

};

name，用于描述该constraints；

min_uV、max_uV，输出电压的范围，[min_uV, max_uV]，单位为uV。只对voltage regulator有效；

uV_offset，consumer看到的电压和实际电压之间的偏移值。通常用于补偿压降。只对voltage regulator有效；

min_uA、max_uA，输出电流的范围，[min_uA, max_uA]，单位为uA。只对current regulator有效；

valid_modes_mask，regulator mode相关的内容，和DTS无关，后面再解释；

valid_ops_mask，该regulator支持哪些操作，以bit mask的形式提供，包括：
        REGULATOR_CHANGE_VOLTAGE，可以改变输出电压；
        REGULATOR_CHANGE_CURRENT，可以改变输出电流；
        REGULATOR_CHANGE_MODE，可以修改mode，后面再介绍；
        REGULATOR_CHANGE_STATUS，可以enable/disable；
        REGULATOR_CHANGE_DRMS，支持Dynamic Regulator Mode Switching（DRMS），可以动态的调整regulator的mode，有关mode描述可参考5.3章节；
        REGULATOR_CHANGE_BYPASS，支持bypass模式。

input_uV，如果该regulator的输入是另一个regulator，该字段指定regulator期望的输入电压；

state_xxx、initial_state，regulator电源管理有关的字段，后面会专门介绍；

initial_mode，初始mode，具体请参考5.3节的介绍；

always_on，是否一直保持使能状态；

boot_on，是否在启动时使能；

rapm_delay，由于模拟器件的特性，电压改变，需要一定的生效时间。在一定的范围内，生效时间和电压的变化值成比例。该变量就是描述regulator器件的这个特性，单位为uV/us，即1us可以产生多大的电压变化。在rapm_disable不为1的情况下，当consumer要求改变电压时，regulator framework core会根据该变量，以及电压改变量，计算出需要等待的时间，进行延时操作；

rapm_disable，是否禁止延时操作；

enable time，regulator的开启时间，单位为us。consumer enable regulator时，regulator framework会根据该变量进行延时操作；

apply_uV，如果min_uV和max_uV相同，该变量指示“在regulator注册到kernel时，是否将电压设置为min_uV/max_uV。

结合struct regulation_constraints结构，我们解释一下2.2小节中tps51632的DTS：

       1: tps51632@43 {

       2:         compatible = "ti,tps51632";

       3:         reg = <0x43>;

       4:         regulator-name = "vdd-cpu";

       5:         regulator-min-microvolt = <500000>;

       6:         regulator-max-microvolt = <1520000>;

       7:         regulator-boot-on;

       8:         regulator-always-on;

       9: };

regulator-name，对应struct regulation_constraints中name；

regulator-min-microvolt，对应struct regulation_constraints中的min_uV；

regulator-max-microvolt，对应struct regulation_constraints中的max_uV；

regulator-boot-on，对应struct regulation_constraints中的boot_on；

regulator-always-on，对应struct regulation_constraints中的always_on。

其它的字段，可以根据实际情况，自行添加，具体可参考“Documentation/devicetree/bindings/regulator/regulator.txt”中的描述。

3.2 DTS的解析

regulator的DTS信息，可以通过两种方法解析：

1）在regulator注册前，调用of_get_regulator_init_data接口自行解析，该接口的实现如下：

       1: struct regulator_init_data *of_get_regulator_init_data(struct device *dev,

       2:                                                 struct device_node *node)

       3: {

       4:         struct regulator_init_data *init_data;

       5:  

       6:         if (!node)

       7:                 return NULL;

       8:  

       9:         init_data = devm_kzalloc(dev, sizeof(*init_data), GFP_KERNEL);

      10:         if (!init_data)

      11:                 return NULL; /* Out of memory? */

      12:  

      13:         of_get_regulation_constraints(node, &init_data);

      14:         return init_data;

      15: }

      16: EXPORT_SYMBOL_GPL(of_get_regulator_init_data);

该接口有两个输入参数：设备指针，以及包含了DTS信息的node指针（以3.1中的例子，即“tps51632@43”所在的node）。

它会分配一个struct regulator_init_data变量，并调用of_get_regulation_constraints解析DTS，把结果保存在该变量中。

最后返回struct regulator_init_data变量的地址。

2）在regulator注册时，由regulator_register调用regulator_of_get_init_data帮忙解析，该接口的实现如下：

       1: struct regulator_init_data *regulator_of_get_init_data(struct device *dev,

       2:                                             const struct regulator_desc *desc,

       3:                                             struct device_node **node)

       4: {

       5:         struct device_node *search, *child;

       6:         struct regulator_init_data *init_data = NULL;

       7:         const char *name;

       8:  

       9:         if (!dev->of_node || !desc->of_match)

                return NULL;

  

        if (desc->regulators_node)

                search = of_get_child_by_name(dev->of_node,

                                              desc->regulators_node);

        else

                search = dev->of_node;

  

        if (!search) {

                dev_dbg(dev, "Failed to find regulator container node '%s'\n",

                        desc->regulators_node);

                return NULL;

        }

  

        for_each_child_of_node(search, child) {

                name = of_get_property(child, "regulator-compatible", NULL);

                if (!name)

                        name = child->name;

  

                if (strcmp(desc->of_match, name))

                        continue;

  

                init_data = of_get_regulator_init_data(dev, child);

                if (!init_data) {

                        dev_err(dev,

                                "failed to parse DT for regulator %s\n",

                                child->name);

                        break;

                }

  

                of_node_get(child);

                *node = child;

                break;

        }

        of_node_put(search);

  

        return init_data;

}

与of_get_regulator_init_data不同的是，该接口以struct regulator_desc指针为参数，该参数提供了regulator DTS有关的搜索信息（desc->of_match），根据这些信息，可以获得包含regulator信息的DTS node。

它本质上是一种通用的DTS匹配逻辑（和kernel解析platform device的标准资源类似），大致如下：

a）调用者提供parent node（struct device指针中，代表regulators的宿主设备，如上面的tps65090@48），以及该regulator在DTS中的名称（由desc->of_match提供）。

b）还可以在struct regulator_desc中提供包含regulator DTS信息的node名称（可选，用于regulator不直接在parent node下的情况）。

c）以parent device的node，或者指定的子node为基准，查找其下所有的node，如果node的名字或者“regulator-compatible”字段和desc->of_match匹配，则调用of_get_regulator_init_data从中解析DTS信息。

总结：1、2两种DTS解析的方法，各有优缺点：1直接，方便，容易理解，但会有冗余代码；2简洁，但需要regulator driver开发者非常熟悉解析的原理，并以此设计DTS和struct regulator_desc变量。大家可以根据实际情况，灵活使用。

4. 主要数据结构

4.1 struct regulator_desc

在注册regulator的时候，需要使用struct regulator_desc结构提供该regulator的静态描述。所谓的静态，是指这些描述不会在运行时改变，代表了设备的一种属性，如下：

       1: /* include/linux/regulator/driver.h */

       2:  

       3: struct regulator_desc {

       4:         const char *name;

       5:         const char *supply_name;

       6:         const char *of_match;

       7:         const char *regulators_node;

       8:         int id;

       9:         bool continuous_voltage_range;

        unsigned n_voltages;

        const struct regulator_ops *ops;

        int irq;

        enum regulator_type type;

        struct module *owner;

  

        unsigned int min_uV;

        unsigned int uV_step;

        unsigned int linear_min_sel;

        int fixed_uV;

        unsigned int ramp_delay;

  

        const struct regulator_linear_range *linear_ranges;

        int n_linear_ranges;

  

        const unsigned int *volt_table;

  

        unsigned int vsel_reg;

        unsigned int vsel_mask;

        unsigned int apply_reg;

        unsigned int apply_bit;

        unsigned int enable_reg;

        unsigned int enable_mask;

        unsigned int enable_val;

        unsigned int disable_val;

        bool enable_is_inverted;

        unsigned int bypass_reg;

        unsigned int bypass_mask;

        unsigned int bypass_val_on;

        unsigned int bypass_val_off;

  

        unsigned int enable_time;

  

        unsigned int off_on_delay;

};

name，该regulator的名称，唯一标识该regulator，必须提供；

supply_name，该regulator的输入regulator的名称；

of_match、regulators_node，提供信息，以便在注册的时候自动从DTS中解析init_data，具体可参考3.2小节的描述；

id，标识该regulator的一个数字；

continuous_voltage_range，为true时，表示该regulator可以在一定范围输出连续的电压；

n_voltages，consumer可以通过ops.list_voltage()接口，获取该regulator可以输出的电压值。该变量指定可以获取的电压值的个数，后面讲到ops时，再介绍；

ops，该regulator的操作函数集，见后面；

irq，该regulator的中断号（有的话）；

type，该regulator的类型，包括REGULATOR_VOLTAGE和REGULATOR_CURRENT两种；

其它字段，和regulator的输出控制有关，后面会以专题的形式介绍。

struct regulator_ops提供了regulator的所有操作，如下：

       1: struct regulator_ops {

       2:  

       3:         /* enumerate supported voltages */

       4:         int (*list_voltage) (struct regulator_dev *, unsigned selector);

       5:  

       6:         /* get/set regulator voltage */

       7:         int (*set_voltage) (struct regulator_dev *, int min_uV, int max_uV,

       8:                             unsigned *selector);

       9:         int (*map_voltage)(struct regulator_dev *, int min_uV, int max_uV);

        int (*set_voltage_sel) (struct regulator_dev *, unsigned selector);

        int (*get_voltage) (struct regulator_dev *);

        int (*get_voltage_sel) (struct regulator_dev *);

  

        /* get/set regulator current  */

        int (*set_current_limit) (struct regulator_dev *,

                                 int min_uA, int max_uA);

        int (*get_current_limit) (struct regulator_dev *);

  

        /* enable/disable regulator */

        int (*enable) (struct regulator_dev *);

        int (*disable) (struct regulator_dev *);

        int (*is_enabled) (struct regulator_dev *);

  

        /* get/set regulator operating mode (defined in consumer.h) */

        int (*set_mode) (struct regulator_dev *, unsigned int mode);

        unsigned int (*get_mode) (struct regulator_dev *);

  

        /* Time taken to enable or set voltage on the regulator */

        int (*enable_time) (struct regulator_dev *);

        int (*set_ramp_delay) (struct regulator_dev *, int ramp_delay);

        int (*set_voltage_time_sel) (struct regulator_dev *,

                                     unsigned int old_selector,

                                     unsigned int new_selector);

  

        /* report regulator status ... most other accessors report

         * control inputs, this reports results of combining inputs

         * from Linux (and other sources) with the actual load.

         * returns REGULATOR_STATUS_* or negative errno.

         */

        int (*get_status)(struct regulator_dev *);

  

        /* get most efficient regulator operating mode for load */

        unsigned int (*get_optimum_mode) (struct regulator_dev *, int input_uV,

                                          int output_uV, int load_uA);

  

        /* control and report on bypass mode */

        int (*set_bypass)(struct regulator_dev *dev, bool enable);

        int (*get_bypass)(struct regulator_dev *dev, bool *enable);

        

        /* the operations below are for configuration of regulator state when

         * its parent PMIC enters a global STANDBY/HIBERNATE state */

        

        /* set regulator suspend voltage */

        int (*set_suspend_voltage) (struct regulator_dev *, int uV);

        

        /* enable/disable regulator in suspend state */

        int (*set_suspend_enable) (struct regulator_dev *);

        int (*set_suspend_disable) (struct regulator_dev *);

        

        /* set regulator suspend operating mode (defined in consumer.h) */

        int (*set_suspend_mode) (struct regulator_dev *, unsigned int mode);

};

这些回调函数的具体意义，请参考后续的描述。

4.2 struct regulator_config

struct regulator_config保存了regulator的动态信息，所谓的动态信息，是指那些会在driver运行过程中改变、或者driver运行后才会确定的信息，如下：

       1: struct regulator_config {

       2:         struct device *dev;

       3:         const struct regulator_init_data *init_data;

       4:         void *driver_data;

       5:         struct device_node *of_node;

       6:         struct regmap *regmap;

       7:  

       8:         int ena_gpio;

       9:         unsigned int ena_gpio_invert:1;

      10:         unsigned int ena_gpio_flags;

      11: };

dev，对应的struct device指针。会在regulator_register时，由regulator core分配，保存在此，以便后续使用；

init_data，init data指针，在解析DTS后，保存在此，以便后续使用；

of_node，可以为空；

regmap，参考后续描述；

ena_gpio、ena_gpio_invert、ena_gpio_flags，控制regulator使能的GPIO及其active极性。

4.3 struct regulator_dev

struct regulator_dev是regulator设备的抽象，当driver以struct regulator_desc、struct regulator_config两个类型的参数，调用regulator_register将regulator注册到kernel之后，regulator就会分配一个struct regulator_dev变量，后续所有的regulator操作，都将以该变量为对象。

       1: struct regulator_dev {

       2:         const struct regulator_desc *desc;

       3:         int exclusive;

       4:         u32 use_count;

       5:         u32 open_count;

       6:         u32 bypass_count;

       7:  

       8:         /* lists we belong to */

       9:         struct list_head list; /* list of all regulators */

  

        /* lists we own */

        struct list_head consumer_list; /* consumers we supply */

  

        struct blocking_notifier_head notifier;

        struct mutex mutex; /* consumer lock */

        struct module *owner;

        struct device dev;

        struct regulation_constraints *constraints;

        struct regulator *supply;       /* for tree */

        struct regmap *regmap;

  

        struct delayed_work disable_work;

        int deferred_disables;

  

        void *reg_data;         /* regulator_dev data */

  

        struct dentry *debugfs;

  

        struct regulator_enable_gpio *ena_pin;

        unsigned int ena_gpio_state:1;

  

        /* time when this regulator was disabled last time */

        unsigned long last_off_jiffy;

};

desc，保存了regulator静态描述信息的指针（从这个角度看，所谓的静态描述，其变量必须为全局变量）；

exclusive、use_count、open_count、bypass_count，一些状态记录；

constraints，保存了regulator的constraints指针；

supply，该regulator的supply；

等等。

5 实现逻辑分析

本章简单的分析一下regulator driver相关的实现逻辑。如果要理解有些逻辑，必须具备一些regulator的基础知识，因此在需要的时候，会穿插介绍这些知识。

5.1 regulator core的初始化

regulator core的初始化操作由regulator_init接口负责，主要工作包括：

1）注册regulator class（/sys/class/regulator/）。

2）注册用于调试的debugfs。

和power switch class、input class等类似，regulator framework也是一种class，可以称作regulator class。

5.2 regulator register

regulator的注册，由regulator_register/devm_regulator_register接口负责，如下：

       1: /**

       2:  * regulator_register - register regulator

       3:  * @regulator_desc: regulator to register

       4:  * @config: runtime configuration for regulator

       5:  *

       6:  * Called by regulator drivers to register a regulator.

       7:  * Returns a valid pointer to struct regulator_dev on success

       8:  * or an ERR_PTR() on error.

       9:  */

struct regulator_dev *

regulator_register(const struct regulator_desc *regulator_desc,

           const struct regulator_config *config)

{

    const struct regulation_constraints *constraints = NULL;

    const struct regulator_init_data *init_data;

    static atomic_t regulator_no = ATOMIC_INIT(0);

    struct regulator_dev *rdev;

    struct device *dev;

    int ret, i;

    const char *supply = NULL;

  

    if (regulator_desc == NULL || config == NULL)

        return ERR_PTR(-EINVAL);

  

    dev = config->dev;

    WARN_ON(!dev);

  

    if (regulator_desc->name == NULL || regulator_desc->ops == NULL)

        return ERR_PTR(-EINVAL);

  

    if (regulator_desc->type != REGULATOR_VOLTAGE &&

        regulator_desc->type != REGULATOR_CURRENT)

        return ERR_PTR(-EINVAL);

  

    /* Only one of each should be implemented */

    WARN_ON(regulator_desc->ops->get_voltage &&

        regulator_desc->ops->get_voltage_sel);

    WARN_ON(regulator_desc->ops->set_voltage &&

        regulator_desc->ops->set_voltage_sel);

  

    /* If we're using selectors we must implement list_voltage. */

    if (regulator_desc->ops->get_voltage_sel &&

        !regulator_desc->ops->list_voltage) {

        return ERR_PTR(-EINVAL);

    }

    if (regulator_desc->ops->set_voltage_sel &&

        !regulator_desc->ops->list_voltage) {

        return ERR_PTR(-EINVAL);

    }

  

    rdev = kzalloc(sizeof(struct regulator_dev), GFP_KERNEL);

    if (rdev == NULL)

        return ERR_PTR(-ENOMEM);

  

    init_data = regulator_of_get_init_data(dev, regulator_desc,

                           &rdev->dev.of_node);

    if (!init_data) {

        init_data = config->init_data;

        rdev->dev.of_node = of_node_get(config->of_node);

    }

  

    mutex_lock(®ulator_list_mutex);

  

    mutex_init(&rdev->mutex);

    rdev->reg_data = config->driver_data;

    rdev->owner = regulator_desc->owner;

    rdev->desc = regulator_desc;

    if (config->regmap)

        rdev->regmap = config->regmap;

    else if (dev_get_regmap(dev, NULL))

        rdev->regmap = dev_get_regmap(dev, NULL);

    else if (dev->parent)

        rdev->regmap = dev_get_regmap(dev->parent, NULL);

    INIT_LIST_HEAD(&rdev->consumer_list);

    INIT_LIST_HEAD(&rdev->list);

    BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);

    INIT_DELAYED_WORK(&rdev->disable_work, regulator_disable_work);

  

    /* preform any regulator specific init */

    if (init_data && init_data->regulator_init) {

        ret = init_data->regulator_init(rdev->reg_data);

        if (ret < 0)

            goto clean;

    }

  

    /* register with sysfs */

    rdev->dev.class = ®ulator_class;

    rdev->dev.parent = dev;

    dev_set_name(&rdev->dev, "regulator.%d",

             atomic_inc_return(®ulator_no) - 1);

    ret = device_register(&rdev->dev);

    if (ret != 0) {

        put_device(&rdev->dev);

        goto clean;

    }

  

    dev_set_drvdata(&rdev->dev, rdev);

  

    if (config->ena_gpio && gpio_is_valid(config->ena_gpio)) {

        ret = regulator_ena_gpio_request(rdev, config);

        if (ret != 0) {

            rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",

                 config->ena_gpio, ret);

            goto wash;

        }

  

        if (config->ena_gpio_flags & GPIOF_OUT_INIT_HIGH)

            rdev->ena_gpio_state = 1;

  

        if (config->ena_gpio_invert)

            rdev->ena_gpio_state = !rdev->ena_gpio_state;

    }

  

    /* set regulator constraints */

    if (init_data)

        constraints = &init_data->constraints;

  

    ret = set_machine_constraints(rdev, constraints);

    if (ret < 0)

        goto scrub;

  

    /* add attributes supported by this regulator */

    ret = add_regulator_attributes(rdev);

    if (ret < 0)

        goto scrub;

  

    if (init_data && init_data->supply_regulator)

        supply = init_data->supply_regulator;

    else if (regulator_desc->supply_name)

        supply = regulator_desc->supply_name;

  

    if (supply) {

        struct regulator_dev *r;

  

        r = regulator_dev_lookup(dev, supply, &ret);

  

        if (ret == -ENODEV) {

            /*

             * No supply was specified for this regulator and

             * there will never be one.

             */

            ret = 0;

            goto add_dev;

        } else if (!r) {

            dev_err(dev, "Failed to find supply %s\n", supply);

            ret = -EPROBE_DEFER;

            goto scrub;

        }

  

        ret = set_supply(rdev, r);

        if (ret < 0)

            goto scrub;

  

        /* Enable supply if rail is enabled */

        if (_regulator_is_enabled(rdev)) {

            ret = regulator_enable(rdev->supply);

            if (ret < 0)

                goto scrub;

        }

    }

  

add_dev:

    /* add consumers devices */

    if (init_data) {

        for (i = 0; i < init_data->num_consumer_supplies; i++) {

            ret = set_consumer_device_supply(rdev,

                init_data->consumer_supplies[i].dev_name,

                init_data->consumer_supplies[i].supply);

            if (ret < 0) {

                dev_err(dev, "Failed to set supply %s\n",

                    init_data->consumer_supplies[i].supply);

                goto unset_supplies;

            }

        }

    }

  

    list_add(&rdev->list, ®ulator_list);

  

    rdev_init_debugfs(rdev);

out:

    mutex_unlock(®ulator_list_mutex);

    return rdev;

  

unset_supplies:

    unset_regulator_supplies(rdev);

  

scrub:

    if (rdev->supply)

        _regulator_put(rdev->supply);

    regulator_ena_gpio_free(rdev);

    kfree(rdev->constraints);

wash:

    device_unregister(&rdev->dev);

    /* device core frees rdev */

    rdev = ERR_PTR(ret);

    goto out;

  

clean:

    kfree(rdev);

    rdev = ERR_PTR(ret);

    goto out;

}

EXPORT_SYMBOL_GPL(regulator_register);

主要工作包括：

22~49，检查参数的合法性。其中35~49行，涉及到电压控制的方式，后面后详细说明；

55~60，协助从DTS解析init data，如果解析不到，则使用config中的；

68~73，协助获取regulator的register map（有的话），并保存在register device指针中。regulator driver会在需要的时候使用（通常是在ops回调函数中）；

74~77，初始化一些全局变量，consumer_list用于保存所有的consumer，list用于将自己添加到一个全局的regulator链表（regulator_list）上，disable_work是用于disable regulator的work queue；

86~95，将regulator device注册到kernel；

99~112，申请regulator enable gpio（有的话），并将相应的信息保存在regulator device指针中；

114~120，将从DTS中解析的constraints，应用起来（这个过程比较复杂，就不介绍了，感兴趣的读者可以自行分析）；

123，根据regulator的操作函数集，注册相应的attribute（和PSY class类似）；

127~160，如果该regulator有supply，根据supply的名字，获取相应的regulator device指针，同时根据supply指针，分配一个struct regulator结构，保存在该regulator的supply指针中。最后，如果该regulator处于使能状态，则需要使能其supply（这些动作，需要以consumer的视角操作，因而需要一个struct regulator变量）；

162~175，add consumer devices，等到介绍consumer时，再详细描述。

注4：register map是kernel提供的一种管理寄存器的机制，特别是较为复杂的寄存器，如codec等。本文不会过多描述，如需要，会专门写一篇文章介绍该机制。

5.3 regulator的操作模式（operation mode）

regulator的主要功能，是输出电压/电流的调整（或改变）。由于模拟器件的特性，电压/电流的改变，是需要一定的时间的。对有些regulator而言，可以工作在不同的模式，这些模式有不同的改变速度，可想而知，较快的速度，有较大的功耗。下面是operation mode定义（位于include/linux/regulator/consumer.h中）：

       1: /*

       2:  * Regulator operating modes.

       3:  *

       4:  * Regulators can run in a variety of different operating modes depending on

       5:  * output load. This allows further system power savings by selecting the

       6:  * best (and most efficient) regulator mode for a desired load.

       7:  *

       8:  * Most drivers will only care about NORMAL. The modes below are generic and

       9:  * will probably not match the naming convention of your regulator data sheet

 * but should match the use cases in the datasheet.

 *

 * In order of power efficiency (least efficient at top).

 *

 *  Mode       Description

 *  FAST       Regulator can handle fast changes in it's load.

 *             e.g. useful in CPU voltage & frequency scaling where

 *             load can quickly increase with CPU frequency increases.

 *

 *  NORMAL     Normal regulator power supply mode. Most drivers will

 *             use this mode.

 *

 *  IDLE       Regulator runs in a more efficient mode for light

 *             loads. Can be used for devices that have a low power

 *             requirement during periods of inactivity. This mode

 *             may be more noisy than NORMAL and may not be able

 *             to handle fast load switching.

 *

 *  STANDBY    Regulator runs in the most efficient mode for very

 *             light loads. Can be used by devices when they are

 *             in a sleep/standby state. This mode is likely to be

 *             the most noisy and may not be able to handle fast load

 *             switching.

 *

 * NOTE: Most regulators will only support a subset of these modes. Some

 * will only just support NORMAL.

 *

 * These modes can be OR'ed together to make up a mask of valid register modes.

 */

  

#define REGULATOR_MODE_FAST                     0x1

#define REGULATOR_MODE_NORMAL                   0x2

#define REGULATOR_MODE_IDLE                     0x4

#define REGULATOR_MODE_STANDBY                  0x8

相应的，regulator framework提供了一些机制，用于operation mode的操作，包括：

1）struct regulation_constraints中用于表示初始模式的字段initial_mode。

2）regulator ops中的set_mode/get_mode回调函数。

5.4 电压操作的两种方式

kernel抽象了两种电压操作的方法：

1）直接操作电压，对应struct regulator_ops中的如下回调函数：

       1: /* get/set regulator voltage */

       2: int (*list_voltage) (struct regulator_dev *, unsigned selector);

       3: int (*set_voltage) (struct regulator_dev *, int min_uV, int max_uV,

       4:                     unsigned *selector);

       5: int (*get_voltage) (struct regulator_dev *);

其中set_voltage用于将电压设置为min_uV和max_uV范围内、和min_uV最接近的电压。该接口可以返回一个selector参数，用于告知调用者，实际的电压值；

get_voltage，用于返回当前的电压值；

list_voltage，以selector为参数，获取对应的电压值。

注5：有关selector的描述，可参考下面的介绍。

2）selector的形式

regulator driver以selector的形式，反映电压值。selector是一个从0开始的整数，driver提供如下的接口：

       1: /* enumerate supported voltages */

       2: int (*list_voltage) (struct regulator_dev *, unsigned selector);

       3:  

       4: int (*map_voltage)(struct regulator_dev *, int min_uV, int max_uV);

       5: int (*set_voltage_sel) (struct regulator_dev *, unsigned selector);

       6: int (*get_voltage_sel) (struct regulator_dev *);

list_voltage，上面已经介绍；

map_voltage，是和list_voltage相对的接口，用于将电压范围map成一个selector值；

set_voltage_sel/get_voltage_sel，以selector的形式，操作电压。

regulator driver可以根据实际情况，选择一种实现方式。

5.5 regulator framework提供的sysfs接口

根据regulator提供的ops情况，regulator framework可以通过sysfs提供多种attribute，它们位于/sys/class/regulator/.../目录下，数量相当多，这里就不一一描述了，具体可参考：

https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-regulator

6. 后记

这篇文章写的相当纠结，相当混乱，我相信读者很难看懂……

本以为会很容易写，但里面的知识点太零碎了，以至于无法很好的归纳、抽象、突出重点。崩溃！

时间原因，就先这样了，有机会再回头来整理，希望读者谅解。

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

标签: Linux driver framework regulator

« spin_lock最简单用法。 | linux usb 摄像头测试»

评论：

小学生
2020-02-14 17:32

hi wowo，
请问regulator-min-microamp可以等于0吗？内核代码中machine_constraints_voltage()中，cmin = constraints->min_uV,下面函数有个判断if(cmin<=0 || cmax<=0 || cmax<cmin)->return -EINVAL，

tiem
2018-01-18 10:36

@wowo:
有个疑问能否解答一下：
如果app打开了某个LDO（比如camera app），如果没来得及退出就crash了，那么LDO怎么释放？

Thanks.

xyaw
2017-09-27 17:44

你好
我想請教:
1.
/sys/class/regulator/regulator.14 # ls

device         min_microvolts of_node   suspend_disk_state    type
max_microvolts name           power     suspend_mem_state     uevent
microvolts     num_users      subsystem suspend_standby_state

我在此沒有看到regulator_ops (我想調整電壓 set_voltage_sel/ set_voltage)相關的東西
請問要enable是regular定義時候要加什麼參數?

wowo
2017-09-27 18:49

@xyaw：實際上，regulator framework提供的sysfs api都是readonly的。
這也很好理解：register framework的consumer大部分都是kernel space的其它driver，需要由usersapce軟體直接控制的可能性比較小。
不過，可能小並不代表沒有可能，如果真有這樣的需求，也是有解決方法的：使用userspace consumer（drivers/regulator/userspace-consumer.c）。這其實是一個簡單的驅動程式，可以把需要由userspace軟體控制的regulator開放給userspace（可以簡單的enable、disable），kernel中有相應的例子，例如arch/arm/mach-pxa/em-x270.c，供你參考。
最後，如果實在不想使用已有的框架，你完全可以自己寫一個driver，將需要由userspace控制regulator導出，至於格式嘛，完全取決於您咯～～

xingxing.wang
2017-06-30 17:51

Hi Wowo:
您说的struct regulator_ops里面的所有回调由regulator core统一管控，能否讲解一下具体的实现方式，regulator core是主动调节还是被动调节的？感谢。

wowo
2017-07-03 08:40

@xingxing.wang：一般情况下都是被动调用（core不会自作主张），实现方式，你可以参考这篇文章（http://www.wowotech.net/pm_subsystem/regulator_framework_overview.html）然后对着代码看看（细节的东西，不是一句两句话能说明白的，见谅）。

cym
2016-03-14 13:35

hi wowo
请问下是否知道voltage tolerance是什么意思呢？？

wowo
2016-03-14 14:00

@cym：我的理解是：
假如系统中某个器件（例如CPU），要求一个1.8v的供电。但是，基于电压转换电路（通常是PMU）的特性，不可能输出一个精确的、误差为0的、1.8v的电压。
于是PMU的设计者会问CPU的设计者，一定要1.8吗？多一点、少一点不行吗？
通常情况下，考虑到电源系统设计的难度，器件都会打个折扣，允许输入电压有一定的误差，例如正负10%，这个就叫做voltage tolerance。
如有不对的地方，还请高手指正。

cym
2016-03-14 14:03

@wowo：应该是这样的，多谢wowo大虾

cracker
2016-01-21 18:37

hi wowo：
  这两天看了retulator的文章，不知到下面我的理解是不是正确的：
  1：regulator和cpufreq都可以动态调节电压，但cpu在内核中是特殊的设备，所以对于普通的设备提供regulator机制，而cpu提供了cpufreq机制；
  2：regulator是linux的设备抽象，在注册regulator需要初始化真正的设备属性（regulator_config和regulator_desc），然后注册时将上面初始化的变量交给boss regulator_dev，并让boss和dev绑定；
  3：设备使用与其绑定的regulator时，通过regulator_get函数获取regulator，然后执行regulator_ops的各种回调；
  4：regulator_constraints（regulator_config）与cpufreq_policy;regulator_desc与regulator_driver在思想上是不是一样的呢？

wowo
2016-01-21 20:55

@cracker：不是这样的，regulator和cpufreq是两个事情，没有可比性，具体可参考这个图片：http://www.wowotech.net/content/uploadfile/201506/a4cf6b6a89f45ea76d69dcb9ea0738c720150613141951.gif

passerby
2016-03-17 10:50

@wowo：我理解cpufreq和requlator是分开的，但也有联系。不同的cpufreq的CPU的性能不同，cpufreq高的时候，功耗相应的就大，所以就需要requlator调高CPU电压，以保证CPU有足够的POWER稳定的运行。所以一般CPU都会有一个cpufreq和voltage的对应表，DVFS就是按照这个对应表来调节频率和这个频率对应的电压。不知道我这样理解的对不对？

wowo
2016-03-17 13:34

@passerby：regulator framework只是一个调整电压的工具（无论是CPU的电压还是其它模块的电压），他和clock framework位于一个level。你和上面cracker同学说的都没有问题，但我整不明白的是：
大家理解一个东西的时候，为什么要和其它东西缠绕在一起？
例如理解regulator framework的时候，为什么会想到cpufreq？
而理解cpufreq framework的时候，为什么这么纠结regulator和clock？把这二位当作一个工具就ok了，重点还是要看cpufreq framework的设计思想。

cracker
2016-01-19 17:55

hi wowo
之前学习cpufreq了解是它主动获取cpu工作繁忙程度，实现动态调频。请问regulator如何知道设备是否在用或者是否suspend？

wowo
2016-01-19 18:37

@cracker：regulator只是一个工具，就像一把刀一样，无论让它砍谁，敌人、友军还是自己，它都执行。因此是否suspend，regulator不会关心，需要关心的是使用regulator的driver。
至于regulator driver本身，只需要保证其启动顺序（包括resume顺序）在其它正常的driver之前即可。

tigger
2015-04-27 14:30

为什么第一张图里面，他们用几个器件来提供regular，而不是合成一个呢？
降压控制器（TI tps51632），该控制器输出名称为“vdd-cpu”
是因为vdd-cpu需要特别稳定还是？不知道wowo思考过没有

wowo
2015-04-27 15:40

@tigger：这里面有几个考量：
1. 可配置性。
这个例子，是Tegra的一个开发板，所谓的开发板，需要满足不同类型的产品需求，这些产品所需的电源域的多少可能千差万别（对芯片厂而言，会经常遇到这样的问题）。因此需要可以灵活配置。
2. 体积、功耗和发热。
如果把所有的regulator都集成在一个片子中，会不会发热很严重？如果分开，会不会增大体积？等等。
话又说回来，这只是一个开发板，如果使用这个片子做产品的时候，设计者可能会考虑不同的方案。
3. 灵活的可控性。
对vdd-cpu而言，我猜“更稳定”不是主要的考量因素，因为稳定很容易做到。反而需要重点考虑的是：每个模块的regulator调整，不会影响其它模块。一个模块一个regulator最好，但代价太大。退而求其次，重点照顾CPU吧。

tigger
2015-04-27 14:26

hi wowo
最开始一张图
vdd与dcdc 这样描述是为什么？
还有vdd 跟avdd 数字/模拟怎么理解呢？有什么不同呢？

蜗蜗
2015-04-27 14:55

@tigger：这是我根据它的DTS抄出来的，我的理解是：
VDD和DCDC，表示这两个电压，是由两类不同类型的regulator器件输出的，LDO和DC/DC。LDO噪声小，但输出效率低；DC/DC输出效率高，但噪声大。
对于VDD和AVDD，是电路布线上的一种考虑，尽量将数字电路（CPU、MEM等）和模拟电路（Audio等）在电源域上隔离开（当然，不可能完全隔离，最终还是要共地），以减少干扰。

tigger
2015-04-27 15:30

@蜗蜗：有道理

tigger
2015-04-27 14:13

我有个疑问
比如tegra，他们把他们的充电参数放到了哪里呢？
没看到放到dts里面

蜗蜗
2015-04-27 14:54

@tigger：这和具体的版型有关，我们需要知道确切的版型，才能去找。总体来说，无外乎两个地方：DTS和代码中。另外Tegra的DTS文件很多，通过include包含起来了，可能你没有找到。

1 2

发表评论：

蜗窝科技

慢下来，享受技术。