Check whether supply regulator is the couple to avoid infinite recursion
during of locking.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Wait/wound mutex shall be used in order to avoid lockups on locking of
coupled regulators.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Suggested-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Regulators shall be uncoupled if one of the couples disappear.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

On NVIDIA Tegra30 there is a requirement for regulator "A" to have voltage
higher than voltage of regulator "B" by N microvolts, the N value changes
depending on the voltage of regulator "B". This is similar to min-spread
between voltages of regulators, the difference is that the spread value
isn't fixed. This means that extra carefulness is required for regulator
"A" to drop its voltage without violating the requirement, hence its
voltage should be changed in steps so that its couple "B" could follow
(there is also max-spread requirement).

Add new "max_uV_step" constraint that breaks voltage change into several
steps, each step is limited by the max_uV_step value.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Don't allow to get regulator until all of its couples resolved because
consumer will get EPERM and coupling shall be transparent for the drivers.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

If registered regulator found a couple, then the couple can find the
registered regulator too and hence coupling can be mutually resolved
at the registration time.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread between
two devices' voltages is so high, that there is a risk of changing
'high' and 'low' states on the interconnection between devices powered
by those regulators.

Uncoupled regulators should be a special case of coupled regulators, so
they should share a common voltage setting path. When enabling,
disabling or setting voltage of a coupled regulator, all coupled
regulators should be locked. Regulator's supplies should be locked, when
setting voltage of a single regulator. Enabling a coupled regulator or
setting its voltage should not be possible if some of its coupled
regulators, has not been registered.

Add function for locking coupled regulators and supplies. Extract
a new function regulator_set_voltage_rdev() from
regulator_set_voltage_unlocked(), which is called when setting
voltage of a single regulator.
Signed-off-by: NMaciej Purski <m.purski@samsung.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread between
two devices' voltages is so high, that there is a risk of changing
'high' and 'low' states on the interconnection between devices powered
by those regulators.

Introduce new function regulator_balance_voltage(), which
keeps max_spread constraint fulfilled between a group of coupled
regulators. It should be called if a regulator changes its
voltage or after disabling or enabling. Disabled regulators should
follow changes of the enabled ones, but their consumers' demands
shouldn't be taken into account while calculating voltage of other
coupled regulators.

Find voltages, which are closest to suiting all the consumers' demands,
while fulfilling max_spread constraint, keeping the following rules:
- if one regulator is about to rise its voltage, rise others
  voltages in order to keep the max_spread
- if a regulator, which has caused rising other regulators, is
  lowered, lower other regulators if possible
- if one regulator is about to lower its voltage, but it hasn't caused
  rising other regulators, change its voltage so that it doesn't break the
  max_spread

Change regulators' voltages step by step, keeping max_spread constraint
fulfilled all the time. Function regulator_get_optimal_voltage()
should find the best possible change for the regulator, which doesn't
break max_spread constraint. In function regulator_balance_voltage()
optimize number of steps by finding highest voltage difference on
each iteration.

If a regulator, which is about to change its voltage, is not coupled,
method regulator_get_optimal_voltage() should simply return the lowest
voltage fulfilling consumers' demands.

Coupling should be checked only if the system is in PM_SUSPEND_ON state.
Signed-off-by: NMaciej Purski <m.purski@samsung.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Update the rest of the comment at the start of the file to also use C++
style comments to match the required style of the SPDX header.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

All the fields in struct bd718xx_pmic are not really necessary.
Remove struct bd718xx_pmic to simplify the code.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Since the core regulator code is treating GPIO descriptors as
nonexclusive, i.e. it assumes that the enable GPIO line may be
shared with several regulators, let's add the flag introduced
for fixing this problem on fixed regulators to all drivers
fetching GPIO descriptors to avoid possible regressions.
Reported-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This allows nonexclusive (simultaneous) access to a single
GPIO line for the fixed regulator enable line. This happens
when several regulators use the same GPIO for enabling and
disabling a regulator, and all need a handle on their GPIO
descriptor.

This solution with a special flag is not entirely elegant
and should ideally be replaced by something more careful as
this makes it possible for several consumers to
enable/disable the same GPIO line to the left and right
without any consistency. The current use inside the regulator
core should however be fine as it takes special care to
handle this.

