2011-11-18 11:17:17 +00:00
|
|
|
Voltage/Current Regulators
|
|
|
|
|
|
|
|
|
|
Optional properties:
|
|
|
|
|
- regulator-name: A string used as a descriptive name for regulator outputs
|
|
|
|
|
- regulator-min-microvolt: smallest voltage consumers may set
|
|
|
|
|
- regulator-max-microvolt: largest voltage consumers may set
|
|
|
|
|
- regulator-microvolt-offset: Offset applied to voltages to compensate for voltage drops
|
|
|
|
|
- regulator-min-microamp: smallest current consumers may set
|
|
|
|
|
- regulator-max-microamp: largest current consumers may set
|
|
|
|
|
- regulator-always-on: boolean, regulator should never be disabled
|
|
|
|
|
- regulator-boot-on: bootloader/firmware enabled regulator
|
2013-06-20 08:37:37 +00:00
|
|
|
- regulator-allow-bypass: allow the regulator to go into bypass mode
|
2011-11-18 11:17:17 +00:00
|
|
|
- <name>-supply: phandle to the parent supply/regulator node
|
2012-06-18 06:03:16 +00:00
|
|
|
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)
|
regulator: deprecate regulator-compatible DT property
When the bindings for the TPS6586x regulator were being proposed, I
asserted that DT node naming rules for bus child nodes should also be
applied to nodes inside the TPS6586x regulator node itself. In other
words, that each node providing regulator init data should be named
after the type of object it represented ("regulator") and hence that
some other property was required to indicate which regulator the node
described ("regulator-compatible"). In turn this led to multiple nodes
having the same name, thus requiring node names to use a unit address
to make them unique, thus requiring reg properties within the nodes and
However, subsequent discussion indicates that the rules I was asserting
only applies to standardized bus nodes, and within a device's own node,
the binding can basically do anything sane that it wants.
Hence, this change deprecates the register-compatible property, and
instead uses node names to replace this functionality. This greatly
simplifies the device tree content, making them smaller and more legible.
The code is changed such that old device trees continue to work.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-09-24 19:25:00 +00:00
|
|
|
|
|
|
|
|
Deprecated properties:
|
2012-07-05 07:23:04 +00:00
|
|
|
- regulator-compatible: If a regulator chip contains multiple
|
|
|
|
|
regulators, and if the chip's binding contains a child node that
|
|
|
|
|
describes each regulator, then this property indicates which regulator
|
regulator: deprecate regulator-compatible DT property
When the bindings for the TPS6586x regulator were being proposed, I
asserted that DT node naming rules for bus child nodes should also be
applied to nodes inside the TPS6586x regulator node itself. In other
words, that each node providing regulator init data should be named
after the type of object it represented ("regulator") and hence that
some other property was required to indicate which regulator the node
described ("regulator-compatible"). In turn this led to multiple nodes
having the same name, thus requiring node names to use a unit address
to make them unique, thus requiring reg properties within the nodes and
However, subsequent discussion indicates that the rules I was asserting
only applies to standardized bus nodes, and within a device's own node,
the binding can basically do anything sane that it wants.
Hence, this change deprecates the register-compatible property, and
instead uses node names to replace this functionality. This greatly
simplifies the device tree content, making them smaller and more legible.
The code is changed such that old device trees continue to work.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-09-24 19:25:00 +00:00
|
|
|
this child node is intended to configure. If this property is missing,
|
|
|
|
|
the node's name will be used instead.
|
2011-11-18 11:17:17 +00:00
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
xyzreg: regulator@0 {
|
|
|
|
|
regulator-min-microvolt = <1000000>;
|
|
|
|
|
regulator-max-microvolt = <2500000>;
|
|
|
|
|
regulator-always-on;
|
|
|
|
|
vin-supply = <&vin>;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
Regulator Consumers:
|
|
|
|
|
Consumer nodes can reference one or more of its supplies/
|
|
|
|
|
regulators using the below bindings.
|
|
|
|
|
|
|
|
|
|
- <name>-supply: phandle to the regulator node
|
|
|
|
|
|
|
|
|
|
These are the same bindings that a regulator in the above
|
|
|
|
|
example used to reference its own supply, in which case
|
|
|
|
|
its just seen as a special case of a regulator being a
|
|
|
|
|
consumer itself.
|
|
|
|
|
|
|
|
|
|
Example of a consumer device node (mmc) referencing two
|
2011-11-28 13:37:16 +00:00
|
|
|
regulators (twl_reg1 and twl_reg2),
|
2011-11-18 11:17:17 +00:00
|
|
|
|
2011-11-28 13:37:16 +00:00
|
|
|
twl_reg1: regulator@0 {
|
2011-11-18 11:17:17 +00:00
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
|
2011-11-28 13:37:16 +00:00
|
|
|
twl_reg2: regulator@1 {
|
2011-11-18 11:17:17 +00:00
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
mmc: mmc@0x0 {
|
|
|
|
|
...
|
|
|
|
|
...
|
2011-11-28 13:37:16 +00:00
|
|
|
vmmc-supply = <&twl_reg1>;
|
|
|
|
|
vmmcaux-supply = <&twl_reg2>;
|
2011-11-18 11:17:17 +00:00
|
|
|
};
|
