Change suspend_late ops to suspend normal ops. The goal is to avoid
requesting all the regulator drivers to be operational in suspend late
phase.
Signed-off-by: pascal paillet <p.paillet@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Revert the last two commits of the voltage coupling mechanism patch set:
456e7cdf3b regulator: core: Change voltage setting path
696861761a regulator: core: Add voltage balancing mechanism
as they broke boot on OMAP again.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark 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: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Mark 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, 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 <m.purski@samsung.com>
Signed-off-by: Mark 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.
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 <m.purski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <m.purski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
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 57a0dd1879 ("regulator: Fix suspend to idle"),
which fixed the suspend part.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When suspending to idle with the new suspend mode configuration support
we go through the suspend callbacks with a state of PM_SUSPEND_TO_IDLE
which we don't have regulator constraints for, causing an error. Avoid
this and similar errors by treating missing constraints as a noop.
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
3d67fe9507 (regulator: core: Refactor regulator_list_voltage()) missed
one user of regulator_list_voltage(), update for that.
Signed-off-by: Mark Brown <broonie@kernel.org>
Change _regulator_list_voltage() argument from regulator to
regulator_dev in order to provide better separation of core layers.
Allow calling _regulator_list_voltage() from functions, with
regulator_dev argument. This refactoring is needed in order to
implement setting voltage of coupled regulators.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As of_find_regulator_by_node() is an of function it should be moved from
core.c to of_regulator.c. It provides better separation of device tree
functions from the core and allows other of_functions in of_regulator.c
to resolve device_node to regulator_dev. This will be useful for
implementation of parsing coupled regulators properties.
Declare of_find_regulator_by_node() function in internal.h as well as
regulator_class and dev_to_rdev(), as they are needed by
of_find_regulator_by_node().
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In this patch, consumers are allowed to set suspend voltage, and this
actually just set the "uV" in constraint::regulator_state, when the
regulator_suspend_late() was called by PM core through callback when
the system is entering into suspend, the regulator device would act
suspend activity then.
And it assumes that if any consumer set suspend voltage, the regulator
device should be enabled in the suspend state. And if the suspend
voltage of a regulator device for all consumers was set zero, the
regulator device would be off in the suspend state.
This patch also provides a new function hook to regulator devices for
resuming from suspend states.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Regualtor suspend/resume functions should only be called by PM suspend
core via registering dev_pm_ops, and regulator devices should implement
the callback functions. Thus, any regulator consumer shouldn't call
the regulator suspend/resume functions directly.
In order to avoid compile errors, two empty functions with the same name
still be left for the time being.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The items "disabled" and "enabled" are a little redundant, since only one
of them would be set to record if the regulator device should keep on
or be switched to off in suspend states.
So in this patch, the "disabled" was removed, only leave the "enabled":
- enabled == 1 for regulator-on-in-suspend
- enabled == 0 for regulator-off-in-suspend
- enabled == -1 means do nothing when entering suspend mode.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulator consumers would like to make the regulator device
keeping a voltage range output when the system entering into
suspend states.
Making regulator voltage be an array can allow consumers to set voltage
for normal state as well as for suspend states through the same code.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove extraneous space to fix indentation on a couple of assignment
statements.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A race condition between queueing and processing the disable_work
instances results in having a work instance in the queue and the
deferred_disables variable of regulator device structure having a
value '0'. If no new regulator_disable_deferred() call later from
clients, the deferred_disables variable value remains '0' and hits
BUG() in regulator_disable_work() when the queued instance scheduled
for processing the work.
The race occurs as below:
Core-0 Core-1
..... /* deferred_disables = 2 */ .....
..... /* disable_work is queued */ .....
..... .....
regulator_disable_deferred: regulator_disable_work:
mutex_lock(&rdev->mutex); .....
rdev->deferred_disables++; .....
mutex_unlock(&rdev->mutex); .....
queue_delayed_work(...) mutex_lock(&rdev->mutex);
..... count =rdev->deferred_disables;
..... rdev->deferred_disables = 0;
..... .....
..... mutex_unlock(&rdev->mutex);
..... .....
..... return;
..... .....
/* No new regulator_disable_deferred() calls from clients */
/* The newly queued instance is scheduled for processing */
..... .....
regulator_disable_work:
.....
mutex_lock(&rdev->mutex);
BUG_ON(!rdev->deferred_disables); /* deferred_disables = 0 */
The race is fixed by removing the work instance that is queued while
processing the previous queued instance. Cancel the newly queued instance
from disable_work() handler just after reset the deferred_disables variable
to value '0'. Also move the work queueing step before mutex_unlock in
regulator_disable_deferred().
Also use mod_delayed_work() in the pace of queue_delayed_work() as
queue_delayed_work() always uses the delay requested in the first call
when multiple consumers call regulator_disable_deferred() close in time
and does not guarantee the semantics of regulator_disable_deferred().
Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Now the debugfs file supply_map has a size limit PAGE_SIZE and the user
can not see the whole content of regulator_map_list when it is larger
than this limit.
This patch uses seq_file instead to make sure supply_map shows the full
information of regulator_map_list.
Signed-off-by: Haishan Zhou <zhssmail@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators support get_voltage() and some support get_voltage_sel()
operations but currently we only propagate changes if the regulator has
a get_voltage() operation. Also do this if we've got get_voltage_sel()
[Rewite commit message for clarity -- broonie]
Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, when looking up a regulator supply, the regulator name
takes priority over the consumer mappings. As there are a lot of
regulator names that are in fairly common use (VDD, MICVDD, etc.) this
can easily lead to obtaining the wrong supply, when a system contains
two regulators that share a name.
The explicit consumer mappings contain much less ambiguity as they
specify both a name and a consumer device. As such prioritise those if
one exists and only fall back to the regulator name if there are no
matching explicit mappings.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators have different settling times for voltage increases and
decreases. To avoid a time penalty on the faster transition allow for
different settings for up- and downward transitions.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Rather than just not resolving the supply when there is explicitly no
supply mapping fall through and allow a dummy supply to be substituted.
This fixes issues with constant retries reported by Dong Aisheng.
Signed-off-by: Mark Brown <broonie@kernel.org>
Tested-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
When we are propagating voltage changes to parent regulators don't
bother if the parent does not have permission to change voltages. This
simplifies error checking in the function for cases where the regulator
lacks some of the voltage operations.
Reported-by: Dong Aisheng <aisheng.dong@nxp.com>
Tested-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators (some PWM regulators) have the voltage transition
non-linear i.e. exponentially. On such cases, the settling time
for voltage transition can not be presented in the voltage-ramp-delay.
Add new property for non-linear voltage transition and handle this
in getting the voltage settling time.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 26988efe11 ("regulator: core: Allow to get voltage count and
list from parent") introduces the propagation of the parent voltage
count and list for regulators that don't provide this information
themselves. The goal is to support simple switch regulators, however as
a side effect normal continuous regulators can leak details of their
supplies and provide consumers with inconsistent information.
Limit the propagation of the voltage count and list to switch
regulators.
Fixes: 26988efe11 ("regulator: core: Allow to get voltage count and
list from parent")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the description for the non-existing 'ret' to fix the build warning:
./drivers/regulator/core.c:1467: warning:
Excess function parameter 'ret' description in 'regulator_dev_lookup'.
The description found for the return value is: @ret: 0 on success, -ENODEV
if lookup fails permanently, -EPROBE_DEFER if lookup could succeed in the future.
Signed-off-by: Tamara Diaconita <diaconita.tamara@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is useful for devices, which need some time to start up, to help
the drivers track how long the supply has been up already. Ie whether
it can safely talk to the HW or needs to wait.
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The supply_name member of struct regulator can be const as we
don't change it in the regulator core. Furthermore, when we copy
the supply name we can use kstrdup_const() here to avoid a copy
if the name is in the ro data section.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When creating the link to the device sysfs entry, the regulator core
calls scnprintf() and then checks if the returned value is greater or
equal than the buffer size.
The former can never happen as scnprintf() returns the number of bytes
that were actually written to the buffer, not the bytes that *would*
have been written.
Use the right function in this case: snprintf().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
After commit 66d228a2bf ("regulator: core: Don't use regulators as
supplies until the parent is bound"), input supplies aren't resolved
if the input supplies parent device has not been bound. This prevent
regulators to hold an invalid reference if its supply parent device
driver probe is deferred.
But this causes issues on some boards where a PMIC's regulator use as
input supply a regulator from another PMIC whose driver is registered
after the driver for the former.
In this case the regulators for the first PMIC will fail to resolve
input supplies on regulators registration (since the other PMIC wasn't
probed yet). And when the core attempts to resolve again latter when
the other PMIC registers its own regulators, it will fail again since
the parent device isn't bound yet.
This will cause some parent supplies to never be resolved and wrongly
be disabled on boot due taking them as unused.
To solve this problem, also attempt to resolve the pending regulators
input supplies before disabling the unused regulators.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It is allowed to call regulator_get with a NULL dev argument
(_regulator_get explicitly checks for it) but this causes an error later
when printing /sys/kernel/debug/regulator_summary.
Fix this by explicitly handling "deviceless" consumers in the debugfs code.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The code in _regulator_get() got a bit confusing over time, with control
flow jumping to a label from couple of places. Let's untangle it a bit by
doing the following:
1. Make handling of missing supplies and substituting them with dummy
regulators more explicit:
- check if we not have full constraints and refuse considering dummy
regulators with appropriate message;
- use "switch (get_type)" to handle different types of request explicitly
as well. "Normal" requests will get dummies, exclusive will not and
will notify user about that; optional will fail silently.
2. Stop jumping to a label in the middle of the function but instead have
proper conditional flow. I believe jumps should be reserved for error
handling, breaking from inner loop, or restarting a loop, but not for
implementing normal conditional flow.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of returning both regulator_dev structure as return value and
auxiliary error code in 'ret' argument, let's switch to using ERR_PTR
encoded values. This makes it more obvious what is going on at call sites.
Also, let's not unlock the mutex in the middle of a loop, but rather break
out and have single unlock path.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to have two loops there, we can store error for subsequent
reporting.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of separate "exclusive" and "allow_dummy" arguments, that formed 3
valid combinations (normal, exclusive and optional) and an invalid one,
let's accept explicit "get_type", like we did in devm-managed code.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no point in assigning value to 'ret' before calling
regulator_dev_lookup() as it will clobber 'ret' anyway.
Also, let's explicitly return -PROBE_DEFER when try_module_get() fails,
instead of relying that earlier initialization of "regulator" carries
correct value.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When regulators are successfully registered, we check to see if the
regulator is a supply for any other registered regulator and if so
add the new regulator as the supply for the existing regulator(s).
Some devices, such as Power Management ICs, may register a series of
regulators when probed and there are cases where one of the regulators
may fail to register and defer the probing of the parent device. In this
case any successfully registered regulators would be unregistered so
that they can be re-registered at some time later when the probe is
attempted again. However, if one of the regulators that was registered
was added as a supply to another registered regulator (that did not
belong to the same parent device), then this supply regulator was
unregister again because the parent device is probe deferred, then a
regulator could be holding an invalid reference to a supply regulator
that has been unregistered. This will lead to a system crash if that
regulator is then used.
Although it would be possible to check when unregistering a regulator
if any other regulator in the system is using it as a supply, it still
may not be possible to remove it as a supply if this other regulator is
in use. Therefore, fix this by preventing any regulator from adding
another regulator as a supply if the parent device for the supply
regulator has not been bound and if the parent device for the supply
and the regulator are different. This will allow a parent device that is
registering regulators to be probe deferred and ensure that none of the
regulators it has registered are used as supplies for any other
regulator from another device.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Every function handling the mode within the regulator core uses an unsigned
int for mode, except for regulator_mode_constrain. This patch changes the
type of mode within regulator_mode_constrain which fixes several instances
where we are passing pointers to unsigned ints then treating them as an int
within this function.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark 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: Axel Haslam <ahaslam@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 73e705bf81 ("regulator: core: Add set_voltage_time op")
introduced a new rdev_warn() if the ramp_delay is 0.
Apparently, on omap3/twl4030 platforms with dynamic voltage
management this results in non-ending spurious messages like
[ 511.143066] VDD1: ramp_delay not set
[ 511.662322] VDD1: ramp_delay not set
[ 513.903625] VDD1: ramp_delay not set
[ 514.222198] VDD1: ramp_delay not set
[ 517.062835] VDD1: ramp_delay not set
[ 517.382568] VDD1: ramp_delay not set
[ 520.142791] VDD1: ramp_delay not set
[ 520.502593] VDD1: ramp_delay not set
[ 523.062896] VDD1: ramp_delay not set
[ 523.362701] VDD1: ramp_delay not set
[ 526.143035] VDD1: ramp_delay not set
I have observed this on GTA04 while it is reported to occur on
N900 as well: https://bugzilla.kernel.org/show_bug.cgi?id=178371
This patch makes the warning appear only in debugging mode.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
drms_uA_update() always returns failure when it cannot find regulator's
input voltage. But if hardware supports load configuration with
ops->set_load() and the input regulator isn't specified with valid reason
such as the input regulator is battery, not finding input voltage is
normal so such case should not return with an error.
Avoid such inadequate error return by checking input/output voltages
only when drms_uA_update() is about to configure load with enum based
ops->set_mode().
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
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: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The current code assumes that only the ramp_delay is used to determine
the time needed for the voltage to stabilize. This may be true for the
calculation done by regulator_set_voltage_time_sel(), however regulators
can implement their own set_voltage_time_sel() op which would be skipped
if no ramp delay is specified. Remove the check in
_regulator_do_set_voltage(), the functions calculating the ramp delay
return 0 anyway when the ramp delay is not configured.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
If the voltage can not be set jump to the end of the function. This
avoids having to check for an error multiple times and eliminates one
level of nesting in a follow-up change.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark 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 3ff3f518a1.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Mark 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: Mark Brown <broonie@kernel.org>
The call to set_machine_constraints() in regulator_register(), will
attempt to get the voltage for the regulator. If a regulator is in
bypass will fail to get the voltage (ie. it's bypass voltage) and
hence register the regulator, because the supply for the regulator has
not been resolved yet.
To fix this, add a call to regulator_resolve_supply() before we call
set_machine_constraints(). If the call to regulator_resolve_supply()
fails, rather than returning an error at this point, allow the
registration of the regulator to continue because for some regulators
resolving the supply at this point may not be necessary and it will be
resolved later as more regulators are added. Furthermore, if the supply
is still not resolved for a bypassed regulator, this will be detected
when we attempt to get the voltage for the regulator and an error will
be propagated at this point.
If a bypassed regulator does not have a supply when we attempt to get
the voltage, rather than returing -EINVAL, return -EPROBE_DEFER instead
to allow the registration of the regulator to be deferred and tried
again later.
Please note that regulator_resolve_supply() will call
regulator_dev_lookup() which may acquire the regulator_list_mutex. To
avoid any deadlocks we cannot hold the regulator_list_mutex when calling
regulator_resolve_supply(). Therefore, rather than holding the lock
around a large portion of the registration code, just hold the lock when
aquiring any GPIOs and setting up supplies because these sections may
add entries to the regulator_map_list and regulator_ena_gpio_list,
respectively.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
To make the code more compat and centralized, this patch add a
unified function - regulator_ops_is_valid. So we can add
some extra checking code easily later.
Signed-off-by: WEN Pingbo <pingbo.wen@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The public functions to acquire a regulator, such as regulator_get(),
internally look-up the regulator from the list of regulators that have
been registered with the regulator device class. The registration of
a new regulator with the regulator device class happens before the
regulator has been completely setup. Therefore, it is possible that
the regulator could be acquired before it has been setup successfully.
To avoid this move the device registration of the regulator to the end
of the regulator setup and update the error exit path accordingly.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
During the resolution of a regulator's supply, we may attempt to enable
the supply if the regulator itself is already enabled. If enabling the
supply fails, then we will call _regulator_put() for the supply.
However, the pointer to the supply has not been cleared for the
regulator and this will cause a crash if we then unregister the
regulator and attempt to call regulator_put() a second time for the
supply. Fix this by clearing the supply pointer if enabling the supply
after fails when resolving the supply for a regulator.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The function regulator_register_resolve_supply() is called from the
context of class_for_each_dev() (during the regulator registration) to
resolve any supplies added. regulator_register_resolve_supply() will
return an error if a regulator's supply cannot be resolved and this will
terminate the loop in class_for_each_dev(). This means that we will not
attempt to resolve any other supplies after one has failed. Hence, this
may delay the resolution of other regulator supplies until the failing
one itself can be resolved.
Rather than terminating the loop early, don't return an error code and
keep attempting to resolve any other supplies for regulators that have
been registered.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There are debugfs entries for voltage and current, but not for
the constraint flags. It's useful for debugging to be able to
see what these flags are so this patch adds a new debugfs file.
We can't use debugfs_create_bool for this because the flags are
bitfields, so as this needs a special read callback they have been
collected into a single file that lists all the flags.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
suspend_prepare can be called during regulator init time also, where
the mutex is not locked yet. This causes a false lockdep warning.
To avoid the problem, remove the lockdep assertion from the function
causing the issue. An alternative would be to lock the mutex during
init, but this would cause other problems (some APIs used during init
will attempt to lock the mutex also, causing deadlock.)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When we acquire a shareable enable GPIO on probe we do so with the
regulator_list_mutex held. However when we release the GPIOs we do this
immediately after dropping the mutex meaning that the list could become
corrupted. Move the release into the locked region to avoid this.
Signed-off-by: Mark Brown <broonie@kernel.org>
device_register() is calling ->get_voltage() as part of it's sysfs attribute
initialization process, and this functions might need to know the regulator
constraints to return a valid value.
This is at least true for the pwm regulator driver (when operating in
continuous mode) which needs to know the minimum and maximum voltage values
to calculate the current voltage:
min_uV + (((max_uV - min_uV) * dutycycle) / 100);
Move device_register() after set_machine_constraints() to make sure those
constraints are correctly initialized when ->get_voltage() is called.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When a regulator is in bypass mode it is functioning as a switch
returning the voltage set in the regulator will not give the voltage
being output by the regulator as it's just passing through its supply.
This means that when we are getting the voltage from a regulator we
should check to see if it is in bypass mode and if it is we should
report the voltage from the supply rather than that which is set on the
regulator.
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
[treding@nvidia.com: return early for bypass mode]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 5e3ca2b349 ("regulator: Try to resolve regulators supplies on
registration") added a call to regulator_resolve_supply() within
regulator_register() where the regulator_list_mutex is held. This causes
a deadlock to occur on the Tegra114 Dalmore board when the palmas PMIC
is registered because regulator_register_resolve_supply() calls
regulator_dev_lookup() which may try to acquire the regulator_list_mutex
again.
Fix this by releasing the mutex before calling
regulator_register_resolve_supply() and update the error exit path to
ensure the mutex is released on an error.
[Made commit message more legible -- broonie]
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This aids in debugging problems triggered by the regulator core applying
its constraints, we could potentially crash immediately after updating
the voltage if the constraints are buggy.
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 6261b06de5 ("regulator: Defer lookup of supply to regulator_get")
moved the regulator supplies lookup logic from the regulators registration
to the regulators get time.
Unfortunately, that changed the behavior of the regulator core since now a
parent supply with a child regulator marked as always-on, won't be enabled
unless a client driver attempts to get the child regulator during boot.
This patch tries to resolve the parent supply for the already registered
regulators each time that a new regulator is registered. So the regulators
that have child regulators marked as always on will be enabled regardless
if a driver gets the child regulator or not.
That was the behavior before the mentioned commit, since parent supplies
were looked up at regulator registration time instead of during child get.
Since regulator_resolve_supply() checks for rdev->supply, most of the times
it will be a no-op. Errors aren't checked to keep the possible out of order
dependencies which was the motivation for the mentioned commit.
Also, the supply being available will be enforced on regulator get anyways
in case the resolve fails on regulators registration.
Fixes: 6261b06de5 ("regulator: Defer lookup of supply to regulator_get")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org> # 4.1+
Currently we only attempt to set the voltage during constraints
application if an exact voltage is specified. Extend this so that if
the currently set voltage for the regulator is outside the bounds set in
constraints we will move the voltage to the nearest constraint, raising
to the minimum or lowering to the maximum as needed. This ensures that
drivers can probe without the hardware being driven out of spec.
Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Apparently due to a wrongly resolved merge conflict between two
branches, which contained the same commit, the commit contents
partially was added two times in a row.
This change reverts the latter wrong inclusion of commit 909f7ee0b5
("regulator: core: Add support for active-discharge configuration").
The first applied commit 670666b9e0 ("regulator: core: Add support
for active-discharge configuration") is not touched.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator_resolve_supply() function checks if a supply has been
associated with a regulator to avoid enabling it if that is not the
case.
But the supply was already looked up with regulator_resolve_supply()
and set with set_supply() before the check and both return on error.
So the fact that this statement has been reached means that neither
of them failed and a supply must be associated with the regulator.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark 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: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark 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: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This problem was introduced by:
commit daad134d66 ("regulator: core: Request GPIO before creating
sysfs entries")
The error path was not updated correctly after moving GPIO registration
code and in case regulator_ena_gpio_free failed, device_unregister() was
called even though device_register() was not yet called.
This problem breaks the boot at least on all Tegra 32-bit devices. It
will also crash each device that specifices GPIO that is unavaiable at
regulator_register call. Here's error log I've got when forced GPIO to
be invalid:
[ 1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22
[ 1.122794] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
[ 1.130894] pgd = c0004000
[ 1.133598] [00000044] *pgd=00000000
[ 1.137205] Internal error: Oops: 5 [#1] SMP ARM
and here's backtrace from KDB:
Exception stack(0xef11fbd0 to 0xef11fc18)
fbc0: 00000000 c0738a14 00000000 00000000
fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c
fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff
[<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8)
[<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58)
[<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68)
[<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c)
[<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4)
[<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c)
[<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac)
[<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84)
[<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0)
[<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0)
[<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440)
[<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120)
[<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98)
[<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138)
[<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20)
[<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c)
[<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc)
[<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454)
[<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510)
[<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104)
[<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c)
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator_attr_is_visible (which is a .is_visible callback of
regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if
"status" file should be present in sysfs. This field is set at the end
of regulator_ena_gpio_request so it has to be called before
device_register() otherwise this test will always fail, causing "status"
file to not be visible.
Since regulator_attr_is_visible also tests for is_enabled() op, this
problem is only visible for regulators that does not define this
callback, like regulator-fixed.c.
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As we now free the constraints in regulator_dev_release we will still
call free on the constraints pointer even if we went down an error
path in regulator_register, because it is only allocated after the
device_register. As such we no longer need to free rdev->constraints
on the error paths, so this patch removes said frees.
Fixes: 29f5f4860a ("regulator: core: Move more deallocation into class unregister")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
