The regulators set consists of 2 BUCKs and 2 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components. The ramp delay is configurable
for both BUCKs.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some of platforms like Nvidia's Tegra210 Jetson-TX1 platform has
multiple PMW based regulators. Add support to have multiple instances
of the driver by not changing any global data of pwm regulator and
if required, making instance specific copy and then making changes.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

With following equation for calculating
voltage_to_duty_cycle_percentage
	100 - (((req_uV * 100) - (min_uV * 100)) / diff);

we get 0% for max_uV and 100% for min_uV.

Correcting this to
	((req_uV * 100) - (min_uV * 100)) / diff;
 to get proper duty cycle.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

OF interface provides to read the u32 value via standard interface
of_property_read_u32(). Use this API to read "regulator-min-microvolts"
and "regulator-max-microvolt".

This will make consistent with other property value reads.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is a patch to fix incorrect clear of event register.
Signed-off-by: NJames Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is a patch to fix incorrect clear of event register.
Signed-off-by: NJames Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add regulator ops callback for configuration of active-discharge
and provide necessarily information via regulator descriptor.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add helper function to set the state of active-discharge of
regulator using regmap. The HW regulator driver can directly
use this by providing the necessary information in the regulator
descriptor.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The documentation lists both 1.8V and 3.3V for this regulator output,
but 3.3V is mentioned more often and also matches what JZ4770 and
JZ4780 expect as an input.

Note that the voltage of REG9 is not programmable, so this commit only
changes the voltage reported in sysfs and debugfs, not the actual
output voltage of the hardware.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Make the field name match its type.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

There is no need to preserve its value between calls. I guess this
was a copy-paste slip-up.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The same alias is already in .id_table.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