For the state of the GPIO backend, this is still the
lesser evil compared to going back to global GPIO
numbers.

Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Jon Hunter <jonathanh@nvidia.com>
Fixes: efdfeb07 ("regulator: fixed: Convert to use GPIO descriptor only")
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Lochnagar is an evaluation and development board for Cirrus
Logic Smart CODEC and Amp devices. It allows the connection of
most Cirrus Logic devices on mini-cards, as well as allowing
connection of various application processor systems to provide a
full evaluation platform. This driver supports the board
controller chip on the Lochnagar board.

The Lochnagar board provides power supplies for the attached
CODEC/Amp device. Currently this driver supports the microphone
supplies and the digital core voltage for the attached
device. There are some additional supplies that will be
added in time but these supplies are sufficient for most
systems/use-cases.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

-EINVAL is not a valid return value for .of_map_mode, return
REGULATOR_MODE_INVALID instead.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The stpmic1 PMIC embeds several regulators and switches with
different capabilities.
Signed-off-by: Npascal paillet <p.paillet@st.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Notice that in this particular case, I moved the whole comment
"Fall through to the check below.", which contains the "Fall through"
comment, at the bottom of the case, which is what GCC is expecting
to find.

Addresses-Coverity-ID: 1436594 ("Missing break in switch")
Addresses-Coverity-ID: 1364475 ("Missing break in switch")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

commit efdfeb07
("regulator: fixed: Convert to use GPIO descriptor only")
switched to use gpiod_get() to look up the regulator from the
gpiolib core whether that is device tree or boardfile.

This meant that we activate the code in
a603a2b8 ("gpio: of: Add special quirk to parse regulator flags")
which means the descriptors coming from the device tree already
have the right inversion and open drain semantics set up from
the gpiolib core.

As the fixed regulator was inspected again we got the
inverted inversion and things broke.

Fix it by ignoring the config in the device tree for now: the
later patches in the series will push all inversion handling
over to the gpiolib core and set it up properly in the
boardfiles for legacy devices, but I did not finish that
for this kernel cycle.

Fixes: commit efdfeb07 ("regulator: fixed: Convert to use GPIO descriptor only")
Reported-by: NLeonard Crestez <leonard.crestez@nxp.com>
Reported-by: NFabio Estevam <festevam@gmail.com>
Reported-by: NJohn Stultz <john.stultz@linaro.org>
Reported-by: NAnders Roxell <anders.roxell@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

rename bd71837-regulator.c to bd718x7-regulator.c to reflect the
fact that also BD71847 is now supported by the driver.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Few regulators in BD71837 and BD71847 can output voltages from
different voltage ranges. Register interface is arranged so that
used range is selected by toggling bits which are not next to actual
voltage selection bits. Then the voltage inside selected range is
determined by voltage selection bits (as usual). Support BD71837
and BD71847 selectible range voltages using new pickable ranges
helpers.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Rename parts of code that support both BD71837 and BD71847 to BD718XX.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

For example ROHM BD71837 and ROHM BD71847 Power management ICs have
regulators which provide multiple linear ranges. Ranges can be
selected by individual non contagious bit in vsel register. Add
regmap helper functions for selecting ranges.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

BD71847 is reduced version of BD71837. DVS bucks 3 and 4 are
removed as is LDO7. Voltage ranges of some regulators are
expanded.

