Commit Graph

536 Commits

Author SHA1 Message Date
Mark Brown
57a0dd1879
regulator: Fix suspend to idle
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>
2018-01-30 12:25:59 +00:00
Mark Brown
00cb9f4f5e
regulator: Fix build error
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>
2018-01-26 17:55:30 +00:00
Mark Brown
285c22de37
Merge branch 'topic/suspend' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core 2018-01-26 17:40:03 +00:00
Maciej Purski
3d67fe9507
regulator: core: Refactor regulator_list_voltage()
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>
2018-01-26 15:48:08 +00:00
Maciej Purski
148096af0b
regulator: core: Move of_find_regulator_by_node() to of_regulator.c
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>
2018-01-26 15:48:07 +00:00
Chunyan Zhang
f7efad10b5
regulator: add PM suspend and resume hooks
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>
2018-01-26 14:43:55 +00:00
Chunyan Zhang
aa27bbc6c6
regulator: empty the old suspend functions
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>
2018-01-26 14:43:51 +00:00
Chunyan Zhang
72069f9957
regulator: leave one item to record whether regulator is enabled
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>
2018-01-26 14:43:46 +00:00
Chunyan Zhang
c360a6df02
regulator: make regulator voltage be an array to support more states
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>
2018-01-26 14:43:45 +00:00
Colin Ian King
0d5c8633b1
regulator: fix incorrect indentation of two assignment statements
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>
2017-12-07 14:04:43 +00:00
Mark Brown
02929a4478 Merge remote-tracking branches 'regulator/topic/cpcap', 'regulator/topic/da9063', 'regulator/topic/dt', 'regulator/topic/fan53555' and 'regulator/topic/ltc3589' into regulator-next 2017-09-04 17:45:42 +01:00
Tirupathi Reddy
c9ccaa0cac regulator: core: fix a possible race in disable_work handling
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>
2017-07-20 13:22:29 +01:00
Rob Herring
7799167b7a regulator: Convert to using %pOF instead of full_name
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>
2017-07-19 11:56:01 +01:00
Mark Brown
8d67f64f77 Merge remote-tracking branches 'regulator/topic/settle', 'regulator/topic/tps65910' and 'regulator/topic/tps65917' into regulator-next 2017-07-03 16:52:21 +01:00
Mark Brown
fcaa3167b2 Merge remote-tracking branch 'regulator/topic/core' into regulator-next 2017-07-03 16:52:16 +01:00
Haishan Zhou
dbc5595540 regulator: core: Fix size limit of supply_map
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>
2017-06-30 12:56:42 +01:00
Tirupathi Reddy
2c2874b191 regulator: core: Fix voltage change propagations to supply regulators
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>
2017-06-28 20:39:36 +01:00
Charles Keepax
062171973e regulator: core: Prioritise consumer mappings over regulator name
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>
2017-06-13 18:43:28 +01:00
Matthias Kaehlcke
3ffad468cf regulator: Allow for asymmetric settling times
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>
2017-05-17 10:49:25 +01:00
Mark Brown
81bc8e386f Merge remote-tracking branches 'regulator/topic/notifier', 'regulator/topic/pfuze100', 'regulator/topic/settle', 'regulator/topic/tps65132' and 'regulator/topic/twl6030' into regulator-next 2017-04-30 22:17:36 +09:00
Mark Brown
c93609ab39 regulator: core: Allow dummy regulators for supplies
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>
2017-04-14 18:08:01 +01:00
Mark Brown
43fc99f293 regulator: core: Only propagate voltage changes to if it can change voltages
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>
2017-04-14 18:07:51 +01:00
Laxman Dewangan
d6c1dc3f52 regulator: Add settling time for non-linear voltage transition
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>
2017-04-05 18:25:10 +01:00
Matthias Kaehlcke
fd08604555 regulator: core: Limit propagation of parent voltage count and list
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>
2017-03-29 12:49:38 +01:00
Tamara Diaconita
fffd113338 regulator: core: Fix kerneldoc comments
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>
2017-03-29 11:35:32 +01:00
Harald Geyer
264b88c9e5 regulator: core: Add new notification for enabling of regulator
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>
2017-03-24 19:13:42 +00:00
Stephen Boyd
0630b61439 regulator: Mark supply_name const and duplicate it as such
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>
2017-03-17 13:12:22 +00:00
Bartosz Golaszewski
b7cd1b1386 regulator: core: use snprintf() instead of scnprintf()
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>
2017-03-07 13:07:21 +01:00
Mark Brown
fad9cd45ed Merge remote-tracking branches 'regulator/topic/s2mpa01', 'regulator/topic/supplies' and 'regulator/topic/tps65217' into regulator-next 2017-02-19 16:40:41 +00:00
Mark Brown
401c42429c Merge remote-tracking branch 'regulator/topic/core' into regulator-next 2017-02-19 16:40:23 +00:00
Mark Brown
0fe3f971fc Merge remote-tracking branches 'regulator/fix/debugfs' and 'regulator/fix/tps65086' into regulator-linus 2017-02-19 16:40:22 +00:00
Javier Martinez Canillas
3827b64dba regulator: core: Resolve supplies before disabling unused regulators
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>
2017-02-16 18:15:01 +00:00
Leonard Crestez
e42a46b6f5 regulator: Fix regulator_summary for deviceless consumers
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
2017-02-16 12:44:58 +00:00
Dmitry Torokhov
a4d7641fa7 regulator: core: simplify _regulator_get()
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>
2017-02-08 18:29:05 +00:00
Dmitry Torokhov
163478dae0 regulator: core: have regulator_dev_lookup() return ERR_PTR-encoded errors
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>
2017-02-05 17:36:40 +01:00
Dmitry Torokhov
d1642ea717 regulator: core: fix typo in regulator_bulk_disable()
"re-enable" was misspelled as "reename".

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2017-02-04 11:37:32 +01:00
Dmitry Torokhov
b8c77ff690 regulator: core: simplify regulator_bulk_force_disable()
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>
2017-02-04 11:37:24 +01:00
Dmitry Torokhov
a8bd42a977 regulator: core: have _regulator_get() accept get_type argument
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>
2017-02-04 11:31:52 +01:00
Dmitry Torokhov
7d245afa24 regulator: core: remove dead code in _regulator_get()
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>
2017-02-04 11:25:07 +01:00
Jon Hunter
66d228a2bf regulator: core: Don't use regulators as supplies until the parent is bound
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>
2017-01-12 17:25:14 +00:00
Mark Brown
bed69721b6 Merge remote-tracking branches 'regulator/topic/arizona', 'regulator/topic/bypass', 'regulator/topic/error' and 'regulator/topic/fixed' into regulator-next 2016-12-12 12:17:24 +00:00
Mark Brown
6b46856246 Merge remote-tracking branch 'regulator/topic/core' into regulator-next 2016-12-12 12:17:23 +00:00
David Lechner
b2661e983f regulator: core: add newline in debug message
This adds a trailing newline to a debug message.

Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-12-05 11:31:30 +00:00
Charles Keepax
109c75afa1 regulator: core: Correct type of mode in regulator_mode_constrain
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>
2016-11-30 17:44:16 +00:00
Axel Haslam
1b5b422164 regulator: core: Add new API to poll for error conditions
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>
2016-11-04 12:15:25 -06:00
H. Nikolaus Schaller
ba14fa1a57 regulator: core: silence warning: "VDD1: ramp_delay not set"
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>
2016-10-28 18:22:40 +01:00
Mark Brown
2dfcb921da Merge remote-tracking branches 'regulator/topic/of', 'regulator/topic/pv88080', 'regulator/topic/rk808', 'regulator/topic/set-voltage' and 'regulator/topic/tps65218' into regulator-next 2016-09-30 09:13:58 -07:00
Mark Brown
81c383c9ba Merge remote-tracking branches 'regulator/topic/bulk', 'regulator/topic/dbx500', 'regulator/topic/hi6421', 'regulator/topic/load' and 'regulator/topic/ltc3676' into regulator-next 2016-09-30 09:13:55 -07:00
Joonwoo Park
577766175c regulator: core: don't return error with inadequate reason
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>
2016-09-24 19:36:41 +01:00
Matthias Kaehlcke
73e705bf81 regulator: core: Add set_voltage_time op
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>
2016-09-16 18:38:22 +01:00