aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/power/regulator
diff options
context:
space:
mode:
authorLiam Girdwood <lrg@slimlogic.co.uk>2008-10-10 08:22:20 -0400
committerLiam Girdwood <lrg@slimlogic.co.uk>2008-10-13 16:51:50 -0400
commita5766f11cfd3a0c03450d99c8fe548c2940be884 (patch)
treec511dd532fb20329d59c47b0f24b3ba587698319 /Documentation/power/regulator
parenta447c0932445f92ce6f4c1bd020f62c5097a7842 (diff)
regulator: core - Rework machine API to remove string based functions.
This improves the machine level API in order to configure regulator constraints and consumers as platform data and removes the old string based API that required several calls to set up each regulator. The intention is to create a struct regulator_init_data, populate it's fields with constraints, consumers devices, etc and then register the regulator device from board.c in the standard Linux way. e.g. regulator LDO2 (supplying codec and sim) platform data. /* regulator LDO2 consumer devices */ static struct regulator_consumer_supply ldo2_consumers[] = { { .dev = &platform_audio_device.dev, .supply = "codec_avdd", }, { .dev = &platform_sim_device.dev, .supply = "sim_vcc", } }; /* regulator LDO2 constraints */ static struct regulator_init_data ldo2_data = { .constraints = { .min_uV = 3300000, .max_uV = 3300000, .valid_modes_mask = REGULATOR_MODE_NORMAL, .apply_uV = 1, }, .num_consumer_supplies = ARRAY_SIZE(ldo2_consumers), .consumer_supplies = ldo2_consumers, }; /* machine regulator devices with thier consumers and constraints */ static struct platform_device wm8350_regulator_devices[] = { { .name = "wm8350-regulator", .id = WM8350_LDO_2, .dev = { .platform_data = &ldo2_data, }, }, }; Changes in detail:- o Removed all const char* regulator config functions in machine API. o Created new struct regulator_init_data to contain regulator machine configuration constraints and consmuers. o Changed set_supply(), set_machine_constraints(), set_consumer_device_supply() to remove their string identifier parameters. Also made them static and moved functions nearer top of core.c. o Removed no longer used inline func to_rdev() o Added regulator_get_init_drvdata() to retrieve init data. o Added struct device* as parameter to regulator_register(). o Changed my email address. Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Diffstat (limited to 'Documentation/power/regulator')
-rw-r--r--Documentation/power/regulator/machine.txt140
-rw-r--r--Documentation/power/regulator/regulator.txt8
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
4The regulator machine driver interface is intended for board/machine specific 4The regulator machine driver interface is intended for board/machine specific
5initialisation code to configure the regulator subsystem. Typical things that 5initialisation code to configure the regulator subsystem.
6machine 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
141. Regulator -> device mapping
15==============================
16Consider the following machine :- 7Consider 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
22The drivers for consumers A & B must be mapped to the correct regulator in 13The 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 14order to control their power supply. This mapping can be achieved in machine
24initialisation code by calling :- 15initialisation code by creating a struct regulator_consumer_supply for
16each regulator.
17
18struct regulator_consumer_supply {
19 struct device *dev; /* consumer */
20 const char *supply; /* consumer supply - e.g. "vcc" */
21};
25 22
26int regulator_set_device_supply(const char *regulator, struct device *dev, 23e.g. for the machine above
27 const char *supply);
28 24
29and is shown with the following code :- 25static struct regulator_consumer_supply regulator1_consumers[] = {
26{
27 .dev = &platform_consumerB_device.dev,
28 .supply = "Vcc",
29},};
30 30
31regulator_set_device_supply("Regulator-1", devB, "Vcc"); 31static struct regulator_consumer_supply regulator2_consumers[] = {
32regulator_set_device_supply("Regulator-2", devA, "Vcc"); 32{
33 .dev = &platform_consumerA_device.dev,
34 .supply = "Vcc",
35},};
33 36
34This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2 37This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
35to the 'Vcc' supply for Consumer A. 38to the 'Vcc' supply for Consumer A.
36 39
37 40Constraints can now be registered by defining a struct regulator_init_data
382. Regulator supply configuration. 41for each regulator power domain. This structure also maps the consumers
39================================== 42to their supply regulator :-
40Consider the following machine (again) :- 43
41 44static 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
46Regulator-1 supplies power to Regulator-2. This relationship must be registered 54Regulator-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 55with the core so that Regulator-1 is also enabled when Consumer A enables it's
48supply (Regulator-2). 56supply (Regulator-2). The supply regulator is set by the supply_regulator_dev
49 57field below:-
50This relationship can be register with the core via :- 58
51 59static struct regulator_init_data regulator2_data = {
52int regulator_set_supply(const char *regulator, const char *regulator_supply); 60 .supply_regulator_dev = &platform_regulator1_device.dev,
53 61 .constraints = {
54In this example we would use the following code :- 62 .min_uV = 1800000,
55 63 .max_uV = 2000000,
56regulator_set_supply("Regulator-2", "Regulator-1"); 64 .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
57 65 .valid_modes_mask = REGULATOR_MODE_NORMAL,
58Relationships can be queried by calling :- 66 },
59 67 .num_consumer_supplies = ARRAY_SIZE(regulator2_consumers),
60const char *regulator_get_supply(const char *regulator); 68 .consumer_supplies = regulator2_consumers,
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}; 69};
92 70
93struct regulation_constraints domain_2 = { 71Finally the regulator devices must be registered in the usual manner.
94 .min_uV = 1800000, 72
95 .max_uV = 2000000, 73static 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 = &regulator1_data,
79 },
80},
81{
82 .name = "regulator",
83 .id = DCDC_2,
84 .dev = {
85 .platform_data = &regulator2_data,
86 },
87},
98}; 88};
89/* register regulator 1 device */
90platform_device_register(&wm8350_regulator_devices[0]);
99 91
100regulator_set_platform_constraints("Regulator-1", &domain_1); 92/* register regulator 2 device */
101regulator_set_platform_constraints("Regulator-2", &domain_2); 93platform_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
11Drivers can register a regulator by calling :- 11Drivers can register a regulator by calling :-
12 12
13struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, 13struct regulator_dev *regulator_register(struct device *dev,
14 void *reg_data); 14 struct regulator_desc *regulator_desc);
15 15
16This will register the regulators capabilities and operations the regulator 16This will register the regulators capabilities and operations to the regulator
17core. The core does not touch reg_data (private to regulator driver). 17core.
18 18
19Regulators can be unregistered by calling :- 19Regulators can be unregistered by calling :-
20 20