aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLiam Girdwood <lg@opensource.wolfsonmicro.com>2008-04-30 12:22:50 -0400
committerLiam Girdwood <lg@opensource.wolfsonmicro.com>2008-07-30 05:10:22 -0400
commite7d0fe340557b202dc00135ab3cc877db794a01f (patch)
tree3ba6bec545c6939411a5d5b3fb40d9e4382a5128
parente8695ebe5568921c41c269f4434e17590735865c (diff)
regulator: documentation - machine
This adds documenation describing the regulator machine interface. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
-rw-r--r--Documentation/power/regulator/machine.txt101
1 files changed, 101 insertions, 0 deletions
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt
new file mode 100644
index 000000000000..c9a35665cf70
--- /dev/null
+++ b/Documentation/power/regulator/machine.txt
@@ -0,0 +1,101 @@
1Regulator Machine Driver Interface
2===================================
3
4The regulator machine driver interface is intended for board/machine specific
5initialisation code to configure the regulator subsystem. Typical things that
6machine drivers would do are :-
7
8 1. Regulator -> Device mapping.
9 2. Regulator supply configuration.
10 3. Power Domain constraint setting.
11
12
13
141. Regulator -> device mapping
15==============================
16Consider the following machine :-
17
18 Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
19 |
20 +-> [Consumer B @ 3.3V]
21
22The drivers for consumers A & B must be mapped to the correct regulator in
23order to control their power supply. This mapping can be achieved in machine
24initialisation code by calling :-
25
26int regulator_set_device_supply(const char *regulator, struct device *dev,
27 const char *supply);
28
29and is shown with the following code :-
30
31regulator_set_device_supply("Regulator-1", devB, "Vcc");
32regulator_set_device_supply("Regulator-2", devA, "Vcc");
33
34This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
35to the 'Vcc' supply for Consumer A.
36
37
382. Regulator supply configuration.
39==================================
40Consider the following machine (again) :-
41
42 Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
43 |
44 +-> [Consumer B @ 3.3V]
45
46Regulator-1 supplies power to Regulator-2. This relationship must be registered
47with the core so that Regulator-1 is also enabled when Consumer A enables it's
48supply (Regulator-2).
49
50This relationship can be register with the core via :-
51
52int regulator_set_supply(const char *regulator, const char *regulator_supply);
53
54In this example we would use the following code :-
55
56regulator_set_supply("Regulator-2", "Regulator-1");
57
58Relationships can be queried by calling :-
59
60const char *regulator_get_supply(const char *regulator);
61
62
633. Power Domain constraint setting.
64===================================
65Each power domain within a system has physical constraints on voltage and
66current. This must be defined in software so that the power domain is always
67operated within specifications.
68
69Consider the following machine (again) :-
70
71 Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
72 |
73 +-> [Consumer B @ 3.3V]
74
75This gives us two regulators and two power domains:
76
77 Domain 1: Regulator-2, Consumer B.
78 Domain 2: Consumer A.
79
80Constraints can be registered by calling :-
81
82int regulator_set_platform_constraints(const char *regulator,
83 struct regulation_constraints *constraints);
84
85The example is defined as follows :-
86
87struct regulation_constraints domain_1 = {
88 .min_uV = 3300000,
89 .max_uV = 3300000,
90 .valid_modes_mask = REGULATOR_MODE_NORMAL,
91};
92
93struct 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
100regulator_set_platform_constraints("Regulator-1", &domain_1);
101regulator_set_platform_constraints("Regulator-2", &domain_2);