sh:sh2007_defconfig fails to build with the following error:

In file included from include/linux/regulator/machine.h:18:0,
                 from arch/sh/boards/board-sh2007.c:10:
include/linux/regulator/consumer.h: In function 'regulator_get_optional':
include/linux/regulator/consumer.h:271:2:
		error: implicit declaration of function 'ERR_PTR'
include/linux/err.h: At top level:
include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR'
include/linux/regulator/consumer.h:271:9:
		note: previous implicit declaration of 'ERR_PTR' was here

Since consumer.h uses ERR_PTR, it should include err.h.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently regulator drivers which support DT all repeat very similar code
to supply a list of known regulator identifiers to be matched with DT,
convert that to platform data which is then matched up with the regulators
as they are registered. This is both fiddly to get right and for devices
which can use the standard helpers to provide their operations is the main
source of code in the driver.

Since this code is essentially identical for most drivers we can factor it
out into the core, moving the identifiers in the match table into the
regulator descriptors and also allowing drivers to pass in the name of the
subnode to search. When a driver provides an of_match string for the
regulator the core will attempt to use that to obtain init_data, allowing
the driver to remove all explicit code for DT parsing and simply provide
data instead.

The current code leaks the phandles for the child nodes, this will be
addressed incrementally and makes no practical difference for FDT anyway
as the DT data structures are never freed.
Signed-off-by: NMark Brown <broonie@linaro.org>

Add device-tree support to max1586.
The driver can still be used with the legacy platform data, or the new
device-tree way.

This work is heavily inspired by the device-tree support of its cousin
max8660 driver.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NMark Brown <broonie@kernel.org>

In some cases we need to know when a regulator is about to be changed.
Add a way for clients to be notified.  Note that for set_voltage() we
don't necessarily know what voltage we'll end up with, so we tell the
client what the range will be so they can prepare.
Signed-off-by: NHeiko Stübner <heiko@sntech.de>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NMark Brown <broonie+linaro@kernel.org>

Fix kernel-doc warnings in regulator header files:

