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

Merge remote-tracking branches 'regulator/topic/arizona', 'regulator/topic/bypass', 'regulator/topic/error' and 'regulator/topic/fixed' into regulator-next

2016-12-12T12:17:24+00:00

Merge remote-tracking branch 'regulator/topic/core' into regulator-next

2016-12-12T12:17:23+00:00

regulator: core: add newline in debug message

2016-12-05T11:31:30+00:00

This adds a trailing newline to a debug message.

Signed-off-by: David Lechner 
Signed-off-by: Mark Brown

regulator: core: Correct type of mode in regulator_mode_constrain

2016-11-30T17:44:16+00:00

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

regulator: core: Add new API to poll for error conditions

2016-11-04T18:15:25+00:00

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

regulator: core: silence warning: "VDD1: ramp_delay not set"

2016-10-28T17:22:40+00:00

commit 73e705bf81ce ("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 
Signed-off-by: Mark Brown

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-30T16:13:58+00:00

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-30T16:13:55+00:00

regulator: core: don't return error with inadequate reason

2016-09-24T18:36:41+00:00

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 
Cc: Mark Brown 
Cc: Bjorn Andersson 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joonwoo Park 
Signed-off-by: Mark Brown

regulator: core: Add set_voltage_time op

2016-09-16T17:38:22+00:00

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