Commit 3a4c6959 authored by Geert Uytterhoeven's avatar Geert Uytterhoeven Committed by Mark Brown

regulator: Proofread documentation

Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: default avatarMark Brown <broonie@linaro.org>
parent 7d1311b9
...@@ -143,8 +143,9 @@ This will cause the core to recalculate the total load on the regulator (based ...@@ -143,8 +143,9 @@ This will cause the core to recalculate the total load on the regulator (based
on all its consumers) and change operating mode (if necessary and permitted) on all its consumers) and change operating mode (if necessary and permitted)
to best match the current operating load. to best match the current operating load.
The load_uA value can be determined from the consumers datasheet. e.g.most The load_uA value can be determined from the consumer's datasheet. e.g. most
datasheets have tables showing the max current consumed in certain situations. datasheets have tables showing the maximum current consumed in certain
situations.
Most consumers will use indirect operating mode control since they have no Most consumers will use indirect operating mode control since they have no
knowledge of the regulator or whether the regulator is shared with other knowledge of the regulator or whether the regulator is shared with other
...@@ -173,7 +174,7 @@ Consumers can register interest in regulator events by calling :- ...@@ -173,7 +174,7 @@ Consumers can register interest in regulator events by calling :-
int regulator_register_notifier(struct regulator *regulator, int regulator_register_notifier(struct regulator *regulator,
struct notifier_block *nb); struct notifier_block *nb);
Consumers can uregister interest by calling :- Consumers can unregister interest by calling :-
int regulator_unregister_notifier(struct regulator *regulator, int regulator_unregister_notifier(struct regulator *regulator,
struct notifier_block *nb); struct notifier_block *nb);
......
...@@ -9,14 +9,14 @@ Safety ...@@ -9,14 +9,14 @@ Safety
- Errors in regulator configuration can have very serious consequences - Errors in regulator configuration can have very serious consequences
for the system, potentially including lasting hardware damage. for the system, potentially including lasting hardware damage.
- It is not possible to automatically determine the power confugration - It is not possible to automatically determine the power configuration
of the system - software-equivalent variants of the same chip may of the system - software-equivalent variants of the same chip may
have different power requirments, and not all components with power have different power requirements, and not all components with power
requirements are visible to software. requirements are visible to software.
=> The API should make no changes to the hardware state unless it has => The API should make no changes to the hardware state unless it has
specific knowledge that these changes are safe to do perform on specific knowledge that these changes are safe to perform on this
this particular system. particular system.
Consumer use cases Consumer use cases
------------------ ------------------
......
...@@ -11,7 +11,7 @@ Consider the following machine :- ...@@ -11,7 +11,7 @@ Consider the following machine :-
+-> [Consumer B @ 3.3V] +-> [Consumer B @ 3.3V]
The drivers for consumers A & B must be mapped to the correct regulator in The drivers for consumers A & B must be mapped to the correct regulator in
order to control their power supply. This mapping can be achieved in machine order to control their power supplies. This mapping can be achieved in machine
initialisation code by creating a struct regulator_consumer_supply for initialisation code by creating a struct regulator_consumer_supply for
each regulator. each regulator.
...@@ -39,7 +39,7 @@ to the 'Vcc' supply for Consumer A. ...@@ -39,7 +39,7 @@ to the 'Vcc' supply for Consumer A.
Constraints can now be registered by defining a struct regulator_init_data Constraints can now be registered by defining a struct regulator_init_data
for each regulator power domain. This structure also maps the consumers for each regulator power domain. This structure also maps the consumers
to their supply regulator :- to their supply regulators :-
static struct regulator_init_data regulator1_data = { static struct regulator_init_data regulator1_data = {
.constraints = { .constraints = {
......
...@@ -36,11 +36,11 @@ Some terms used in this document:- ...@@ -36,11 +36,11 @@ Some terms used in this document:-
Consumers can be classified into two types:- Consumers can be classified into two types:-
Static: consumer does not change its supply voltage or Static: consumer does not change its supply voltage or
current limit. It only needs to enable or disable it's current limit. It only needs to enable or disable its
power supply. Its supply voltage is set by the hardware, power supply. Its supply voltage is set by the hardware,
bootloader, firmware or kernel board initialisation code. bootloader, firmware or kernel board initialisation code.
Dynamic: consumer needs to change it's supply voltage or Dynamic: consumer needs to change its supply voltage or
current limit to meet operation demands. current limit to meet operation demands.
...@@ -156,7 +156,7 @@ relevant to non SoC devices and is split into the following four interfaces:- ...@@ -156,7 +156,7 @@ relevant to non SoC devices and is split into the following four interfaces:-
This interface is for machine specific code and allows the creation of This interface is for machine specific code and allows the creation of
voltage/current domains (with constraints) for each regulator. It can voltage/current domains (with constraints) for each regulator. It can
provide regulator constraints that will prevent device damage through provide regulator constraints that will prevent device damage through
overvoltage or over current caused by buggy client drivers. It also overvoltage or overcurrent caused by buggy client drivers. It also
allows the creation of a regulator tree whereby some regulators are allows the creation of a regulator tree whereby some regulators are
supplied by others (similar to a clock tree). supplied by others (similar to a clock tree).
......
...@@ -13,7 +13,7 @@ Drivers can register a regulator by calling :- ...@@ -13,7 +13,7 @@ Drivers can register a regulator by calling :-
struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
const struct regulator_config *config); const struct regulator_config *config);
This will register the regulators capabilities and operations to the regulator This will register the regulator's capabilities and operations to the regulator
core. core.
Regulators can be unregistered by calling :- Regulators can be unregistered by calling :-
...@@ -23,8 +23,8 @@ void regulator_unregister(struct regulator_dev *rdev); ...@@ -23,8 +23,8 @@ void regulator_unregister(struct regulator_dev *rdev);
Regulator Events Regulator Events
================ ================
Regulators can send events (e.g. over temp, under voltage, etc) to consumer Regulators can send events (e.g. overtemperature, undervoltage, etc) to
drivers by calling :- consumer drivers by calling :-
int regulator_notifier_call_chain(struct regulator_dev *rdev, int regulator_notifier_call_chain(struct regulator_dev *rdev,
unsigned long event, void *data); unsigned long event, void *data);
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment