The new op is analogous to set_voltage_time_sel. It can be used by
regulators which don't have a table of discrete voltages. The function
returns the time for the regulator output voltage to stabilize after
being set to a new value, in microseconds. If the op is not set a
default implementation is used to calculate the delay.

This change also removes the ramp_delay calculation in the PWM
regulator, since the driver now uses the core code for the calculation
of the delay.
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Using a bitfield enables the compiler to lay out the structure more
efficiently when we have other boolean flags since multiple values can
be included in a single byte.
Signed-off-by: NMark Brown <broonie@kernel.org>

Over current protection is missing descriptions for documentation.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Members csel_reg and csel_mask of the regulator_desc struct are missing
descriptions for documentation. Adding them.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.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>

Add support for TPS65218 LS3 current regulator, which is capable of 4
current input limit modes: 100, 200, 500, and 1000 uA.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: NMark Brown <broonie@kernel.org>

Many voltage Regulators need a input voltage that is higher than the
output voltage. Allow to specify a minimum dropout voltage which will
be used later to find the best input voltage for regulators.

[Changed uv to uV for consistency and legibility -- broonie]
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some regulators can automatically shut down when they detect an
over current event. Add an op (set_over_current_protection) and a
DT property + constraint to support this capability.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The docbook for these members is missing. Add them.

Warning(include/linux/regulator/machine.h:147): No description
found for parameter 'soft_start'
Warning(include/linux/regulator/driver.h:197): No description
found for parameter 'set_soft_start'
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some regulators can limit their input current (typically annotated
as ilim). Add an op (set_input_current_limit) and a DT property +
constraint to support this.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some regulators support a "soft start" feature where the voltage
ramps up slowly when the regulator is enabled. Add an op
(set_soft_start) and a DT property + constraint to support this.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some regulators need to be configured to pull down a resistor
when the regulator is disabled. Add an op (set_pull_down) and a
DT property + constraint to support this.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Instead of resolving regulator supplies during registration move this to
the time of a consumer retrieving a handle. The benefit is that it's
possible for one driver to register regulators with internal
dependencies out of order.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

dev_get_regulator() does not exist, fix the typo.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Expose the requested load directly to the regulator implementation for
hardware that does not support the normal enum based set_mode().
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When drivers use simplified DT parsing method (they provide
'regulator_desc.of_match') they still may want to parse custom
properties for some of the regulators. For example some of the
regulators support GPIO enable control.

Add a driver-supplied callback for such case. This way the regulator
core parses common bindings offloading a lot of code from drivers and
still custom properties may be used.

The callback, called for each parsed regulator, may modify the
'regulator_config' initially passed to regulator_register().
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The "regulator-initial-mode" and "regulator-mode" DT properties allows
to configure the regulator operating modes at startup or when a system
enters into a susend state.

But these properties use as valid values the operating modes supported
by each device while the core deals with the standard operating modes.
So a mapping function is needed to translate from the hardware specific
modes to the standard ones.

This mapping is a non-varying configuration for each regulator, so add
a function pointer to struct regulator_desc that will allow drivers to
define their callback to do the modes translation.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NMark Brown <broonie@kernel.org>

Most drivers do not set the ena_gpio field of struct regulator_config
before passing it to the regulator core. This is fine as long as the
gpio identifier that is passed is a positive integer. But the gpio
identifier 0 is also valid. So we are not able to decide wether we got a
real gpio identifier or not based on a 0 in ena_gpio.

To be able to decide if it is a valid gpio that got passed, this patch
adds a ena_gpio_initialized field that should be set if was initialized
with a correct value, either a gpio >= 0 or a negative error number. The
core then checks if ena_gpio or ena_gpio_initialized before handling it
as a gpio. This way we maintain backwards compatibility and fix the
behaviour for gpio number 0.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
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>

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>

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 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>

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>

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 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>

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>