diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2008-08-01 13:56:40 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-08-01 13:56:40 -0400 |
commit | 561b35b341b1aeeab486affe1ede0ee6640ce33b (patch) | |
tree | a7570737884bef3c15db98cae629a82ce3586b3c /Documentation | |
parent | a7c2a10dab4e5122cbcfa3d5e9d589a52ccc2287 (diff) | |
parent | 0eb5d5ab3ec99bfd22ff16797d95835369ffb25b (diff) |
Merge branch 'reg-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6
* 'reg-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6:
regulator: TI bq24022 Li-Ion Charger driver
regulator: maintainers - add maintainers for regulator framework.
regulator: documentation - ABI
regulator: documentation - machine
regulator: documentation - regulator driver
regulator: documentation - consumer interface
regulator: documentation - overview
regulator: core kbuild files
regulator: regulator test harness
regulator: add support for fixed regulators.
regulator: regulator framework core
regulator: fixed regulator interface
regulator: machine driver interface
regulator: regulator driver interface
regulator: consumer device interface
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/ABI/testing/sysfs-class-regulator | 315 | ||||
-rw-r--r-- | Documentation/power/regulator/consumer.txt | 182 | ||||
-rw-r--r-- | Documentation/power/regulator/machine.txt | 101 | ||||
-rw-r--r-- | Documentation/power/regulator/overview.txt | 171 | ||||
-rw-r--r-- | Documentation/power/regulator/regulator.txt | 30 |
5 files changed, 799 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-regulator b/Documentation/ABI/testing/sysfs-class-regulator new file mode 100644 index 00000000000..79a4a75b2d2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-regulator | |||
@@ -0,0 +1,315 @@ | |||
1 | What: /sys/class/regulator/.../state | ||
2 | Date: April 2008 | ||
3 | KernelVersion: 2.6.26 | ||
4 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
5 | Description: | ||
6 | Each regulator directory will contain a field called | ||
7 | state. This holds the regulator output state. | ||
8 | |||
9 | This will be one of the following strings: | ||
10 | |||
11 | 'enabled' | ||
12 | 'disabled' | ||
13 | 'unknown' | ||
14 | |||
15 | 'enabled' means the regulator output is ON and is supplying | ||
16 | power to the system. | ||
17 | |||
18 | 'disabled' means the regulator output is OFF and is not | ||
19 | supplying power to the system.. | ||
20 | |||
21 | 'unknown' means software cannot determine the state. | ||
22 | |||
23 | NOTE: this field can be used in conjunction with microvolts | ||
24 | and microamps to determine regulator output levels. | ||
25 | |||
26 | |||
27 | What: /sys/class/regulator/.../type | ||
28 | Date: April 2008 | ||
29 | KernelVersion: 2.6.26 | ||
30 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
31 | Description: | ||
32 | Each regulator directory will contain a field called | ||
33 | type. This holds the regulator type. | ||
34 | |||
35 | This will be one of the following strings: | ||
36 | |||
37 | 'voltage' | ||
38 | 'current' | ||
39 | 'unknown' | ||
40 | |||
41 | 'voltage' means the regulator output voltage can be controlled | ||
42 | by software. | ||
43 | |||
44 | 'current' means the regulator output current limit can be | ||
45 | controlled by software. | ||
46 | |||
47 | 'unknown' means software cannot control either voltage or | ||
48 | current limit. | ||
49 | |||
50 | |||
51 | What: /sys/class/regulator/.../microvolts | ||
52 | Date: April 2008 | ||
53 | KernelVersion: 2.6.26 | ||
54 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
55 | Description: | ||
56 | Each regulator directory will contain a field called | ||
57 | microvolts. This holds the regulator output voltage setting | ||
58 | measured in microvolts (i.e. E-6 Volts). | ||
59 | |||
60 | NOTE: This value should not be used to determine the regulator | ||
61 | output voltage level as this value is the same regardless of | ||
62 | whether the regulator is enabled or disabled. | ||
63 | |||
64 | |||
65 | What: /sys/class/regulator/.../microamps | ||
66 | Date: April 2008 | ||
67 | KernelVersion: 2.6.26 | ||
68 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
69 | Description: | ||
70 | Each regulator directory will contain a field called | ||
71 | microamps. This holds the regulator output current limit | ||
72 | setting measured in microamps (i.e. E-6 Amps). | ||
73 | |||
74 | NOTE: This value should not be used to determine the regulator | ||
75 | output current level as this value is the same regardless of | ||
76 | whether the regulator is enabled or disabled. | ||
77 | |||
78 | |||
79 | What: /sys/class/regulator/.../opmode | ||
80 | Date: April 2008 | ||
81 | KernelVersion: 2.6.26 | ||
82 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
83 | Description: | ||
84 | Each regulator directory will contain a field called | ||
85 | opmode. This holds the regulator operating mode setting. | ||
86 | |||
87 | The opmode value can be one of the following strings: | ||
88 | |||
89 | 'fast' | ||
90 | 'normal' | ||
91 | 'idle' | ||
92 | 'standby' | ||
93 | 'unknown' | ||
94 | |||
95 | The modes are described in include/linux/regulator/regulator.h | ||
96 | |||
97 | NOTE: This value should not be used to determine the regulator | ||
98 | output operating mode as this value is the same regardless of | ||
99 | whether the regulator is enabled or disabled. | ||
100 | |||
101 | |||
102 | What: /sys/class/regulator/.../min_microvolts | ||
103 | Date: April 2008 | ||
104 | KernelVersion: 2.6.26 | ||
105 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
106 | Description: | ||
107 | Each regulator directory will contain a field called | ||
108 | min_microvolts. This holds the minimum safe working regulator | ||
109 | output voltage setting for this domain measured in microvolts. | ||
110 | |||
111 | NOTE: this will return the string 'constraint not defined' if | ||
112 | the power domain has no min microvolts constraint defined by | ||
113 | platform code. | ||
114 | |||
115 | |||
116 | What: /sys/class/regulator/.../max_microvolts | ||
117 | Date: April 2008 | ||
118 | KernelVersion: 2.6.26 | ||
119 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
120 | Description: | ||
121 | Each regulator directory will contain a field called | ||
122 | max_microvolts. This holds the maximum safe working regulator | ||
123 | output voltage setting for this domain measured in microvolts. | ||
124 | |||
125 | NOTE: this will return the string 'constraint not defined' if | ||
126 | the power domain has no max microvolts constraint defined by | ||
127 | platform code. | ||
128 | |||
129 | |||
130 | What: /sys/class/regulator/.../min_microamps | ||
131 | Date: April 2008 | ||
132 | KernelVersion: 2.6.26 | ||
133 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
134 | Description: | ||
135 | Each regulator directory will contain a field called | ||
136 | min_microamps. This holds the minimum safe working regulator | ||
137 | output current limit setting for this domain measured in | ||
138 | microamps. | ||
139 | |||
140 | NOTE: this will return the string 'constraint not defined' if | ||
141 | the power domain has no min microamps constraint defined by | ||
142 | platform code. | ||
143 | |||
144 | |||
145 | What: /sys/class/regulator/.../max_microamps | ||
146 | Date: April 2008 | ||
147 | KernelVersion: 2.6.26 | ||
148 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
149 | Description: | ||
150 | Each regulator directory will contain a field called | ||
151 | max_microamps. This holds the maximum safe working regulator | ||
152 | output current limit setting for this domain measured in | ||
153 | microamps. | ||
154 | |||
155 | NOTE: this will return the string 'constraint not defined' if | ||
156 | the power domain has no max microamps constraint defined by | ||
157 | platform code. | ||
158 | |||
159 | |||
160 | What: /sys/class/regulator/.../num_users | ||
161 | Date: April 2008 | ||
162 | KernelVersion: 2.6.26 | ||
163 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
164 | Description: | ||
165 | Each regulator directory will contain a field called | ||
166 | num_users. This holds the number of consumer devices that | ||
167 | have called regulator_enable() on this regulator. | ||
168 | |||
169 | |||
170 | What: /sys/class/regulator/.../requested_microamps | ||
171 | Date: April 2008 | ||
172 | KernelVersion: 2.6.26 | ||
173 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
174 | Description: | ||
175 | Each regulator directory will contain a field called | ||
176 | requested_microamps. This holds the total requested load | ||
177 | current in microamps for this regulator from all its consumer | ||
178 | devices. | ||
179 | |||
180 | |||
181 | What: /sys/class/regulator/.../parent | ||
182 | Date: April 2008 | ||
183 | KernelVersion: 2.6.26 | ||
184 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
185 | Description: | ||
186 | Some regulator directories will contain a link called parent. | ||
187 | This points to the parent or supply regulator if one exists. | ||
188 | |||
189 | What: /sys/class/regulator/.../suspend_mem_microvolts | ||
190 | Date: May 2008 | ||
191 | KernelVersion: 2.6.26 | ||
192 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
193 | Description: | ||
194 | Each regulator directory will contain a field called | ||
195 | suspend_mem_microvolts. This holds the regulator output | ||
196 | voltage setting for this domain measured in microvolts when | ||
197 | the system is suspended to memory. | ||
198 | |||
199 | NOTE: this will return the string 'not defined' if | ||
200 | the power domain has no suspend to memory voltage defined by | ||
201 | platform code. | ||
202 | |||
203 | What: /sys/class/regulator/.../suspend_disk_microvolts | ||
204 | Date: May 2008 | ||
205 | KernelVersion: 2.6.26 | ||
206 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
207 | Description: | ||
208 | Each regulator directory will contain a field called | ||
209 | suspend_disk_microvolts. This holds the regulator output | ||
210 | voltage setting for this domain measured in microvolts when | ||
211 | the system is suspended to disk. | ||
212 | |||
213 | NOTE: this will return the string 'not defined' if | ||
214 | the power domain has no suspend to disk voltage defined by | ||
215 | platform code. | ||
216 | |||
217 | What: /sys/class/regulator/.../suspend_standby_microvolts | ||
218 | Date: May 2008 | ||
219 | KernelVersion: 2.6.26 | ||
220 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
221 | Description: | ||
222 | Each regulator directory will contain a field called | ||
223 | suspend_standby_microvolts. This holds the regulator output | ||
224 | voltage setting for this domain measured in microvolts when | ||
225 | the system is suspended to standby. | ||
226 | |||
227 | NOTE: this will return the string 'not defined' if | ||
228 | the power domain has no suspend to standby voltage defined by | ||
229 | platform code. | ||
230 | |||
231 | What: /sys/class/regulator/.../suspend_mem_mode | ||
232 | Date: May 2008 | ||
233 | KernelVersion: 2.6.26 | ||
234 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
235 | Description: | ||
236 | Each regulator directory will contain a field called | ||
237 | suspend_mem_mode. This holds the regulator operating mode | ||
238 | setting for this domain when the system is suspended to | ||
239 | memory. | ||
240 | |||
241 | NOTE: this will return the string 'not defined' if | ||
242 | the power domain has no suspend to memory mode defined by | ||
243 | platform code. | ||
244 | |||
245 | What: /sys/class/regulator/.../suspend_disk_mode | ||
246 | Date: May 2008 | ||
247 | KernelVersion: 2.6.26 | ||
248 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
249 | Description: | ||
250 | Each regulator directory will contain a field called | ||
251 | suspend_disk_mode. This holds the regulator operating mode | ||
252 | setting for this domain when the system is suspended to disk. | ||
253 | |||
254 | NOTE: this will return the string 'not defined' if | ||
255 | the power domain has no suspend to disk mode defined by | ||
256 | platform code. | ||
257 | |||
258 | What: /sys/class/regulator/.../suspend_standby_mode | ||
259 | Date: May 2008 | ||
260 | KernelVersion: 2.6.26 | ||
261 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
262 | Description: | ||
263 | Each regulator directory will contain a field called | ||
264 | suspend_standby_mode. This holds the regulator operating mode | ||
265 | setting for this domain when the system is suspended to | ||
266 | standby. | ||
267 | |||
268 | NOTE: this will return the string 'not defined' if | ||
269 | the power domain has no suspend to standby mode defined by | ||
270 | platform code. | ||
271 | |||
272 | What: /sys/class/regulator/.../suspend_mem_state | ||
273 | Date: May 2008 | ||
274 | KernelVersion: 2.6.26 | ||
275 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
276 | Description: | ||
277 | Each regulator directory will contain a field called | ||
278 | suspend_mem_state. This holds the regulator operating state | ||
279 | when suspended to memory. | ||
280 | |||
281 | This will be one of the following strings: | ||
282 | |||
283 | 'enabled' | ||
284 | 'disabled' | ||
285 | 'not defined' | ||
286 | |||
287 | What: /sys/class/regulator/.../suspend_disk_state | ||
288 | Date: May 2008 | ||
289 | KernelVersion: 2.6.26 | ||
290 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
291 | Description: | ||
292 | Each regulator directory will contain a field called | ||
293 | suspend_disk_state. This holds the regulator operating state | ||
294 | when suspended to disk. | ||
295 | |||
296 | This will be one of the following strings: | ||
297 | |||
298 | 'enabled' | ||
299 | 'disabled' | ||
300 | 'not defined' | ||
301 | |||
302 | What: /sys/class/regulator/.../suspend_standby_state | ||
303 | Date: May 2008 | ||
304 | KernelVersion: 2.6.26 | ||
305 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
306 | Description: | ||
307 | Each regulator directory will contain a field called | ||
308 | suspend_standby_state. This holds the regulator operating | ||
309 | state when suspended to standby. | ||
310 | |||
311 | This will be one of the following strings: | ||
312 | |||
313 | 'enabled' | ||
314 | 'disabled' | ||
315 | 'not defined' | ||
diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt new file mode 100644 index 00000000000..82b7a43aadb --- /dev/null +++ b/Documentation/power/regulator/consumer.txt | |||
@@ -0,0 +1,182 @@ | |||
1 | Regulator Consumer Driver Interface | ||
2 | =================================== | ||
3 | |||
4 | This text describes the regulator interface for consumer device drivers. | ||
5 | Please see overview.txt for a description of the terms used in this text. | ||
6 | |||
7 | |||
8 | 1. Consumer Regulator Access (static & dynamic drivers) | ||
9 | ======================================================= | ||
10 | |||
11 | A consumer driver can get access to it's supply regulator by calling :- | ||
12 | |||
13 | regulator = regulator_get(dev, "Vcc"); | ||
14 | |||
15 | The consumer passes in it's struct device pointer and power supply ID. The core | ||
16 | then finds the correct regulator by consulting a machine specific lookup table. | ||
17 | If the lookup is successful then this call will return a pointer to the struct | ||
18 | regulator that supplies this consumer. | ||
19 | |||
20 | To release the regulator the consumer driver should call :- | ||
21 | |||
22 | regulator_put(regulator); | ||
23 | |||
24 | Consumers can be supplied by more than one regulator e.g. codec consumer with | ||
25 | analog and digital supplies :- | ||
26 | |||
27 | digital = regulator_get(dev, "Vcc"); /* digital core */ | ||
28 | analog = regulator_get(dev, "Avdd"); /* analog */ | ||
29 | |||
30 | The regulator access functions regulator_get() and regulator_put() will | ||
31 | usually be called in your device drivers probe() and remove() respectively. | ||
32 | |||
33 | |||
34 | 2. Regulator Output Enable & Disable (static & dynamic drivers) | ||
35 | ==================================================================== | ||
36 | |||
37 | A consumer can enable it's power supply by calling:- | ||
38 | |||
39 | int regulator_enable(regulator); | ||
40 | |||
41 | NOTE: The supply may already be enabled before regulator_enabled() is called. | ||
42 | This may happen if the consumer shares the regulator or the regulator has been | ||
43 | previously enabled by bootloader or kernel board initialization code. | ||
44 | |||
45 | A consumer can determine if a regulator is enabled by calling :- | ||
46 | |||
47 | int regulator_is_enabled(regulator); | ||
48 | |||
49 | This will return > zero when the regulator is enabled. | ||
50 | |||
51 | |||
52 | A consumer can disable it's supply when no longer needed by calling :- | ||
53 | |||
54 | int regulator_disable(regulator); | ||
55 | |||
56 | NOTE: This may not disable the supply if it's shared with other consumers. The | ||
57 | regulator will only be disabled when the enabled reference count is zero. | ||
58 | |||
59 | Finally, a regulator can be forcefully disabled in the case of an emergency :- | ||
60 | |||
61 | int regulator_force_disable(regulator); | ||
62 | |||
63 | NOTE: this will immediately and forcefully shutdown the regulator output. All | ||
64 | consumers will be powered off. | ||
65 | |||
66 | |||
67 | 3. Regulator Voltage Control & Status (dynamic drivers) | ||
68 | ====================================================== | ||
69 | |||
70 | Some consumer drivers need to be able to dynamically change their supply | ||
71 | voltage to match system operating points. e.g. CPUfreq drivers can scale | ||
72 | voltage along with frequency to save power, SD drivers may need to select the | ||
73 | correct card voltage, etc. | ||
74 | |||
75 | Consumers can control their supply voltage by calling :- | ||
76 | |||
77 | int regulator_set_voltage(regulator, min_uV, max_uV); | ||
78 | |||
79 | Where min_uV and max_uV are the minimum and maximum acceptable voltages in | ||
80 | microvolts. | ||
81 | |||
82 | NOTE: this can be called when the regulator is enabled or disabled. If called | ||
83 | when enabled, then the voltage changes instantly, otherwise the voltage | ||
84 | configuration changes and the voltage is physically set when the regulator is | ||
85 | next enabled. | ||
86 | |||
87 | The regulators configured voltage output can be found by calling :- | ||
88 | |||
89 | int regulator_get_voltage(regulator); | ||
90 | |||
91 | NOTE: get_voltage() will return the configured output voltage whether the | ||
92 | regulator is enabled or disabled and should NOT be used to determine regulator | ||
93 | output state. However this can be used in conjunction with is_enabled() to | ||
94 | determine the regulator physical output voltage. | ||
95 | |||
96 | |||
97 | 4. Regulator Current Limit Control & Status (dynamic drivers) | ||
98 | =========================================================== | ||
99 | |||
100 | Some consumer drivers need to be able to dynamically change their supply | ||
101 | current limit to match system operating points. e.g. LCD backlight driver can | ||
102 | change the current limit to vary the backlight brightness, USB drivers may want | ||
103 | to set the limit to 500mA when supplying power. | ||
104 | |||
105 | Consumers can control their supply current limit by calling :- | ||
106 | |||
107 | int regulator_set_current_limit(regulator, min_uV, max_uV); | ||
108 | |||
109 | Where min_uA and max_uA are the minimum and maximum acceptable current limit in | ||
110 | microamps. | ||
111 | |||
112 | NOTE: this can be called when the regulator is enabled or disabled. If called | ||
113 | when enabled, then the current limit changes instantly, otherwise the current | ||
114 | limit configuration changes and the current limit is physically set when the | ||
115 | regulator is next enabled. | ||
116 | |||
117 | A regulators current limit can be found by calling :- | ||
118 | |||
119 | int regulator_get_current_limit(regulator); | ||
120 | |||
121 | NOTE: get_current_limit() will return the current limit whether the regulator | ||
122 | is enabled or disabled and should not be used to determine regulator current | ||
123 | load. | ||
124 | |||
125 | |||
126 | 5. Regulator Operating Mode Control & Status (dynamic drivers) | ||
127 | ============================================================= | ||
128 | |||
129 | Some consumers can further save system power by changing the operating mode of | ||
130 | their supply regulator to be more efficient when the consumers operating state | ||
131 | changes. e.g. consumer driver is idle and subsequently draws less current | ||
132 | |||
133 | Regulator operating mode can be changed indirectly or directly. | ||
134 | |||
135 | Indirect operating mode control. | ||
136 | -------------------------------- | ||
137 | Consumer drivers can request a change in their supply regulator operating mode | ||
138 | by calling :- | ||
139 | |||
140 | int regulator_set_optimum_mode(struct regulator *regulator, int load_uA); | ||
141 | |||
142 | This will cause the core to recalculate the total load on the regulator (based | ||
143 | on all it's consumers) and change operating mode (if necessary and permitted) | ||
144 | to best match the current operating load. | ||
145 | |||
146 | The load_uA value can be determined from the consumers datasheet. e.g.most | ||
147 | datasheets have tables showing the max current consumed in certain situations. | ||
148 | |||
149 | Most consumers will use indirect operating mode control since they have no | ||
150 | knowledge of the regulator or whether the regulator is shared with other | ||
151 | consumers. | ||
152 | |||
153 | Direct operating mode control. | ||
154 | ------------------------------ | ||
155 | Bespoke or tightly coupled drivers may want to directly control regulator | ||
156 | operating mode depending on their operating point. This can be achieved by | ||
157 | calling :- | ||
158 | |||
159 | int regulator_set_mode(struct regulator *regulator, unsigned int mode); | ||
160 | unsigned int regulator_get_mode(struct regulator *regulator); | ||
161 | |||
162 | Direct mode will only be used by consumers that *know* about the regulator and | ||
163 | are not sharing the regulator with other consumers. | ||
164 | |||
165 | |||
166 | 6. Regulator Events | ||
167 | =================== | ||
168 | Regulators can notify consumers of external events. Events could be received by | ||
169 | consumers under regulator stress or failure conditions. | ||
170 | |||
171 | Consumers can register interest in regulator events by calling :- | ||
172 | |||
173 | int regulator_register_notifier(struct regulator *regulator, | ||
174 | struct notifier_block *nb); | ||
175 | |||
176 | Consumers can uregister interest by calling :- | ||
177 | |||
178 | int regulator_unregister_notifier(struct regulator *regulator, | ||
179 | struct notifier_block *nb); | ||
180 | |||
181 | Regulators use the kernel notifier framework to send event to thier interested | ||
182 | consumers. | ||
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt new file mode 100644 index 00000000000..c9a35665cf7 --- /dev/null +++ b/Documentation/power/regulator/machine.txt | |||
@@ -0,0 +1,101 @@ | |||
1 | Regulator Machine Driver Interface | ||
2 | =================================== | ||
3 | |||
4 | The regulator machine driver interface is intended for board/machine specific | ||
5 | initialisation code to configure the regulator subsystem. Typical things that | ||
6 | machine drivers would do are :- | ||
7 | |||
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 :- | ||
17 | |||
18 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
19 | | | ||
20 | +-> [Consumer B @ 3.3V] | ||
21 | |||
22 | 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 | ||
24 | initialisation code by calling :- | ||
25 | |||
26 | int regulator_set_device_supply(const char *regulator, struct device *dev, | ||
27 | const char *supply); | ||
28 | |||
29 | and is shown with the following code :- | ||
30 | |||
31 | regulator_set_device_supply("Regulator-1", devB, "Vcc"); | ||
32 | regulator_set_device_supply("Regulator-2", devA, "Vcc"); | ||
33 | |||
34 | This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2 | ||
35 | to the 'Vcc' supply for Consumer A. | ||
36 | |||
37 | |||
38 | 2. Regulator supply configuration. | ||
39 | ================================== | ||
40 | Consider the following machine (again) :- | ||
41 | |||
42 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
43 | | | ||
44 | +-> [Consumer B @ 3.3V] | ||
45 | |||
46 | 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 | ||
48 | supply (Regulator-2). | ||
49 | |||
50 | This relationship can be register with the core via :- | ||
51 | |||
52 | int regulator_set_supply(const char *regulator, const char *regulator_supply); | ||
53 | |||
54 | In this example we would use the following code :- | ||
55 | |||
56 | regulator_set_supply("Regulator-2", "Regulator-1"); | ||
57 | |||
58 | Relationships can be queried by calling :- | ||
59 | |||
60 | const char *regulator_get_supply(const char *regulator); | ||
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 | }; | ||
92 | |||
93 | struct regulation_constraints domain_2 = { | ||
94 | .min_uV = 1800000, | ||
95 | .max_uV = 2000000, | ||
96 | .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE, | ||
97 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | ||
98 | }; | ||
99 | |||
100 | regulator_set_platform_constraints("Regulator-1", &domain_1); | ||
101 | regulator_set_platform_constraints("Regulator-2", &domain_2); | ||
diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt new file mode 100644 index 00000000000..bdcb332bd7f --- /dev/null +++ b/Documentation/power/regulator/overview.txt | |||
@@ -0,0 +1,171 @@ | |||
1 | Linux voltage and current regulator framework | ||
2 | ============================================= | ||
3 | |||
4 | About | ||
5 | ===== | ||
6 | |||
7 | This framework is designed to provide a standard kernel interface to control | ||
8 | voltage and current regulators. | ||
9 | |||
10 | The intention is to allow systems to dynamically control regulator power output | ||
11 | in order to save power and prolong battery life. This applies to both voltage | ||
12 | regulators (where voltage output is controllable) and current sinks (where | ||
13 | current limit is controllable). | ||
14 | |||
15 | (C) 2008 Wolfson Microelectronics PLC. | ||
16 | Author: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
17 | |||
18 | |||
19 | Nomenclature | ||
20 | ============ | ||
21 | |||
22 | Some terms used in this document:- | ||
23 | |||
24 | o Regulator - Electronic device that supplies power to other devices. | ||
25 | Most regulators can enable and disable their output whilst | ||
26 | some can control their output voltage and or current. | ||
27 | |||
28 | Input Voltage -> Regulator -> Output Voltage | ||
29 | |||
30 | |||
31 | o PMIC - Power Management IC. An IC that contains numerous regulators | ||
32 | and often contains other susbsystems. | ||
33 | |||
34 | |||
35 | o Consumer - Electronic device that is supplied power by a regulator. | ||
36 | Consumers can be classified into two types:- | ||
37 | |||
38 | Static: consumer does not change it's supply voltage or | ||
39 | current limit. It only needs to enable or disable it's | ||
40 | power supply. It's supply voltage is set by the hardware, | ||
41 | bootloader, firmware or kernel board initialisation code. | ||
42 | |||
43 | Dynamic: consumer needs to change it's supply voltage or | ||
44 | current limit to meet operation demands. | ||
45 | |||
46 | |||
47 | o Power Domain - Electronic circuit that is supplied it's input power by the | ||
48 | output power of a regulator, switch or by another power | ||
49 | domain. | ||
50 | |||
51 | The supply regulator may be behind a switch(s). i.e. | ||
52 | |||
53 | Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A] | ||
54 | | | | ||
55 | | +-> [Consumer B], [Consumer C] | ||
56 | | | ||
57 | +-> [Consumer D], [Consumer E] | ||
58 | |||
59 | That is one regulator and three power domains: | ||
60 | |||
61 | Domain 1: Switch-1, Consumers D & E. | ||
62 | Domain 2: Switch-2, Consumers B & C. | ||
63 | Domain 3: Consumer A. | ||
64 | |||
65 | and this represents a "supplies" relationship: | ||
66 | |||
67 | Domain-1 --> Domain-2 --> Domain-3. | ||
68 | |||
69 | A power domain may have regulators that are supplied power | ||
70 | by other regulators. i.e. | ||
71 | |||
72 | Regulator-1 -+-> Regulator-2 -+-> [Consumer A] | ||
73 | | | ||
74 | +-> [Consumer B] | ||
75 | |||
76 | This gives us two regulators and two power domains: | ||
77 | |||
78 | Domain 1: Regulator-2, Consumer B. | ||
79 | Domain 2: Consumer A. | ||
80 | |||
81 | and a "supplies" relationship: | ||
82 | |||
83 | Domain-1 --> Domain-2 | ||
84 | |||
85 | |||
86 | o Constraints - Constraints are used to define power levels for performance | ||
87 | and hardware protection. Constraints exist at three levels: | ||
88 | |||
89 | Regulator Level: This is defined by the regulator hardware | ||
90 | operating parameters and is specified in the regulator | ||
91 | datasheet. i.e. | ||
92 | |||
93 | - voltage output is in the range 800mV -> 3500mV. | ||
94 | - regulator current output limit is 20mA @ 5V but is | ||
95 | 10mA @ 10V. | ||
96 | |||
97 | Power Domain Level: This is defined in software by kernel | ||
98 | level board initialisation code. It is used to constrain a | ||
99 | power domain to a particular power range. i.e. | ||
100 | |||
101 | - Domain-1 voltage is 3300mV | ||
102 | - Domain-2 voltage is 1400mV -> 1600mV | ||
103 | - Domain-3 current limit is 0mA -> 20mA. | ||
104 | |||
105 | Consumer Level: This is defined by consumer drivers | ||
106 | dynamically setting voltage or current limit levels. | ||
107 | |||
108 | e.g. a consumer backlight driver asks for a current increase | ||
109 | from 5mA to 10mA to increase LCD illumination. This passes | ||
110 | to through the levels as follows :- | ||
111 | |||
112 | Consumer: need to increase LCD brightness. Lookup and | ||
113 | request next current mA value in brightness table (the | ||
114 | consumer driver could be used on several different | ||
115 | personalities based upon the same reference device). | ||
116 | |||
117 | Power Domain: is the new current limit within the domain | ||
118 | operating limits for this domain and system state (e.g. | ||
119 | battery power, USB power) | ||
120 | |||
121 | Regulator Domains: is the new current limit within the | ||
122 | regulator operating parameters for input/ouput voltage. | ||
123 | |||
124 | If the regulator request passes all the constraint tests | ||
125 | then the new regulator value is applied. | ||
126 | |||
127 | |||
128 | Design | ||
129 | ====== | ||
130 | |||
131 | The framework is designed and targeted at SoC based devices but may also be | ||
132 | relevant to non SoC devices and is split into the following four interfaces:- | ||
133 | |||
134 | |||
135 | 1. Consumer driver interface. | ||
136 | |||
137 | This uses a similar API to the kernel clock interface in that consumer | ||
138 | drivers can get and put a regulator (like they can with clocks atm) and | ||
139 | get/set voltage, current limit, mode, enable and disable. This should | ||
140 | allow consumers complete control over their supply voltage and current | ||
141 | limit. This also compiles out if not in use so drivers can be reused in | ||
142 | systems with no regulator based power control. | ||
143 | |||
144 | See Documentation/power/regulator/consumer.txt | ||
145 | |||
146 | 2. Regulator driver interface. | ||
147 | |||
148 | This allows regulator drivers to register their regulators and provide | ||
149 | operations to the core. It also has a notifier call chain for propagating | ||
150 | regulator events to clients. | ||
151 | |||
152 | See Documentation/power/regulator/regulator.txt | ||
153 | |||
154 | 3. Machine interface. | ||
155 | |||
156 | This interface is for machine specific code and allows the creation of | ||
157 | voltage/current domains (with constraints) for each regulator. It can | ||
158 | provide regulator constraints that will prevent device damage through | ||
159 | overvoltage or over current caused by buggy client drivers. It also | ||
160 | allows the creation of a regulator tree whereby some regulators are | ||
161 | supplied by others (similar to a clock tree). | ||
162 | |||
163 | See Documentation/power/regulator/machine.txt | ||
164 | |||
165 | 4. Userspace ABI. | ||
166 | |||
167 | The framework also exports a lot of useful voltage/current/opmode data to | ||
168 | userspace via sysfs. This could be used to help monitor device power | ||
169 | consumption and status. | ||
170 | |||
171 | See Documentation/ABI/testing/regulator-sysfs.txt | ||
diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt new file mode 100644 index 00000000000..a6905014359 --- /dev/null +++ b/Documentation/power/regulator/regulator.txt | |||
@@ -0,0 +1,30 @@ | |||
1 | Regulator Driver Interface | ||
2 | ========================== | ||
3 | |||
4 | The regulator driver interface is relatively simple and designed to allow | ||
5 | regulator drivers to register their services with the core framework. | ||
6 | |||
7 | |||
8 | Registration | ||
9 | ============ | ||
10 | |||
11 | Drivers can register a regulator by calling :- | ||
12 | |||
13 | struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, | ||
14 | void *reg_data); | ||
15 | |||
16 | This will register the regulators capabilities and operations the regulator | ||
17 | core. The core does not touch reg_data (private to regulator driver). | ||
18 | |||
19 | Regulators can be unregistered by calling :- | ||
20 | |||
21 | void regulator_unregister(struct regulator_dev *rdev); | ||
22 | |||
23 | |||
24 | Regulator Events | ||
25 | ================ | ||
26 | Regulators can send events (e.g. over temp, under voltage, etc) to consumer | ||
27 | drivers by calling :- | ||
28 | |||
29 | int regulator_notifier_call_chain(struct regulator_dev *rdev, | ||
30 | unsigned long event, void *data); | ||