These fields are never used and not required at all, remove them.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This problem was introduced by:
commit daad134d ("regulator: core: Request GPIO before creating
sysfs entries")

The error path was not updated correctly after moving GPIO registration
code and in case regulator_ena_gpio_free failed, device_unregister() was
called even though device_register() was not yet called.

This problem breaks the boot at least on all Tegra 32-bit devices. It
will also crash each device that specifices GPIO that is unavaiable at
regulator_register call. Here's error log I've got when forced GPIO to
be invalid:

[    1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22
[    1.122794] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
[    1.130894] pgd = c0004000
[    1.133598] [00000044] *pgd=00000000
[    1.137205] Internal error: Oops: 5 [#1] SMP ARM

and here's backtrace from KDB:

Exception stack(0xef11fbd0 to 0xef11fc18)
fbc0:                                     00000000 c0738a14 00000000 00000000
fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c
fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff
[<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8)
[<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58)
[<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68)
[<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c)
[<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4)
[<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c)
[<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac)
[<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84)
[<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0)
[<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0)
[<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440)
[<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120)
[<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98)
[<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138)
[<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20)
[<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c)
[<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc)
[<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454)
[<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510)
[<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104)
[<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c)
Signed-off-by: NKrzysztof Adamski <krzysztof.adamski@tieto.com>
Reported-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NJon Hunter <jonathanh@nvidia.com>
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

regulator_attr_is_visible (which is a .is_visible callback of
regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if
"status" file should be present in sysfs. This field is set at the end
of regulator_ena_gpio_request so it has to be called before
device_register() otherwise this test will always fail, causing "status"
file to not be visible.

Since regulator_attr_is_visible also tests for is_enabled() op, this
problem is only visible for regulators that does not define this
callback, like regulator-fixed.c.
Signed-off-by: NKrzysztof Adamski <krzysztof.adamski@tieto.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Don't print out an error with the driver sees EPROBE_DEFER when
attempting to get the gpio.  These errors are usually transient; the
probe will be retried later.
Signed-off-by: NRabin Vincent <rabin.vincent@axis.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Remove the s2mps11_info.rdev_num because it is not used outside of
probe.
Suggested-by: NAndi Shyti <andi.shyti@samsung.com>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NAndi Shyti <andi.shyti@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

i2c_master_send() returns the number of bytes written on success.
So current code returns 2 if ad5398_write_reg() success.
This return value is propagated to .set_current_limit, .enable and .disable
callbacks of regulator_ops. This can be a problem, for example, if the
users test if the return value of regulator_set_current_limit() is 0.
Fix it by making ad5398_write_reg() return 0 on success.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

MAXIM Semiconductor's PMIC, MAX77620 and MAX20024 have the
multiple DCDC and LDOs. This supplies the power to different
components of the system.
Also these rails has configuration for ramp time, flexible
power sequence, slew rate etc.

Add regulator driver to access these rails via regulator APIs.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMallikarjun Kasoju <mkasoju@nvidia.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Following BUILD_BUG_ON using a variable fails for some of the compilers
and optimization levels (reported for gcc 4.9):
	var = ARRAY_SIZE(s2mps15_regulators);
	BUILD_BUG_ON(S2MPS_REGULATOR_MAX < var);
Fix this by using ARRAY_SIZE directly.

Additionally add missing BUILD_BUG_ON check for S2MPS15 device (the
check ensures that internal arrays are big enough to hold data for all
of regulators on all devices).
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The s5m8767_pmic_probe() function calls s5m8767_get_register() to
read data without checking the return code, which produces a compile-time
warning when that data is accessed:

drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This changes the s5m8767_get_register() function to return a -EINVAL
not just for an invalid register number but also for an invalid
regulator number, as both would result in returning uninitialized
data. The s5m8767_pmic_probe() function is then changed accordingly
to fail on a read error, as all the other callers of s5m8767_get_register()
already do.

In practice this probably cannot happen, as we don't call
s5m8767_get_register() with invalid arguments, but the gcc
warning seems valid in principle, in terms writing safe
error checking.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 9c4c6055 ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap")
Signed-off-by: NMark Brown <broonie@kernel.org>

The vexpress regulator implementation is currently just called vexpress.
This is a problem because it clashes with another module with the same
name in hardware monitors.

This patch renames the vexpress regulator implementation to
vexpress-regulator so that there will be no clash in the module namespace.

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Reported-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Originally the helper macros used uppercase regulator names, which
are primarily used to expand to the regulator ID enum, as the default
names. This is aestheticly unpleasent.

Since the of_match bits are the same, just lowercase, use that as the
default names instead.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add the regulator driver for hi655x PMIC.
Signed-off-by: NChen Feng <puck.chen@hisilicon.com>
Signed-off-by: NFei Wang <w.f@huawei.com>
Signed-off-by: NXinwei Kong <kong.kongxinwei@hisilicon.com>
Reviewed-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

It's perfectly valid to use the LTC3589 without an interrupt pin
connected to it. Currently, the driver probing fails when client->irq
is 0 (which means "no interrupt"). Don't register the interrupt
handler in that case but successfully finish the device probing instead.
Signed-off-by: NBernhard Walle <bernhard@bwalle.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The max77686 and max77802 regulator drivers are for sub-devices of a MFD
driver for some PMIC blocks. But the same object file name (max77686.o)
was used for both the common MFD driver and the max77686 regulator one.

This confuses kbuild if both drivers are built as module causing the MFD
driver to not be copied when installing the modules.

Also, max77{686,802} are a quite generic name for MFD subdevices drivers
so it is better to rename them to max77{686,802}-regulator like it's the
case for most regulator drivers.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This patch adds support for TPS65912 PMIC regulators.

The regulators set consists of 4 DCDCs and 10 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The old tps65912 driver is being replaced, delete old driver.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

LP872x regulators are made active via the EN pin, which might be hooked to a
GPIO. This adds support for driving the GPIO high when the driver is in use.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some devices don't hook the DVS pin to a GPIO but to ground or VCC.
In those cases, it is not a problem to have no DVS GPIO provided, as the current
code will already switch to software-only DVS selection:

When the DVS GPIO is invalid, lp872x_init_dvs jumps to the set_default_dvs_mode
label, which instructs the chip not to use the DVS pin at all and do it all in
software instead (by clearing the LP8720_EXT_DVS_M bit in the
LP872X_GENERAL_CFG register).

That is reflected later in the code, when setting the bucks (the DVS pin only
applies to the bucks) by checking for the LP8720_EXT_DVS_M bit on the
LP872X_GENERAL_CFG register (in lp872x_select_buck_vout_addr) to decide whether
to use software or hardware DVS selection.

Thus, there is no need to print a warning when the DVS GPIO is invalid.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch adds new regulator driver to support ACT8945A MFD
chip's regulators.

The ACT8945A has three step-down DC/DC converters and four
low-dropout regulators.
Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

AXP20X datasheet lists the possible voltage settings for LDO4, so
it was implemented using a voltage table. Upon closer examination,
the valid voltages can be mapped into 3 linear ranges.

Move AXP20X LDO4 to use linear ranges. The supporting code can be
reused with later AXP8xx PMICs, which have a number of regulators
that have 2 linear ranges.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Switch-type regulators, such as DC1SW on AXP22X, are a secondary output
from DCDC1. They are just an on/off switch, and the driver should not
try to read its voltage directly from the DCDC1 control registers.

Instead, the core will pass down the voltage from the regulator supply
chain.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The Documentation/devicetree/bindings/regulator/mt6397-regulator.txt doc
mentions that a compatible "mediatek,mt6397-regulator" is required for
the MT6397 device node but the driver doesn't provide a OF match table so
the platform bus .match fallbacks to match using the driver name instead.

This also means that module auto-loading is broken for this driver since
the MFD driver that register the device, has a .of_compatible set so the
platform .uevent callback reports a OF modalias that's not in the module.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The platform bus_type .match callback attempts to match the platform device
name with an entry on the .id_table if provided and fallbacks to match with
the driver's name if a table is not provided.

Using a platform device ID to match is more explicit, allows the driver to
support more than one device and also the MODULE_DEVICE_TABLE macro can be
used to export the module aliases information instead of the MODULE_ALIAS.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

As we now free the constraints in regulator_dev_release we will still
call free on the constraints pointer even if we went down an error
path in regulator_register, because it is only allocated after the
device_register. As such we no longer need to free rdev->constraints
on the error paths, so this patch removes said frees.

Fixes: 29f5f486 ("regulator: core: Move more deallocation into class unregister")
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>