diff options
author | Liam Girdwood <lrg@slimlogic.co.uk> | 2008-10-10 08:22:20 -0400 |
---|---|---|
committer | Liam Girdwood <lrg@slimlogic.co.uk> | 2008-10-13 16:51:50 -0400 |
commit | a5766f11cfd3a0c03450d99c8fe548c2940be884 (patch) | |
tree | c511dd532fb20329d59c47b0f24b3ba587698319 /Documentation/power/regulator | |
parent | a447c0932445f92ce6f4c1bd020f62c5097a7842 (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.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 | ||