regulator: Proofread documentation

on all its consumers) and change operating mode (if necessary and permitted)

to best match the current operating load.

The load_uA value can be determined from the consumers datasheet. e.g.most

datasheets have tables showing the max current consumed in certain situations.

The load_uA value can be determined from the consumer's datasheet. e.g. most

datasheets have tables showing the maximum current consumed in certain

situations.

Most consumers will use indirect operating mode control since they have no

knowledge of the regulator or whether the regulator is shared with other

int regulator_register_notifier(struct regulator *regulator,

			      struct notifier_block *nb);

Consumers can uregister interest by calling :-

Consumers can unregister interest by calling :-

int regulator_unregister_notifier(struct regulator *regulator,

				struct notifier_block *nb);

 - Errors in regulator configuration can have very serious consequences

   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

   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.

  => The API should make no changes to the hardware state unless it has

     specific knowledge that these changes are safe to do perform on

     this particular system.

     specific knowledge that these changes are safe to perform on this

     particular system.

Consumer use cases

------------------

               +-> [Consumer B @ 3.3V]

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

each regulator.

Constraints can now be registered by defining a struct regulator_init_data

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 = {

	.constraints = {

                   Consumers can be classified into two types:-

                   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,

                   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.

struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,

					 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.

Regulators can be unregistered by calling :-

Regulator Events

================

Regulators can send events (e.g. over temp, under voltage, etc) to consumer

drivers by calling :-

Regulators can send events (e.g. overtemperature, undervoltage, etc) to

consumer drivers by calling :-

int regulator_notifier_call_chain(struct regulator_dev *rdev,

				  unsigned long event, void *data);