The function signature of does not match regulator_get_error_flags()
when CONFIG_REGULATOR is not defined vs. when it is not defined.
This makes both declarations match to prevent compiler errors.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Regulator consumers can receive event notifications when
errors are reported to the driver, but currently, there is
no way for a regulator consumer to know when the error is over.

To allow a regulator consumer to poll for error conditions
add a new API: regulator_get_error_flags.
Signed-off-by: NAxel Haslam <ahaslam@baylibre.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The patch was based on my missinterpretation of the API and only
accidentally worked for me. Let's clean it out to not confuse others.

This reverts commit 3ff3f518.
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

There is little obvious use case for a regualtor driver to know if it is
possible to vary voltages at all by itself.  If a consumer needs to
limit what voltages it tries to set based on the system configuration
then it will need to enumerate the possible voltages, and without that
even if it is possible to change voltages that doesn't mean that
constraints or other consumers will allow whatever change the driver is
trying to do at a given time.  It doesn't even indicate if _set_voltage()
calls will work as noop _set_voltage() calls return success.

There were no users of this API that weren't abusing it and now they're
all gone so remove the API.
Signed-off-by: NMark Brown <broonie@kernel.org>

Cut down on noise for mainstream users of the API and people doing build
testing by dropping the deprecated flag from regulator_can_change_voltage()
as it triggers even on the EXPORT_SYMBOL_GPL() which affects all builds
rather than just the remaining drivers with calls to it (for which fixes
are currently pending).

The function remains deprecated and is expected to be removed entirely
in v4.8.
Signed-off-by: NMark Brown <broonie@kernel.org>

All current users of regulator_can_change_voltage() are abusing it,
using it to wrap a call to regulator_set_voltage() on probe without any
alternative handling for fixed voltages.  Drivers should only be using
regulator_set_voltage() if they need to vary voltages at runtime, fixed
voltages should normally be set via machine constraints, and calling
regulator_set_voltage() on a regulator which can't be varied will
succeed if the current voltage is within the range requested so users
shouldn't worry if they have permission to vary normally.

Deprecate the API to try to stop any new users appearing while we fix
the current callers.
Signed-off-by: NMark Brown <broonie@kernel.org>

Make it possible to use the bulk API with optional supplies, by allowing
the consumer to marking supplies as optional in the regulator_bulk_data.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Voltage tolerance isn't necessarily same on both sides of the target
voltage and regulator_set_voltage_tol() wouldn't be suitable in such
cases.

Add another routine regulator_set_voltage_triplet(), which accepts
target, min and max voltages as arguments.

This first tries to set the voltage between the target voltage and the
upper limit, then fall back on the full range. The idea behind this is
to set regulator's voltage as close to the target voltage, as possible.

Based on regulator_set_voltage_tol().
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fixes a build break when CONFIG_REGULATOR is not selected.

e.g, on linux-next - 07102015:

drivers/clk/tegra/clk-dfll.c: In function ‘find_lut_index_for_rate’:
drivers/clk/tegra/clk-dfll.c:691:3: error: implicit declaration of function ‘regulator_list_voltage’ [-Werror=implicit-function-declaration]
    if (regulator_list_voltage(td->vdd_reg, td->i2c_lut[i]) == uv)
    ^
   CC      drivers/clocksource/mmio.o
   CC      fs/proc/softirqs.o
cc1: some warnings being treated as errors
make[3]: *** [drivers/clk/tegra/clk-dfll.o] Error 1
make[2]: *** [drivers/clk/tegra] Error 2
make[1]: *** [drivers/clk] Error 2
make[1]: *** Waiting for unfinished jobs....

This should be pushed to 4.2 as we have the issue in 4.2-rc1, just that
nobody uses it without the REGULATOR(yet).
Signed-off-by: NSuzuki K. Poulose <suzuki.poulose@arm.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Rename the regulator_set_optimum_mode() function regulator_set_load() to
better represent what's going on.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add devm_regulator_register_notifier, this adds the resource against the
device for the consumer supply we are registering the notifier for. There
seem to be few use-cases where this wouldn't be the users intention and
this ensures the notifiers will always be removed at the correct time.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add a PRE_DISABLE notification so that consumers can use a
notifier to run any steps required to prepare for the
regulator being switched off. Since the regulator disable
can fail an abort notification is also added.
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The user hasn't got a regulator and shouldn't be mislead into thinking
they have one; really we should probably remove this stub entirely (and
may well before the next merge window).
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

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>

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>

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>

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>

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 a resource managed regulator_get_exclusive()
Signed-off-by: NMatthias Kaehlcke <matthias@kaehlcke.net>
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>

