linux-stable.git/include/linux/regulator/driver.h, branch v3.3.4

regulator: map consumer regulator based on device tree

2011-11-23T18:47:31+00:00

Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.

For Example:
	devicenode: node@0x0 {
		...
		...
		vmmc-supply = <®ulator1>;
		vpll-supply = <®ulator2>;
	};

The driver would then do a regulator_get(dev, "vmmc"); to get
regulator1 and do a regulator_get(dev, "vpll"); to get
regulator2.

of_get_regulator() extracts the regulator node for a given
device, based on the supply name.

Use it to look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.

Also, since the regulator dt nodes can use the same binding to
associate with a parent regulator/supply, allow the drivers to
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.

Signed-off-by: Rajendra Nayak 
Acked-by: Grant Likely 
Signed-off-by: Mark Brown

regulator: pass additional of_node to regulator_register()

2011-11-23T18:47:04+00:00

With device tree support for regulators, its needed that the
regulator_dev->dev device has the right of_node attached.
To be able to do this add an additional parameter to the
regulator_register() api, wherein the dt-adapted driver can
then pass this additional info onto the regulator core.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Mark Brown

regulator: Fix implicit use of notifier.h by driver.h

2011-10-31T23:32:16+00:00

This was implicitly appearing by way of module.h -- but when
we fix that, we'll get this:

In file included from drivers/regulator/dummy.c:21:
include/linux/regulator/driver.h:197: error: field 'notifier' has incomplete type
make[3]: *** [drivers/regulator/dummy.o] Error 1

Signed-off-by: Paul Gortmaker

regulator: Implement deferred disable support

2011-09-14T09:58:23+00:00

It is a reasonably common pattern for hardware to require some delay after
being quiesced before the disable has finalised, especially in mixed signal
devices. For example, an active discharge may be required to ensure that
the circuit starts up again in a known state. Avoid having to implement
such delays in the regulator API by providing regulator_deferred_disable()
which will do a regulator_disable() a specified number of milliseconds
after it is called.

Due to the reference counting done on regulators a deferred disable can
be cancelled by doing another regulator_enable().

Signed-off-by: Mark Brown 
Acked-by: Liam Girdwood

regulator: Refactor supply implementation to work as regular consumers

2011-06-09T18:14:34+00:00

Currently the regulator supply implementation is somewhat complex and
fragile as it doesn't look like standard consumers but is instead a
parallel implementation. This causes issues with locking and reference
counting.

Move the implementation over to using standard consumers to address this.
Rather than only notifying the supply on the first enable/disable we do so
every time the regulator is enabled or disabled, simplifying locking as we
don't need to hold a lock on the consumer we are about to enable.

Signed-off-by: Mark Brown 
Signed-off-by: Liam Girdwood

regulator: add set_voltage_time_sel infrastructure

2011-03-26T14:15:06+00:00

This makes it possible to set the stabilization time for voltage
regulators in the same manner as enable_time(). The interface
only supports regulators that implements fixed selectors.

Cc: Bengt Jonsson 
Signed-off-by: Linus Walleij 
Acked-by: Mark Brown 
Signed-off-by: Liam Girdwood

regulator: Add initial per-regulator debugfs support

2011-01-12T14:33:05+00:00

We only expose the use and open counts to userspace, providing a tiny
bit of insight into what the API is up to.

Signed-off-by: Mark Brown 
Signed-off-by: Liam Girdwood

regulator: Provide a selector based set_voltage_sel() operation

2011-01-12T14:33:04+00:00

Many regulator drivers implement voltage setting by looping through a
table of possible values, normally because the set of available voltages
can't be mapped onto selectors with simple calcuation. Factor out these
loops by providing a variant of set_voltage() which takes a selector rather
than a voltage range as an argument and implementing a loop through the
available selectors in the core.

This is not going to be suitable for use with all devices as when the
regulator voltage can be mapped onto selector values with a simple
calculation the linear scan through the available values will be more
expensive than just doing the calculation, especially for regulators
that provide fine grained voltage control.

Signed-off-by: Mark Brown 
Signed-off-by: Liam Girdwood

regulator: Allow drivers to report voltages as selectors

2011-01-12T14:33:01+00:00

Since drivers already have to provide an API for translating selectors
into voltages they may as well just report the selector values directly
to the core API rather than implement the lookup themselves. The old
interface is left in place for now, but may be removed in future.

Signed-off-by: Mark Brown 
Signed-off-by: Liam Girdwood

regulator: Copy constraints from regulators when initialising them

2011-01-12T14:33:01+00:00

Currently the regulator API uses the constraints structure passed in to
the core throughout the lifetime of the object. This means that it is not
possible to mark the constraints as __initdata so if the kernel supports
many boards the constraints for all of them are kept around throughout the
lifetime of the system, consuming memory needlessly. By copying constraints
that are actually used we allow the use of __initdata, saving memory when
multiple boards are supported.

This also means the constraints can be const.

Signed-off-by: Mark Brown 
Signed-off-by: Liam Girdwood