Allow drivers to benefit from both the bulk APIs and managed resources
simultaneously.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Allow consumers to free regulators allocated using devm_regulator_get()
if they need to. This will not normally be required.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Add a resource managed regulator_get() to simplify regulator
usage in drivers. This allows driver authors to "get and forget"
about their regulators by automatically calling regulator_put()
when the driver is detached.

[Fixed up a couple of coding style issues -- broonie]
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch allows consumers to forcibly disable multiple regulator
clients in a single API call.
Signed-off-by: NDonggeun Kim <dg77.kim@samsung.com>
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

regulator_force_disable() was omitted in consumer.h for
!CONFIG_REGULATOR case.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.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>

Fix kernel-doc warning about internal/private data by marking it
as "private:" so that kernel-doc will ignore it.

  Warning(include/linux/regulator/consumer.h:128): No description found for parameter 'ret'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix kernel-doc warning about internal/private data by marking it
as "private:" so that kernel-doc will ignore it.

Warning(include/linux/regulator/consumer.h:128): No description found for parameter 'ret'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

In order to reduce the impact of ramp times rather than enabling the
regulators for a device in series use async tasks to run the actual
enables. This means that the delays which the enables implement can all
run in parallel, though it does mean that the order in which the
supplies come on may be unstable.

For super bonus fun points if any of the regulators are shared between
multiple supplies on the same device (as is rather likely) then this
will test our locking.  Note that in this case we only delay once for
each physical regulator so the threads shouldn't block each other while
delaying.

It'd be even nicer if we could coalesce writes to a shared enable registers
in PMICs but that's definitely future work, and it may also be useful
and is certainly more achievable to optimise out the parallelism if none
of the regulators implement ramp delays.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

This exposes the functionality for rise/fall fime when setting
voltage to the consumers.

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>

When cooperating with an external control source the regulator setup
may be changed underneath the API. Currently consumers can just redo
the regulator_set_voltage() to restore a previously set configuration
but provide an explicit API for doing this as optimsations in the
regulator_set_voltage() implementation will shortly prevent that.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Have the stub variant of regulator_get() return NULL, so that drivers
can (but still don't have to) handle this case specifically.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Jerome Oufella <jerome.oufella@savoirfairelinux.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

The intended use case is for drivers which disable regulators to save
power but need to do some work to restore the hardware state when
restarting.  If the supplies are not actually disabled due to board
limits or sharing with other active devices this notifier allows the
driver to avoid unneeded reinitialisation, particularly when used with
runtime PM.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

consumer.h requires device.h for stand alone build.
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Simplify checking of support for voltage ranges by providing an API which
wraps the existing count and list operations.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Some consumers require complete control of the regulator and can't
tolerate sharing it with other consumers, most commonly because they need
to have the regulator actually disabled so can't have other consumers
forcing it on. This new regulator_get_exclusive() API call allows these
consumers to explicitly request this, documenting the assumptions that
they are making.

In order to simplify coding of such consumers the use count for regulators
they request is forced to match the enabled state of the regulator when
it is requested. This is not possible for consumers which can share
regulators due to the need to keep track of the ownership of use counts.

A new API call is used rather than an additional argument to the existing
regulator_get() in order to avoid merge headaches with driver code in
other trees.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Add a basic mechanism for regulators to report the discrete
voltages they support:  list_voltage() enumerates them using
selectors numbered from 0 to an upper bound.

Use those methods to force machine-level constraints into bounds.
(Example:  regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board
constraints for that rail are 2.0V to 3.6V ... so the range of
voltages is then 2.4V to 3.3V on this board.)

Export those voltages to the regulator consumer interface, so for
example regulator hooked up to an MMC/SD/SDIO slot can report the
actual voltage options available to cards connected there.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Remove deceased email address and update to new address. Also update
website details in MAINTAINERS with correct page.
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Regulator: Push lock out of _notifier_call_chain and into caller functions
(side effect of fixing deadlock in regulator_force_disable)
+ Add a voltage changed event.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Remove kerneldoc warnings that don't relate to missing documentation,
mostly by renaming parameters in the documentation to match their
actual names.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Add support to allow consumer device drivers to control their regulator
power supply.

This uses a similar API to the kernel clock interface in that consumer
drivers can get and put a regulator (like they can with clocks atm) and
get/set voltage, current limit, mode, enable and disable. This should
allow consumers complete control over their supply voltage and current
limit. This also compiles out if not in use so drivers can be reused in
systems with no regulator based power control.
Signed-off-by: NLiam Girdwood <lg@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>