diff options
Diffstat (limited to 'Documentation/power/regulator')
-rw-r--r-- | Documentation/power/regulator/machine.txt | 140 | ||||
-rw-r--r-- | Documentation/power/regulator/regulator.txt | 8 |
2 files changed, 70 insertions, 78 deletions
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index c9a35665cf70..ce3487d99abe 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt | |||
@@ -2,17 +2,8 @@ Regulator Machine Driver Interface | |||
2 | =================================== | 2 | =================================== |
3 | 3 | ||
4 | The regulator machine driver interface is intended for board/machine specific | 4 | The regulator machine driver interface is intended for board/machine specific |
5 | initialisation code to configure the regulator subsystem. Typical things that | 5 | initialisation code to configure the regulator subsystem. |
6 | machine drivers would do are :- | ||
7 | 6 | ||
8 | 1. Regulator -> Device mapping. | ||
9 | 2. Regulator supply configuration. | ||
10 | 3. Power Domain constraint setting. | ||
11 | |||
12 | |||
13 | |||
14 | 1. Regulator -> device mapping | ||
15 | ============================== | ||
16 | Consider the following machine :- | 7 | Consider the following machine :- |
17 | 8 | ||
18 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | 9 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] |
@@ -21,81 +12,82 @@ Consider the following machine :- | |||
21 | 12 | ||
22 | The drivers for consumers A & B must be mapped to the correct regulator in | 13 | The drivers for consumers A & B must be mapped to the correct regulator in |
23 | order to control their power supply. This mapping can be achieved in machine | 14 | order to control their power supply. This mapping can be achieved in machine |
24 | initialisation code by calling :- | 15 | initialisation code by creating a struct regulator_consumer_supply for |
16 | each regulator. | ||
17 | |||
18 | struct regulator_consumer_supply { | ||
19 | struct device *dev; /* consumer */ | ||
20 | const char *supply; /* consumer supply - e.g. "vcc" */ | ||
21 | }; | ||
25 | 22 | ||
26 | int regulator_set_device_supply(const char *regulator, struct device *dev, | 23 | e.g. for the machine above |
27 | const char *supply); | ||
28 | 24 | ||
29 | and is shown with the following code :- | 25 | static struct regulator_consumer_supply regulator1_consumers[] = { |
26 | { | ||
27 | .dev = &platform_consumerB_device.dev, | ||
28 | .supply = "Vcc", | ||
29 | },}; | ||
30 | 30 | ||
31 | regulator_set_device_supply("Regulator-1", devB, "Vcc"); | 31 | static struct regulator_consumer_supply regulator2_consumers[] = { |
32 | regulator_set_device_supply("Regulator-2", devA, "Vcc"); | 32 | { |
33 | .dev = &platform_consumerA_device.dev, | ||
34 | .supply = "Vcc", | ||
35 | },}; | ||
33 | 36 | ||
34 | This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2 | 37 | This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2 |
35 | to the 'Vcc' supply for Consumer A. | 38 | to the 'Vcc' supply for Consumer A. |
36 | 39 | ||
37 | 40 | Constraints can now be registered by defining a struct regulator_init_data | |
38 | 2. Regulator supply configuration. | 41 | for each regulator power domain. This structure also maps the consumers |
39 | ================================== | 42 | to their supply regulator :- |
40 | Consider the following machine (again) :- | 43 | |
41 | 44 | static struct regulator_init_data regulator1_data = { | |
42 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | 45 | .constraints = { |
43 | | | 46 | .min_uV = 3300000, |
44 | +-> [Consumer B @ 3.3V] | 47 | .max_uV = 3300000, |
48 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | ||
49 | }, | ||
50 | .num_consumer_supplies = ARRAY_SIZE(regulator1_consumers), | ||
51 | .consumer_supplies = regulator1_consumers, | ||
52 | }; | ||
45 | 53 | ||
46 | Regulator-1 supplies power to Regulator-2. This relationship must be registered | 54 | Regulator-1 supplies power to Regulator-2. This relationship must be registered |
47 | with the core so that Regulator-1 is also enabled when Consumer A enables it's | 55 | with the core so that Regulator-1 is also enabled when Consumer A enables it's |
48 | supply (Regulator-2). | 56 | supply (Regulator-2). The supply regulator is set by the supply_regulator_dev |
49 | 57 | field below:- | |
50 | This relationship can be register with the core via :- | 58 | |
51 | 59 | static struct regulator_init_data regulator2_data = { | |
52 | int regulator_set_supply(const char *regulator, const char *regulator_supply); | 60 | .supply_regulator_dev = &platform_regulator1_device.dev, |
53 | 61 | .constraints = { | |
54 | In this example we would use the following code :- | 62 | .min_uV = 1800000, |
55 | 63 | .max_uV = 2000000, | |
56 | regulator_set_supply("Regulator-2", "Regulator-1"); | 64 | .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE, |
57 | 65 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | |
58 | Relationships can be queried by calling :- | 66 | }, |
59 | 67 | .num_consumer_supplies = ARRAY_SIZE(regulator2_consumers), | |
60 | const char *regulator_get_supply(const char *regulator); | 68 | .consumer_supplies = regulator2_consumers, |
61 | |||
62 | |||
63 | 3. Power Domain constraint setting. | ||
64 | =================================== | ||
65 | Each power domain within a system has physical constraints on voltage and | ||
66 | current. This must be defined in software so that the power domain is always | ||
67 | operated within specifications. | ||
68 | |||
69 | Consider the following machine (again) :- | ||
70 | |||
71 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
72 | | | ||
73 | +-> [Consumer B @ 3.3V] | ||
74 | |||
75 | This gives us two regulators and two power domains: | ||
76 | |||
77 | Domain 1: Regulator-2, Consumer B. | ||
78 | Domain 2: Consumer A. | ||
79 | |||
80 | Constraints can be registered by calling :- | ||
81 | |||
82 | int regulator_set_platform_constraints(const char *regulator, | ||
83 | struct regulation_constraints *constraints); | ||
84 | |||
85 | The example is defined as follows :- | ||
86 | |||
87 | struct regulation_constraints domain_1 = { | ||
88 | .min_uV = 3300000, | ||
89 | .max_uV = 3300000, | ||
90 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | ||
91 | }; | 69 | }; |
92 | 70 | ||
93 | struct regulation_constraints domain_2 = { | 71 | Finally the regulator devices must be registered in the usual manner. |
94 | .min_uV = 1800000, | 72 | |
95 | .max_uV = 2000000, | 73 | static struct platform_device regulator_devices[] = { |
96 | .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE, | 74 | { |
97 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | 75 | .name = "regulator", |
76 | .id = DCDC_1, | ||
77 | .dev = { | ||
78 | .platform_data = ®ulator1_data, | ||
79 | }, | ||
80 | }, | ||
81 | { | ||
82 | .name = "regulator", | ||
83 | .id = DCDC_2, | ||
84 | .dev = { | ||
85 | .platform_data = ®ulator2_data, | ||
86 | }, | ||
87 | }, | ||
98 | }; | 88 | }; |
89 | /* register regulator 1 device */ | ||
90 | platform_device_register(&wm8350_regulator_devices[0]); | ||
99 | 91 | ||
100 | regulator_set_platform_constraints("Regulator-1", &domain_1); | 92 | /* register regulator 2 device */ |
101 | regulator_set_platform_constraints("Regulator-2", &domain_2); | 93 | platform_device_register(&wm8350_regulator_devices[1]); |
diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt index a69050143592..4200accb9bba 100644 --- a/Documentation/power/regulator/regulator.txt +++ b/Documentation/power/regulator/regulator.txt | |||
@@ -10,11 +10,11 @@ Registration | |||
10 | 10 | ||
11 | Drivers can register a regulator by calling :- | 11 | Drivers can register a regulator by calling :- |
12 | 12 | ||
13 | struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, | 13 | struct regulator_dev *regulator_register(struct device *dev, |
14 | void *reg_data); | 14 | struct regulator_desc *regulator_desc); |
15 | 15 | ||
16 | This will register the regulators capabilities and operations the regulator | 16 | This will register the regulators capabilities and operations to the regulator |
17 | core. The core does not touch reg_data (private to regulator driver). | 17 | core. |
18 | 18 | ||
19 | Regulators can be unregistered by calling :- | 19 | Regulators can be unregistered by calling :- |
20 | 20 | ||