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

da9052_regulator_info and da9053_regulator_info are not used outside
this driver so no need to make the symbol global.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Reported-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NDavid Dajun Chen <dchen@diasemi.com>
Signed-off-by: NAshish Jangam <ashish.jangam@kpitcummins.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The Dialog PMIC has below featured regulators:-
DA9052-BC - 4 DVS Buck converters 0.5V - 3.6V upto 1Amp.
DA9053-AA/BX - 4 DVS Buck converters 0.5V - 2.5V upto 3Amp.
DA9052/53 - 10 Programmable LDO's High PSSR, 1% accuracy.

This patch support all the DA9052 and Da9053 regulators. The output voltages are
fully programmable via I2C or SPI interface. The platform data with regulation
constraints is passed down from the board to the regulator.
Signed-off-by: NDavid Dajun Chen <dchen@diasemi.com>
Signed-off-by: NAshish Jangam <ashish.jangam@kpitcummins.com>
Tested-by: NYing-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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: NShawn Guo <shawn.guo@linaro.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>

This allows read-only access to the device configuration which may be
useful for diagnostics.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

SMPS regulator voltage control differs from the one of the LDO ones.
Current TWL code was using LDO regulator ops for controlling the SMPS
regulators, which fails. This was fixed fixed by adding separate
regulator type which uses correct logic and calculations for the
voltage levels.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org

This is caused by dereferencing 'rdev' after device_unregister() in
the regulator_unregister() function.  'rdev' is freed by
device_unregister(), so it must not be dereferenced after this call.

[Edited commit message for legibility -- broonie]
Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch converts virtual and userspace regulator consumer drivers to use the
module_platform_driver() macro which makes the code smaller and a bit simpler.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The implementation in aat2870_update() already did the bitwise and operation
against mask parameter.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In current implementation, the pointer ri is not NULL if no id is matched.
Fix it by checking i == ARRAY_SIZE(aat2870_regulators) if no id is matched.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org

of_get_fixed_voltage_config() may return NULL, return -ENOMEM in this case
so we don't dereference NULL pointer.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

It is not used outside this driver so no need to make the symbol global.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

of_get_regulator_init_data() may return NULL, thus
check the return value to avoid NULL pointer dereference.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The commit 2c043bcb ("regulator: pass additional of_node to
regulator_register()") caused a compile break because it missed
updating the regulator_register() call in gpio-regulator.c with
the additional parameter (NULL).

The compile break as reported by Stephen Rothwell with the
x86_64 allmodconfig looked like this

drivers/regulator/gpio-regulator.c: In function 'gpio_regulator_probe':
drivers/regulator/gpio-regulator.c:287:8: error: too few arguments to function 'regulator_register'
include/linux/regulator/driver.h:215:23: note: declared here
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NRajendra Nayak <rnayak@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>

The fixed regulator driver uses of_get_fixed_voltage_config()
to extract fixed_voltage_config structure contents from device tree.

Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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

Count of selector voltage is required for regulator_set_voltage
to work via set_voltage_sel. VDD1/2 currently have it as zero,
so regulator_set_voltage won't work for VDD1/2.
Update count (n_voltages) for VDD1/2.

Output Voltage = (step value * 12.5 mV + 562.5 mV) * gain

With above expr, number of voltages that can be selected is
step value count * gain count

constant for gain count will be called VDD1_2_NUM_VOLT_COARSE

existing constant for step value count is VDD1_2_NUM_VOLTS,
use VDD1_2_NUM_VOLT_FINE instead to make clear that step value
is not the only component in deciding selectable voltage count
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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

If we don't know what voltage the regulator is set to return an error
rather than reporting zero volts.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Create an array of fixed size for the platform to pass regulator
initalization data through.

Passing an array of pointers to init data also allows more flexible
definition of init data as well as prevents reading past the end of the
array should the platform define an incorrectly sized array.
Signed-off-by: NKyle Manna <kyle.manna@fuel7.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Move the regulator defintions to the header so that platform board file
can use them to configure specific regulators.
Signed-off-by: NKyle Manna <kyle.manna@fuel7.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NJonghwan Choi <jhbird.choi@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Current driver had the regmapcalls within the bodies of the driver specific read/write fuctions.
This patch removes the original read/write functions and makes the call sites use regmap directly.
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Another group of drivers that are taking advantage of the implicit
presence of module.h -- and will break when we pull the carpet out
from under them during a cleanup.  Fix 'em now.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

So that THIS_MODULE is still in scope once we clean up the presence
of module.h being everywhere.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Now that we have a shared API between the DB8500 and DB5500
PRCMU's, switch to using this neutral API instead. We delete the
parts of db8500-prcmu.h that is now PRCMU-neutral, and calls will
be diverted to respective driver. Common registers are in
dbx500-prcmu-regs.h and common accessors and defines in
<linux/mfd/dbx500-prcmu.h> This way we get a a lot more
abstraction and code reuse.
Signed-off-by: NMattias Nilsson <mattias.i.nilsson@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

In the case where _regulator_enable returns an error it was not checked
if a supplying regulator exists before trying to disable it, leading
to a null pointer-dereference if no supplying regulator existed.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Without GENERIC_GPIO "struct gpio" is undefined leading to errors.
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch adds support for regulators that can be controlled via gpios.

Examples for such regulators are the TI-tps65024x voltage regulators
with 4 fixed and 1 runtime-switchable voltage regulators
or the TI-bq240XX charger regulators.

The number of controlling gpios is not limited, the mapping between
voltage/current and target gpio state is done via the states map
and the driver can be used for either voltage or current regulators.

A mapping for a regulator with two GPIOs could look like:

gpios = {
	{ .gpio = GPIO1, .flags = GPIOF_OUT_INIT_HIGH, .label = "gpio name 1" },
	{ .gpio = GPIO2, .flags = GPIOF_OUT_INIT_LOW,  .label = "gpio name 2" },
}

The flags element of the gpios array determines the initial state of
the gpio, set during probe. The initial state of the regulator is also
calculated from these values

states = {
	{ .value = volt_or_cur1, .gpios = (0 << 1) | (0 << 0) },
	{ .value = volt_or_cur2, .gpios = (0 << 1) | (1 << 0) },
	{ .value = volt_or_cur3, .gpios = (1 << 1) | (0 << 0) },
	{ .value = volt_or_cur4, .gpios = (1 << 1) | (1 << 0) },
}

The target-state for the n-th gpio is determined by the n-th bit
in the bitfield of the target-value.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

There are two sets of defines for the REG_CTRL2 bitfields and one
of them has TPS65023_REG_CTRL2_DCDC1 defined incorrectly. Remove
the duplicates and leave the correct one for TPS65023_REG_CTRL2_DCDC1.

This fixes the following sparse warnings:

drivers/regulator/tps65023-regulator.c:77:9: warning: preprocessor token TPS65023_REG_CTRL2_DCDC1 redefined
drivers/regulator/tps65023-regulator.c:70:9: this was the original definition
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The WM1811 has a slightly different range on LDO2 to other WM8994 class
devices.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

schedule_delayed_work() returns a bool indicating if the work was already
queued when it succeeds so we need to squash a true down to zero.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>