Fix fatal kernel-doc error in <linux/regulator/driver.h>:

Error(include/linux/regulator/driver.h:52): cannot understand prototype: 'struct regulator_linear_range '
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
[Rewrote first line -- broonie]
Signed-off-by: NMark Brown <broonie@linaro.org>

Many regulators have several linear ranges of selector with different
step sizes, for example offering better resolution at lower voltages.
Provide regulator_{map,list}_voltage_linear_range() allowing these
regulators to use generic code. To do so a table of regulator_linear_range
structs needs to be pointed to from the descriptor.

This was inspired by similar code included in a driver submission from
Chao Xie and Yi Zhang at Marvell.
Signed-off-by: NMark Brown <broonie@linaro.org>

A lot of regulator hardware has ascendant voltage list.
This patch adds regulator_map_voltage_ascend() and export it.

Drivers that have ascendant voltage list can use this as their map_voltage()
operation, this is more efficient than default regulator_map_voltage_iterate()
function.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Add enable_is_inverted flag to indicate set enable_mask bits to disable
when using regulator_enable_regmap and friends APIs.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

 The regulator_dev has regulator_enable_gpio structure.
 'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio.

  regulator_dev   --->   regulator_enable_gpio
  .ena_gpio              .gpio
  .ena_gpio_invert       .ena_gpio_invert

  Pointer, 'ena_pin' is used for checking valid enable GPIO pin.
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

 A Regulator can be enabled by external GPIO pin.
 This is configurable in the regulator_config.
 At this moment, the GPIO can be owned by only one regulator device.
 In some devices, multiple regulators are enabled by shared one GPIO pin.
 This patch extends this limitation, enabling shared enable GPIO of regulators.

 New list for enable GPIO: 'regulator_ena_gpio_list'
   This manages enable GPIO list.

 New structure for supporting shared enable GPIO: 'regulator_enable_gpio'
   The enable count is used for balancing GPIO control count.
   This count is incremented when GPIO is enabled.
   On the other hand, it's decremented when GPIO is disabled.

 Reference count: 'request_count'
   The reference count, 'request_count' is incremented/decremented on
   requesting/freeing the GPIO. This count makes sure only free the GPIO
   when it has no users.

 How it works
   If the GPIO is already used, skip requesting new GPIO usage.
   The GPIO is new one, request GPIO function and add it to the list of
   enable GPIO.
   This list is used for balancing enable GPIO count and pin control.

 Updating a GPIO and invert code moved
   'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to
    new function, regulator_ena_gpio_request().
    Use regulator_enable_pin structure rather than regulator_dev.
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

commit df367931 (regulator: core: Provide regmap get/set bypass
operations) introduced regulator_[gs]et_bypass_regmap

However structure documentation for regulator_desc needs an update.
./scripts/kernel-doc include/linux/regulator/driver.h >/dev/null
generates:
Warning(include/linux/regulator/driver.h:233): No description found for parameter 'bypass_reg'
Warning(include/linux/regulator/driver.h:233): No description found for parameter 'bypass_mask'

Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Some DVM regulators needs to update apply_bit after setting vsel_reg to
initiate voltage change on the output.  This patch adds apply_reg and
apply_bit to struct regulator_desc and update
regulator_set_voltage_sel_regmap() to set apply_bit of apply_reg when
apply_bit is set.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Some drivers (at least 3 drivers) have such variant of linear mapping that
the first few selectors are invalid and the reset are linear mapping.
Let's support this case in core.

This patch adds linear_min_sel in struct regulator_desc,
so we can allow specific minimal selector for starting linear mapping.
Then extends regulator_[map|list]_voltage_linear() to support this feature.

Note that for selectors less than min_linear_index, we need count them to
n_voltages so regulator_list_voltage() won't fail while checking the boundary
for selector before calling list_voltage callback.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Some regulators can set any voltage within the constraints range,
not being limited to specified operating points.

This patch makes it possible to describe such regulator and makes
the regulator_is_supported_voltage() function behave correctly.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Many regulators support a bypass mode where they simply switch their
input supply to the output. This is mainly used in low power retention
states where power consumption is extremely low so higher voltage or
less clean supplies can be used.

Support this by providing ops for the drivers and a consumer API which
allows the device to be put into bypass mode if all consumers enable it
and the machine enables permission for this.