Add initial support for BD71847 with BD71837 driver.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/regulator/da9052-regulator.c:423:22: warning: address of array
'pdata->regulators' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (pdata && pdata->regulators) {
                  ~~ ~~~~~~~^~~~~~~~~~
drivers/regulator/da9055-regulator.c:615:22: warning: address of array
'pdata->regulators' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (pdata && pdata->regulators) {
                  ~~ ~~~~~~~^~~~~~~~~~

Link: https://github.com/ClangBuiltLinux/linux/issues/142Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The PMS405 provdies 5 SMPS regulators and 13 LDOs, add these to the RPM
regulator driver.
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NVinod Koul <vkoul@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

dev_set_drvdata() needs to be called before device_register()
exposes device to userspace. Otherwise kernel crashes after it
gets null pointer from dev_get_drvdata() when userspace tries
to access sysfs entries.

[Removed backtrace for length -- broonie]
Signed-off-by: NYu Zhao <yuzhao@google.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

0-Day tests found compilation error on x86. Driver won't
compile on x86_64 as "of_match_ptr" is not found. Add missing
include <linux/of.h>
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

As we augmented the regulator core to accept a GPIO descriptor instead
of a GPIO number, we can augment the fixed GPIO regulator to look up
and pass that descriptor directly from device tree or board GPIO
descriptor look up tables.

Some boards just auto-enumerate their fixed regulator platform devices
and I have assumed they get names like "fixed-regulator.0" but it's
pretty hard to guess this. I need some testing from board maintainers to
be sure. Other boards are straight forward, using just plain
"fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
device ID.

It seems the da9055 and da9211 has never got around to actually passing
any enable gpio into its platform data (not the in-tree code anyway) so we
can just decide to simply pass a descriptor instead.

The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named
"*_dummy_supply_device" while it is a very real device backed by a GPIO
line. There is nothing dummy about it at all, so I renamed it with the
infix *_regulator_* as part of this patch set.

Intel MID portions tested by Andy.

Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Check the x86 BCM stuff
Acked-by: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Reviewed-by: NMike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Trivial fix to spelling mistake in dev_info message
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

On some boards the SoC can use one pin "PMIC_STBY_REQ" to notify th PMIC
about state changes. In this case internal state of PMIC must be
preconfigured for upcomming state change.
It works fine with the current regulator framework, except with the
power-off case.

This patch is providing an optional pm_power_off_prepare handler
which will configure standby state of the PMIC to disable all power lines.

In my power consumption test on RIoTBoard, I got the following results:
power off without this patch:	320 mA
power off with this patch:	2   mA
suspend to ram:			40  mA
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Split regmap_config.use_single_rw into use_single_read and
use_single_write. This change enables drivers of devices which only
support bulk operations in one direction to use the regmap_bulk_*()
functions for both directions and have their bulk operation split into
single operations only when necessary.

Update all struct regmap_config instances where use_single_rw==true to
instead set both use_single_read and use_single_write. No attempt was
made to evaluate whether it is possible to set only one of
use_single_read or use_single_write.
Signed-off-by: NDavid Frey <dpfrey@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fix kernel-doc warning:

../drivers/regulator/core.c:4479: warning: Excess function parameter 'state' description in 'regulator_suspend'
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

regulator_pm_ops with regulator_suspend and regulator_resume functions are
assigned to every regulator device registered in the system, so there is no
need to iterate over all again in them. Replace class_for_each_device()
construction with direct operation on the rdev embedded in the given
regulator device. This saves a lots of useless operations in suspend and
resume paths.

Fixes: f7efad10: regulator: add PM suspend and resume hooks
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some regulators don't have all states defined and in such cases regulator
core should not assume anything. However in current implementation
of of_get_regulation_constraints() DO_NOTHING_IN_SUSPEND enable value was
set only for regulators which had suspend node defined, otherwise the
default 0 value was used, what means DISABLE_IN_SUSPEND. This lead to
broken system suspend/resume on boards, which had simple regulator
constraints definition (without suspend state nodes).

To avoid further mismatches between the default and uninitialized values
of the suspend enabled/disabled states, change the values of the them,
so default '0' means DO_NOTHING_IN_SUSPEND.

Fixes: 72069f99: regulator: leave one item to record whether regulator is enabled
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

There is a HW quirk in BD71837. The shutdown sequence timings for
bucks/LDOs which are enabled via register interface are changed.
At PMIC poweroff the voltage for BUCK6/7 is cut immediately at the
beginning of shut-down sequence. This causes LDO5/6 voltage
monitoring to detect under voltage and force PMIC to emergency
state instead of poweroff. Disable voltage monitoring for LDO5 and
LDO6 at probe to avoid this.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

No functional change here but it can make the code more readable to
have breaks in the "default" case even though it's the last case.
Let's add them.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDavid Collins <collinsd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Most functions that access the rdev lock the rdev mutex before looking
at data.  ...but not the code that implements the debugfs
regulator_summary.  It probably should though, so let's do it.

Note: this fixes no known issues.  The problem was found only by code
inspection.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

It's handy to see the load requested by a regulator consumer in the
regulator_summary.  Add it.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

It's handy to know what opmode a regulator has been configured to in
the summary.  Add it.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Don't give up voltage mapping if first range with suitable min/max uV
does not provide the wanted voltage.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Set it once is enough.
Also move n_voltages close to volt_table for better readability.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>