The expected semantic for something expressed as a tolerance is that it
should deliver the specified value with some deviation allowed but this
is not what set_voltage_tol() currently does. Instead it just passes
the maximum possible range to set_voltage() which will typically result
in a voltage aimed at lower than the target voltage.

Instead first try to set a voltage between the target voltage and the
upper limit, then fall back on the full range. This will be much more
robust against physical variation in systems and makes the API behave
more like users would expect.
Signed-off-by: NMark Brown <broonie@linaro.org>

Add regulator_get_linear_step(), which returns the voltage step size
between VSEL values for linear regulators.  This is intended for use
by regulator consumers which build their own voltage-to-VSEL tables.
Signed-off-by: NPaul Walmsley <pwalmsley@nvidia.com>
Reviewed-by: NAndrew Chew <achew@nvidia.com>
Cc: Matthew Longnecker <mlongnecker@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

It's generally important that devices have power when they expect it so
drivers really ought to be checking for errors on the power up paths.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Introduce a regulator_can_change_voltage() function for the subsytems or
drivers which might check if applying voltage change is possible and use
special workaround code when the driver is used with fixed regulators or
regulators with disabled ability to change the voltage.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

avoids needs for CONFIG_REGULATOR in sdhci.c
Signed-off-by: NPhilip Rakity <prakity@nvidia.com>
Reviewed-by: NEric Miao <eric.y.miao@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If consumers wish to set voltages based on a tolerance it stands to reason
that they will also want to query for support in the same manner.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Many regulators support a bypass mode where they simply switch their
input supply to the output. This is mainly used in low power retention
states where power consumption is extremely low so higher voltage or
less clean supplies can be used.

Support this by providing ops for the drivers and a consumer API which
allows the device to be put into bypass mode if all consumers enable it
and the machine enables permission for this.

This is not supported as a mode since the existing modes are rarely used
due to fuzzy definition and mostly redundant with modern hardware which is
able to respond promptly to load changes.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NGraeme Gregory <gg@slimlogic.co.uk>

There are some use cases where a voltage range could be reasonably
specified by a target voltage and tolerance.  Add a new API
regulator_set_voltage_tol() wrapping regulator_set_voltage() call
to ease the users.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This definition is missing when CONFIG_REGULATOR is not defined.
This causes compiler errors when compiling sdhci.c.  This can
be worked around by adding #ifdef CONFIG_REGULATOR .. #endif
but since other definitions are there we have defined the missing
definition
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Returning 0 isn't useful, it's not even meaningful if there is a real
regulator there.
Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The <linux/device.h> header includes a lot of stuff, and
it in turn gets a lot of use just for the basic "struct device"
which appears so often.

Clean up the users as follows:

1) For those headers only needing "struct device" as a pointer
in fcn args, replace the include with exactly that.

2) For headers not really using anything from device.h, simply
delete the include altogether.

3) For headers relying on getting device.h implicitly before
being included themselves, now explicitly include device.h

4) For files in which doing #1 or #2 uncovers an implicit
dependency on some other header, fix by explicitly adding
the required header(s).

Any C files that were implicitly relying on device.h to be
present have already been dealt with in advance.

Total removals from #1 and #2: 51.  Total additions coming
from #3: 9.  Total other implicit dependencies from #4: 7.

As of 3.3-rc1, there were 110, so a net removal of 42 gives
about a 38% reduction in device.h presence in include/*
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Commit d5ad34f7 "regulator: Implement devm_regulator_free()"
actually implements devm_regulator_put.
Thus rename devm_regulator_free to devm_regulator_put.

Also add empty devm_regulator_put for !CONFIG_REGULATOR
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This fixes below build error if CONFIG_REGULATOR is disabled.

  CC      sound/soc/codecs/wm5100.o
sound/soc/codecs/wm5100.c: In function ‘wm5100_i2c_probe’:
sound/soc/codecs/wm5100.c:2462: error: implicit declaration of function ‘devm_regulator_bulk_get’
make[3]: *** [sound/soc/codecs/wm5100.o] Error 1
make[2]: *** [sound/soc/codecs] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>