This is not supported as a mode since the existing modes are rarely used
due to fuzzy definition and mostly redundant with modern hardware which is
able to respond promptly to load changes.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NGraeme Gregory <gg@slimlogic.co.uk>

Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The regulators should be tending to the maximum in the available range and
consumers should specify the widest range possible.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

REGULATOR_STATUS_UNDEFINED is to be returned by regulator, if any other state
doesn't really apply.
Signed-off-by: NKrystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

It is very common for regulators to support having their enable signal
controlled by a GPIO. Since there are a bunch of fiddly things to get
right like handling the operations when the enable signal is tied to
a rail and it's just replicated code add support for this to the core.

Drivers should set ena_gpio in their config if they have a GPIO control,
using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for
the initial state) and ena_gpio_invert if the GPIO is active low. The
core will then override any enable and disable operations the driver has
and instead control the specified GPIO.

This will in the future also allow us to further extend the core by
identifying when several enable signals have been tied together and
handling this properly.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Many regulators have a fixed specification for their enable time. Allow
this to be set in the regulator_desc as a number to save them having to
implement an explicit operation.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This change makes it possible to set ramp_delay with 0.xxx mV/uS without
truncation issue.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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: NYadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch adds regulator_set_voltage_time_sel(), to move into core, the
commonly used code by drivers to provide the .set_voltage_time_sel callback.
It will also allow us to configure different ramp delay for different
regulators easily.
Signed-off-by: NYadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Some regulator hardware use table based mapping can set volt_table in
regulator_desc and use regulator_list_voltage_table() for their list_voltage
callback.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

A lot of regulator hardware maps selectors on to voltages with a simple
linear mapping function

    selector = base + (selector * step size)

Provide off the shelf list_voltage() and map_voltage() operations which
use new min_uV and uV_step members in the regulator_desc to implement
this function.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

In order to allow more drivers to factor things out into data allow
drivers to provide a mapping function to convert voltages into selectors.
This allows any driver to use set_voltage_sel(). The existing mapping
based on iterating over list_voltage() is provided as an operation which
can be assigned to the new map_voltage() function though for ease of
transition it is treated as the default.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Since the enable(), disable() and is_enabled() operations for most regmap
based regulators come down to reading and updating a single register bit
we can factor out the code and allow these drivers to just define which
bit to update using the enable_reg and enable_mask fields in their desc
and then use operations provided by the core.

As well as the code saving this opens the door to future optimisation of
the bulk operations - if the core can realise that we are updating a
single register for multiple regulators then it should be able to combine
these updates into a single physical operation.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Since the voltage selector operations are intended to directly map a
bitfield in the device register map into regulator API operations the
code for implementing them is usually very standard we can save some
code by providing standard implementations for devices using the regmap
API.

Drivers using regmap can pass their regmap in in the regmap_config
struct, set vsel_reg and vsel_mask in their regulator_desc and then
use regulator_{get,set}_voltage_sel_regmap in their ops. This saves
a small amount of code from each driver.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Since many regulators use regmap for register I/O and since there's quite
a few very common patterns in the code allow drivers to pass in a regmap
to the core for use in generic code.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Rather than adding new arguments to regulator_register() every time we
want to add a new bit of dynamic information at runtime change the function
to take these via a struct. By doing this we avoid needing to do further
changes like the recent addition of device tree support which required each
regulator driver to be updated to take an additional parameter.

The regulator_desc which should (mostly) be static data is still passed
separately as most drivers are able to configure this statically at build
time.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Drivers should be able to declare their descriptors const and the framework
shouldn't ever be modifying the desciptor. Make the parameter and the
pointer in regulator_dev const to enforce this.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If CONFIG_DEBUG_FS=y debugfs functions will never return an
ERR_PTR. Instead they'll return NULL. The intent is to remove
ifdefs in calling code.

Update the code to reflect this. We gain an extra dentry pointer
per struct regulator and struct regulator_dev but that should be
ok because most distros have debugfs compiled in anyway.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The 'mode' is defined in consumer.h.

* patch base version : linux-3.2.4
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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 = <&regulator1>;
		vpll-supply = <&regulator2>;
	};

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: NRajendra Nayak <rnayak@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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: NPaul Gortmaker <paul.gortmaker@windriver.com>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

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 <bengt.g.jonsson@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>