轉自蝸窩科技：http://www.wowotech.net/pm_subsystem/regulator_driver.html

說實話，這篇好難懂啊。。。

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等等。

這些思考在本文的例子（NVIDIA Tegra Dalmore A04的regulator）中體現尤為突出，它的本質是軟體設計中的模組劃分，從而決定了regulator在DTS中的呈現方式和層次。

2.2 使用DTS，將硬體拓撲呈現出來

1）tps51632（是一種電源管理模組）

tps51632是一個簡單的器件，位於i2c匯流排下面，包含一個regulator器件，因此其DTS比較簡單，如下：

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

   : i2c@7000d000 {

   :         status = "okay";

   :         clock-frequency = <>;

   :

   :         tps51632@ {

   :                 compatible = "ti,tps51632";

   :                 reg = <0x43>;

   :                 regulator-name = "vdd-cpu";

  :                 regulator-min-microvolt = <>;

  :                 regulator-max-microvolt = <>;

  :                 regulator-boot-on;

  :                 regulator-always-on;

  :         };

  :         ...

  : }

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怎麼寫的：

   : i2c@7000d000 {

   :         status = "okay";

   :         ...

   :

   :         tps65090@ {

   :                 compatible = "ti,tps65090";

   :                 reg = <0x48>;

   :                 ...

   :

  :                 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。

3）tps65913，和tps65090類似，不再介紹。

4）CPU中的regulator

這一類regulator比較特殊，直接整合在CPU內部，DTS如下：

   : regulators {

   :         compatible = "simple-bus";

   :         #address-cells = <>;

   :         #size-cells = <>;

   :

   :         vdd_ac_bat_reg: regulator@ {

   :                 compatible = "regulator-fixed";

   :                 reg = <>;

   :                 regulator-name = "vdd_ac_bat";

  :                 regulator-min-microvolt = <>;

  :                 regulator-max-microvolt = <>;

  :                 regulator-always-on;

  :         };

  :

  :         dvdd_ts_reg: regulator@ {

  :                 compatible = "regulator-fixed";

  :                 reg = <>;

  :                 regulator-name = "dvdd_ts";

  :                 regulator-min-microvolt = <>;

  :                 regulator-max-microvolt = <>;

  :                 enable-active-high;

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

  :         };

  :         ...

  : };

在回到剛才的話題上，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：

   : /**

   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:  */

  : struct regulator_init_data {

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

  :

  :         struct regulation_constraints constraints;

  :

  :         int num_consumer_supplies;

  :         struct regulator_consumer_supply *consumer_supplies;

  :

  :         /* optional regulator machine specific init */

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

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

  : };

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所有的物理限制，如下：

   : struct regulation_constraints {

   :

   :         const char *name;

   :

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

   :         int min_uV;

   :         int max_uV;

   :

   :         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:;   /* regulator never off when system is on */

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

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

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

  : };

3.2 DTS的解析

regulator的DTS資訊，可以通過兩種方法解析：

1）在regulator註冊前，呼叫of_get_regulator_init_data介面自行解析，該介面的實現如下：

   : struct regulator_init_data *of_get_regulator_init_data(struct device *dev,

   :                                                 struct device_node *node)

   : {

   :         struct regulator_init_data *init_data;

   :

   :         if (!node)

   :                 return NULL;

   :

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

  :         if (!init_data)

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

  :

  :         of_get_regulation_constraints(node, &init_data);

  :         return init_data;

  : }

  : 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幫忙解析，該介面的實現如下：

   : struct regulator_init_data *regulator_of_get_init_data(struct device *dev,

   :                                             const struct regulator_desc *desc,

   :                                             struct device_node **node)

   : {

   :         struct device_node *search, *child;

   :         struct regulator_init_data *init_data = NULL;

   :         const char *name;

   :

   :         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

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

   :

   : struct regulator_desc {

   :         const char *name;

   :         const char *supply_name;

   :         const char *of_match;

   :         const char *regulators_node;

   :         int id;

   :         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;

  : };

4.2 struct regulator_config

 struct regulator_config儲存了regulator的動態資訊，所謂的動態資訊，是指那些會在driver執行過程中改變、或者driver執行後才會確定的資訊，如下：

   : struct regulator_config {

   :         struct device *dev;

   :         const struct regulator_init_data *init_data;

   :         void *driver_data;

   :         struct device_node *of_node;

   :         struct regmap *regmap;

   :

   :         int ena_gpio;

   :         unsigned int ena_gpio_invert:;

  :         unsigned int ena_gpio_flags;

  : };

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操作，都將以該變數為物件。

   : struct regulator_dev {

   :         const struct regulator_desc *desc;

   :         int exclusive;

   :         u32 use_count;

   :         u32 open_count;

   :         u32 bypass_count;

   :

   :         /* lists we belong to */

   :         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:;

  :

  :         /* 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介面負責，如下：

   : /**

   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();

  :     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 < )

  :             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) - );

  :     ret = device_register(&rdev->dev);

  :     if (ret != ) {

  :         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 != ) {

 :             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 = ;

 :

 :         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 < )

 :         goto scrub;

 :

 :     /* add attributes supported by this regulator */

 :     ret = add_regulator_attributes(rdev);

 :     if (ret < )

 :         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) {

 :             /*

 139:              * No supply was specified for this regulator and

 140:              * there will never be one.

 141:              */

 :             ret = ;

 :             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 < )

 :             goto scrub;

 :

 :         /* Enable supply if rail is enabled */

 :         if (_regulator_is_enabled(rdev)) {

 :             ret = regulator_enable(rdev->supply);

 :             if (ret < )

 :                 goto scrub;

 :         }

 :     }

 :

 : add_dev:

 :     /* add consumers devices */

 :     if (init_data) {

 :         for (i = ; 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 < ) {

 :                 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中）：

   : /*

   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

  10:  * but should match the use cases in the datasheet.

  11:  *

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

  13:  *

  14:  *  Mode       Description

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

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

  17:  *             load can quickly increase with CPU frequency increases.

  18:  *

  19:  *  NORMAL     Normal regulator power supply mode. Most drivers will

  20:  *             use this mode.

  21:  *

  22:  *  IDLE       Regulator runs in a more efficient mode for light

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

  24:  *             requirement during periods of inactivity. This mode

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

  26:  *             to handle fast load switching.

  27:  *

  28:  *  STANDBY    Regulator runs in the most efficient mode for very

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

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

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

  32:  *             switching.

  33:  *

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

  35:  * will only just support NORMAL.

  36:  *

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

  38:  */

  :

  : #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中的如下回調函式：

   : /* get/set regulator voltage */

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

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

   :                     unsigned *selector);

   : 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提供如下的介面：

   : /* enumerate supported voltages */

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

   :

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

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

   : 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. 後記

這篇文章寫的相當糾結，相當混亂，我相信讀者很難看懂……