Commit Graph

12 Commits

Author SHA1 Message Date
Kishon Vijay Abraham I 93134c7b40 regulator: of: Added a property to indicate bypass mode support
Added a property to indicate if the regulator supports bypass mode.
Also modified of_get_regulation_constraints() to check for that
property and set appropriate constraints.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-06-20 12:20:09 +01:00
Stephen Warren a2f95c3637 regulator: clear state each invocation of of_regulator_match
of_regulator_match() saves some dynamcially allocated state into the
match table that's passed to it. By implementation and not contract, for
each match table entry, if non-NULL state is already present,
of_regulator_match() will not overwrite it. of_regulator_match() is
typically called each time a regulator is probe()d. This means it is
called with the same match table over and over again if a regulator
triggers deferred probe. This results in stale, kfree()d data being left
in the match table from probe to probe, which causes a variety of crashes
or use of invalid data.

Explicitly free all output state from of_regulator_match() before
generating new results in order to avoid this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
2013-01-30 10:11:06 +08:00
Stephen Warren 13511def87 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-25 13:44:47 +01:00
Laxman Dewangan 5260cd2bc9 regulator: dt: regulator match by regulator-compatible
Match the device's regulators with the property of
"regulator-compatible" of each regulator node.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-07-03 20:19:41 +01:00
Axel Lin 086ccd4379 regulator: Fix setting constraints->ramp_delay in of_get_regulation_constraints
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-18 10:46:57 +01:00
Yadwinder Singh Brar 6f0b2c696c regulator: Add ramp_delay configuration to constraints
For some hardwares ramp_delay for BUCKs is a configurable parameter which can
be configured through DT or board file.This patch adds ramp_delay to regulator
constraints and allow user to configure it for regulators which supports this
feature, through DT or board file. It will provide two ways of setting the
ramp_delay for a regulator:
	First, by setting it as constraints in board file(for configurable
regulators) and set_machine_constraints() will take care of setting it on
hardware by calling(the provided) .set_ramp_delay() operation(callback).
	Second, by setting it as data in regulator_desc(as fixed/default
ramp_delay rate) for a regulator in driver.

regulator_set_voltage_time_sel() will give preference to
constraints->ramp_delay while reading ramp_delay rate for regulator. Similarly
users should also take care accordingly while refering ramp_delay rate(in case
of implementing their private .set_voltage_time_sel() callbacks for different
regulators).

[Rewrote subject for 80 columns -- broonie]

Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-06-17 21:08:52 +01:00
Thierry Reding 1c8fa58f47 regulator: Add generic DT parsing for regulators
Looking up init data for regulators found on chips is a common operation
that can be handled in a generic way. The new helper function introduced
by this patch looks up the children of a given node by names specified
in a match table and fills that match table with information parsed from
the DT.

This is based on work by Rhyland Klein <rklein@nvidia.com>.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-05-04 13:25:15 +01:00
Karol Lewandowski 8a093049c6 regulator: Set apply_uV only when min and max voltages are defined
apply_uV is errornously set when regulator is instantiated from device
tree, even when it doesn't contain any voltage constraints.

This commit fixes error:

  machine_constraints_voltage: CHARGER: failed to apply 0uV constraint

for following regulator description in DTS:

  CHARGER {
	regulator-min-microamp = <100000>;
	regulator-max-microamp = <200000>;
  }

Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-01-26 11:01:21 +00:00
Shawn Guo d9a861cce1 regulator: pass device_node to of_get_regulator_init_data()
It's not always true that the device_node of regulator can be found
at dev->of_node at the time when of_get_regulator_init_data() is being
called, because in some cases the regulator nodes in device tree do
not have 'struct device' behind them until regulator_dev gets created
for it by core function regulator_register().

The patch adds device_node as a new parameter to
of_get_regulator_init_data(), so that caller can pass in the node of
regulator directly.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-12-05 19:10:17 +00:00
Mark Brown ab62aa931e regulator: If a single voltage is set with device tree then set apply_uV
Otherwise there is no way in the bindings to configure a fixed voltage
via software. It seems reasonable to assume that if the binding explicitly
specifies a voltage we want to actually use that voltage.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-12-05 18:59:10 +00:00
Axel Lin e69af5e967 regulator: export of_get_regulator_init_data
of_get_regulator_init_data is called in drivers/regulator/fixed.c
which could be a module.

Export of_get_regulator_init_data to fix below build error:
ERROR: "of_get_regulator_init_data" [drivers/regulator/fixed.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-11-27 11:29:21 +00:00
Rajendra Nayak 8f446e6fa1 regulator: helper routine to extract regulator_init_data
The helper routine is meant to be used by the regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Similarly the regulator<-->parent/supply mapping is handled in
subsequent patches.

Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.

Some of the regulator properties which are linux and board specific,
are left out since its not clear if they can
be in someway embedded into the kernel or passed in from DT.
They will be revisited later.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-11-23 18:46:55 +00:00