Warning(..//include/linux/regulator/machine.h:140): No description found for parameter 'ramp_disable'
Warning(..//include/linux/regulator/driver.h:279): No description found for parameter 'linear_ranges'
Warning(..//include/linux/regulator/driver.h:279): No description found for parameter 'n_linear_ranges'
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

This is a patch for supporting device tree of DA9211/DA9213.
Signed-off-by: NJames Ban <james.ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Fix below build warning:
CC [M]  drivers/regulator/hi6421-regulator.o
drivers/regulator/hi6421-regulator.c:356:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]

This is a revert of commit 716845eb ("regulator: core: Fix build error due
to const qualifier for ops"). The build error was fixed by commit 39f5460d
("regulator: core: add const to regulator_ops and fix build error in mc13892").
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Drop const qualifier for ops of struct regulator_desc.
Allow regulator drivers to update ops before registering regulator.

Fix below build error:
  CC [M]  drivers/regulator/mc13892-regulator.o
drivers/regulator/mc13892-regulator.c: In function 'mc13892_regulator_probe':
drivers/regulator/mc13892-regulator.c:586:3: error: assignment of member 'set_mode' in read-only object
drivers/regulator/mc13892-regulator.c:588:3: error: assignment of member 'get_mode' in read-only object
make[2]: *** [drivers/regulator/mc13892-regulator.o] Error 1
make[1]: *** [drivers/regulator] Error 2
make: *** [drivers] Error 2
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Some regulator require a minimum delay between its disable and next enable.
This is to avoid damages when out-of-range frequent disable/enable of a
single regulator can bring to the regulator chip.

Add @off_on_delay to struct regulator_desc. Device drivers' can use this field
to set this guard time.

Add @last_off_jiffy to struct regulator_dev. When @off_on_delay is set by
driver, regulator core can store its last off (disable) time into this field.
Signed-off-by: NGuodong Xu <guodong.xu@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

struct regulator_ops *ops is a member in struct regulator_desc, which gets
its value from individual regulator driver upon regulator_register() and
is used by regulator core APIs. It's not allowed for regulator core to
modify any of these callbacks in *ops. Add 'const' qualifier to enforce that.
Signed-off-by: NGuodong Xu <guodong.xu@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

This is a patch for supporting DA9213.
Signed-off-by: NJames Ban <james.ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add device id and definition of registers and regulators to support
the act8846 PMU.
Signed-off-by: NBeniamino Galvani <b.galvani@gmail.com>
Tested-by: NWenyou Yang <wenyou.yang@atmel.com>
Reviewed-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch prepares support for other devices in the act88xx family of
PMUs manufactured by Active-Semi.

http://www.active-semi.com/products/power-management-units/act88xx/Signed-off-by: NBeniamino Galvani <b.galvani@gmail.com>
Tested-by: NWenyou Yang <wenyou.yang@atmel.com>
Reviewed-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

So we don't get multiple definitions.
Signed-off-by: NMark Brown <broonie@linaro.org>

Add helper functions that allow regulator consumers to obtain low-level
details about the regulator hardware, like the voltage selector register
address and such. These details can be useful when configuring hardware
or firmware that want to do low-level access to regulators, with no
involvement from the kernel.

The use-case for Tegra is a voltage-controlled oscillator clocksource
which has control logic to change the supply voltage via I2C to achieve
a desired output clock rate.
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

This is the driver for the Dialog DA9211 Multi-phase 12A DC-DC Buck
Converter regulator. It communicates via an I2C bus to the device.
Signed-off-by: NJames Ban <james.ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

CONFIG_REGULATOR_AB8500_DEBUG is always not defined.
ab8500_regulator_debug_init() is not called at all now,
ab8500_regulator_debug_exit() simply return 0, thus remove them.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

When CONFIG_REGULATOR is not set, we cannot call
regulator_can_change_voltage() from a device driver, which results
in a build error like

video/fbdev/omap2/dss/hdmi5.c: In function 'hdmi_init_regulator':
video/fbdev/omap2/dss/hdmi5.c:149:2: error: implicit declaration of function 'regulator_can_change_voltage' [-Werror=implicit-function-declaration]

even for drivers that don't require the regulator API normally.
Such a use was recently added in the omap2+ hdmi driver.

This avoids the problem by adding a static inline function
stub in the API header, as we have for most of the other
regulator functions as well.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Mark Brown <broonie@kernel.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

We already have dummy implementation for most of the regulators APIs for
!CONFIG_REGULATOR case and were missing it for regulator_set_voltage_time().

Found this issue while compiling cpufreq-cpu0 driver without regulators support
in kernel.

drivers/cpufreq/cpufreq-cpu0.c: In function ‘cpu0_cpufreq_probe’:
drivers/cpufreq/cpufreq-cpu0.c:186:3: error: implicit declaration of function ‘regulator_set_voltage_time’ [-Werror=implicit-function-declaration]

Fix this by adding dummy definition for regulator_set_voltage_time().
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Toughen-up checks for read-only regulator names.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Rather than requiring individual drivers to put the of_nodes returned
from of_regulator_match use devres to put them. This also has the
benefit it makes the life-time of the of_nodes match the lifetime of
the init data also contained in the of_regulator_match structure, which
seems more consistent.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Drivers that call regulator_get_optional are tolerant to the absence of
that regulator.  By modifying the value returned from the stub function
to match that seen when a regulator isn't present, callers can wrap the
regulator logic with an IS_ERR based conditional even if they happen to
call regulator_is_supported_voltage.  This improves efficiency as well
as eliminates the possibility for a very subtle bug.
Signed-off-by: NTim Kryger <tim.kryger@linaro.org>
Reviewed-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Fix a typo from my patch adding of_regulator_put_match in the patch:

regulator: core: Add helper to put of_nodes from matches
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

As of_regulator_match will take an of_node reference to each matched
regulator, it makes sense to provide a helper to put all those
references. This patch does that.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch extends the regulator helpers to account for device that use
multiple bits for control when using regmap enable/disable/bypass ops.

The actual regulator helpers wrongly assume that the regulator control
is always performed using single bits, using in the regulator_desc
struct only two parameters *_reg and *_mask defining register and mask
for control.

This patch extends this struct and introduces the helpers to take into
account devices where control is performed using multiple bits and
specific multi-bit values are used for enabling/disabling/bypassing the
regulator.
Signed-off-by: NCarlo Caione <carlo@caione.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

support pfuze200 chip which remove SW1C and SW4 based on pfuze100.
Signed-off-by: NRobin Gong <b38343@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

These patches add the ability to create an alternative device on which
a lookup for a certain supply should be conducted.

A common use-case for this would be devices that are logically
represented as a collection of drivers within Linux but are are
presented as a single device from device tree. It this case it is
necessary for each sub device to locate their supply data on the main
device.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add REGULATOR_LINEAR_RANGE macro and convert regulator drivers to use it.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

linear ranges means each range has linear voltage settings.
So we can calculate max_uV for each linear range in regulator core rather than
set the max_uV field in drivers.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The turn-on time of the regulator depends on the regulator device's
electrical characteristics. Sometimes regulator turn-on time also
depends on the capacitive load on the given platform and it can be
more than the datasheet value.

The driver provides the enable-time as per datasheet.

Add support for configure the enable ramp time through regulator
constraints so that regulator core can take this value for enable
time for that regulator.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

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>

No boards have used this functionality and the new default of providing
dummy regulators by default provides a better solution to the problem it
was trying to solve.
Signed-off-by: NMark Brown <broonie@linaro.org>

Many regulator drivers have a remove function that consists solely of
calling regulator_unregister() so provide a devm_regulator_register()
in order to allow this repeated code to be removed and help eliminate
error handling code.
Signed-off-by: NMark Brown <broonie@linaro.org>

If given rail has the single voltage (n_voltages = 1) then provide the
rail voltage through regulator descriptor so that core can use this
value for finding voltage.

This will avoid the implementation of the callback for get_voltage() or
list_voltage() callback on regulator driver.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add a resource managed regulator_get_exclusive()
Signed-off-by: NMatthias Kaehlcke <matthias@kaehlcke.net>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add define for __FAN53555_H__ to prevent multiple include of the header file.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch adds devicetree bindings for max8660, along with some
documentation.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

While the majority of supplies on devices are mandatory and can't be
physically omitted for electrical reasons some devices do have optional
supplies and need to know if they are missing, MMC being the most common
of these.

Currently the core accurately reports all errors when regulators are
requested since it does not know if the supply is one that must be provided
even if by a regulator software does not know about or if it is one that
may genuinely be disconnected. In order to allow this behaviour to be
changed and stub regulators to be provided in the former case add a new
regulator request function regulator_get_optional() which provides a hint
to the core that the regulator may genuinely not be connected.

Currently the implementation is identical to the current behaviour, future
patches will add support in the core for returning stub regulators in the
case where normal regulator_get() fails and the board has requested it.
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NMark Brown <broonie@linaro.org>