linux.git/drivers/regulator/core.c, branch v4.18

regulator: Revert coupled regulator support again

2018-05-30T14:20:28+00:00

Revert the last two commits of the voltage coupling mechanism patch set:

456e7cdf3b1a14e2606b8 regulator: core: Change voltage setting path
696861761a58d8c93605b regulator: core: Add voltage balancing mechanism

as they broke boot on OMAP again.

Reported-by: Tony Lindgren 
Signed-off-by: Mark Brown

regulator: core: Change voltage setting path

2018-05-17T07:05:51+00:00

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: Maciej Purski 
Signed-off-by: Mark Brown

regulator: core: Add voltage balancing mechanism

2018-05-17T07:05:50+00:00

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, don't change its voltage if it breaks 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: Maciej Purski 
Signed-off-by: Mark Brown

regulator: core: Resolve coupled regulators

2018-05-17T07:05:49+00:00

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.

Fill coupling descriptor with data obtained from DTS using previously
defined of_functions. Fail to register a regulator, if some data
inconsistency occurs. If some coupled regulators are not yet registered,
don't fail to register, but try to resolve them in late init call.

Signed-off-by: Maciej Purski 
Signed-off-by: Mark Brown

regulator: core: Make locks re-entrant

2018-05-17T07:05:03+00:00

Setting voltage, enabling/disabling regulators requires operations on
all regulators related with the regulator being changed. Therefore,
all of them should be locked for the whole operation. With the current
locking implementation, adding additional dependency (regulators
coupling) causes deadlocks in some cases.

Introduce a possibility to attempt to lock a mutex multiple times
by the same task without waiting on a mutex. This should handle all
reasonable coupling-supplying combinations, especially when two coupled
regulators share common supplies. The only situation that should be
forbidden is simultaneous coupling and supplying between a pair of
regulators.

The idea is based on clk core.

Signed-off-by: Maciej Purski 
Signed-off-by: Mark Brown

regulator: core: Allow for regulators that can't be read at bootup

2018-05-17T05:08:37+00:00

Regulators attached via RPMh on Qualcomm sdm845 apparently are
write-only.  Specifically you can send a request for a certain voltage
but you can't read back to see what voltage you've requested.  What
this means is that at bootup we have absolutely no idea what voltage
we could be at.

As discussed in the patches to try to support the RPMh regulators [1],
the fact that regulators are write-only means that its driver's
get_voltage_sel() should return an error code if it's called before
any calls to set_voltage_sel().  This causes problems in
machine_constraints_voltage() when trying to apply the constraints.

A proposed fix was to come up with an error code that could be
returned by get_voltage_sel() which would cause the regulator
framework to simply try setting the voltage with the current
constraints.

In this patch I propose the error code -ENOTRECOVERABLE.  In errno.h
this error is described as "State not recoverable".  Though the error
code was originally intended "for robust mutexes", the description of
the error code seems to apply here because we can't read the state of
the regulator.  Also note that the only existing user of this error
code in the regulator framework is tps65090-regulator.c which returns
this error code from the enable() call (not get_voltage() or
get_voltage_sel()), so there should be no existing regulators that
might accidentally get the new behavior.  (Side note is that tps65090
seems to interpret this error code to mean an error that you can't
recover from rather than some data that can't be recovered).

[1] https://patchwork.kernel.org/patch/10340897/

Signed-off-by: Douglas Anderson 
Signed-off-by: Mark Brown

Merge remote-tracking branches 'regulator/topic/88pg86x', 'regulator/topic/dt', 'regulator/topic/formatting' and 'regulator/topic/gpio' into regulator-next

2018-03-28T02:33:53+00:00

regulator: core: Add missing blank line between functions

2018-03-22T07:23:35+00:00

Signed-off-by: Mark Brown

regulator: Fix resume from suspend to idle

2018-02-20T12:37:43+00:00

When resuming from idle with the new suspend mode configuration support
we go through the resume callbacks with a state of PM_SUSPEND_TO_IDLE
which we don't have regulator constraints for, causing an error:

    dpm_run_callback(): regulator_resume_early+0x0/0x64 returns -22
    PM: Device regulator.0 failed to resume early: error -22

Avoid this and similar errors by treating missing constraints as a noop.

See also commit 57a0dd187956ea04 ("regulator: Fix suspend to idle"),
which fixed the suspend part.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown

regulator: core: Support passing an initialized GPIO enable descriptor

2018-02-16T17:04:02+00:00

We are currently passing a GPIO number from the global GPIO numberspace
into the regulator core for handling enable GPIOs. This is not good
since it ties into the global GPIO numberspace and uses gpio_to_desc()
to overcome this.

Start supporting passing an already initialized GPIO descriptor to the
core instead: leaf drivers pick their descriptors, associated directly
with the device node (or from ACPI or from a board descriptor table)
and use that directly without any roundtrip over the global GPIO
numberspace.

This looks messy since it adds a bunch of extra code in the core, but
at the end of the patch series we will delete the handling of the GPIO
number and only deal with descriptors so things end up neat.

Signed-off-by: Linus Walleij 
Signed-off-by: Mark Brown