Commit Graph

2941 Commits

Author SHA1 Message Date
Boris Brezillon d9070fdbe4 regulator: pwm: Retrieve correct voltage
The continuous PWM voltage regulator is caching the voltage value in
the ->volt_uV field. While most of the time this value should reflect the
real voltage, sometime it can be sightly different if the PWM device
rounded the set_duty_cycle request.
Moreover, this value is not valid until someone has modified the regulator
output.

Remove the ->volt_uV field and always rely on the PWM state to calculate
the regulator output.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-11 08:44:29 +02:00
Boris Brezillon 87248991a1 regulator: pwm: Properly initialize the ->state field
The ->state field is currently initialized to 0, thus referencing the
voltage selector at index 0, which might not reflect the current
voltage value.
If possible, retrieve the current voltage selector from the PWM state,
else return -EINVAL.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-11 08:43:24 +02:00
Boris Brezillon 3f4eb39be9 regulator: pwm: Switch to the atomic PWM API
Use the atomic API wherever appropriate and get rid of pwm_apply_args()
call (the reference period and polarity are now explicitly set when
calling pwm_apply_state()).

We also make use of the pwm_set_relative_duty_cycle() helper to ease
relative to absolute duty_cycle conversion.

Note that changes introduced by commit fd786fb027 ("regulator: pwm:
Try to avoid voltage error in duty cycle calculation") are no longer
needed because pwm_set_relative_duty_cycle() takes care of all rounding
approximation for us.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-11 08:43:21 +02:00
Boris Brezillon fd4f99c4c3 regulator: pwm: Adjust PWM config at probe time
The PWM attached to a PWM regulator device might have been previously
configured by the bootloader.
Make sure the bootloader and linux config are in sync, and adjust the PWM
config if that's not the case.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-07-11 08:41:37 +02:00
Douglas Anderson c2588393e6 regulator: pwm: Fix regulator ramp delay for continuous mode
The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly.  It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS.  Let's
adjust it.  Luckily there appear to be no users of this ramp delay for
PWM regulators (as per grepping through device trees in linuxnext).

Note also that the upper bound of usleep_range probably shouldn't be a
full 1 ms longer than the lower bound since I've seen plenty of hardware
with a ramp rate of ~5000 uS / uV and for small jumps the total delays
are in the tens of uS.  1000 is way too much.  We'll try to be dynamic
and use 10%.

NOTE: This commit doesn't add support for regulator-enable-ramp-delay.
That could be done in a future patch when someone has a user of that
featre.

Though this patch is shows as "fixing" a bug, there are no actual known
users of continuous mode PWM regulator w/ ramp delay in mainline and so
this likely won't have any effect on anyone unless they are working
out-of-tree with private patches.  For anyone in this state, it is
highly encouraged to also pick Boris Brezillon's WIP patches to get
yourself a reliable and glitch-free regulator.

Fixes: 4773be185a ("regulator: pwm-regulator: Add support for continuous-voltage")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-07 11:45:06 +02:00
Mark Brown a29a36f265 Merge remote-tracking branches 'regulator/fix/anatop' and 'regulator/fix/max77620' into regulator-linus 2016-07-01 18:06:48 +02:00
Venkat Reddy Talla 91ff811f32 regulator: max77620: check for valid regulator info
SD4 regulator is not registered with regulator core
framework in probe as there is no support in MAX77620 PMIC,
removing SD4 entry from MAX77620 regulator information list
and checking for valid regulator information data before
configuring FPS source and FPS power up/down period to avoid
NULL pointer exception if regulator not registered with core.

Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-29 18:50:05 +01:00
James Ban 7524c1cebc regulator: da9211: add descriptions for da9212/da9214
This is a patch for adding description for da9212/da9214.

Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-29 17:24:55 +01:00
Stefan Agner ed6d362d8d regulator: rn5t618: Add RN5T567 PMIC support
Extend the driver to support Ricoh RN5T567. Support the additional
DCDC and slightly different voltage range of LDORTC1.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2016-06-29 10:11:29 +01:00
Tero Kristo 3fb2ef111d regulator: tps65218: force set power-up/down strobe to 3 for dcdc3
The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-27 17:56:43 +01:00
Tero Kristo b9a0d35941 regulator: tps65218: Enable suspend configuration
TPS65218 has a pre-defined power-up / power-down sequence which in
a typical application does not need to be changed. However, it is possible
to define custom sequences under I2C control. The power-up sequence is
defined by strobes and delay times. Each output rail is assigned to a
strobe to determine the order in which the rails are enabled.

Every regulator has sequence registers and every regulator has a default
strobe value and gets disabled when a particular power down sequence
occurs.

To keep a regulator on during suspend we write value 0 to strobe so
that the regulator is out of all sequencers and is not impacted by any
power down sequence. Hence saving the default strobe value during probe
so that when we want to regulator to be enabled during suspend we write 0
to strobe and when we want it to get disabled during suspend we write
the default saved strobe value.
This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-27 17:56:43 +01:00
Russ Dill 3de5609959 regulator: tps65217: Enable suspend configuration
The TPS65217 has a pre-defined power-up / power-down sequence which in
a typical application does not need to be changed. However, it is possible
to define custom sequences under I2C control. The power-up sequence is
defined by strobes and delay times. Each output rail is assigned to a
strobe to determine the order in which the rails are enabled.

Every regulator of tps65217 PMIC has sequence registers and every
regulator has a default strobe value and gets disabled when a particular
power down sequence occurs.

To keep a regulator on during suspend we write value 0 to strobe so
that the regulator is out of all sequencers and is not impacted by any
power down sequence. Hence saving the default strobe value during probe
so that when we want to regulator to be enabled during suspend we write 0
to strobe and when we want it to get disabled during suspend we write
the default saved strobe value.

This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
[Enhanced commit log and added dynamic allocation for strobes]
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-27 17:56:43 +01:00
Stephen Boyd 919163f636 regulator: qcom_spmi: Add support for get_mode/set_mode on switches
The voltage switches support mode switching, so add support for
these ops to those types of regulators.

Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: e92a404741 ("regulator: Add QCOM SPMI regulator driver")
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-26 12:24:07 +01:00
Stephen Boyd 93bfe79b03 regulator: qcom_spmi: Update mvs1/mvs2 switches on pm8941
The mvs1 and mvs2 switches are actually called 5vs1 and 5vs2 on
some datasheets. Let's rename them to match the datasheets and
also match the RPM based regulator driver which calls these by
their 5vs names (see qcom_smd-regulator.c). There aren't any
users of these regulators so far, so there aren't any concerns of
DT ABI breakage here. While we're here making updates to the
switches, also mandate usage of the OCP irq for these switches
too.

Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: e92a404741 ("regulator: Add QCOM SPMI regulator driver")
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-26 12:24:07 +01:00
Stephen Boyd c333dfe8db regulator: qcom_spmi: Add support for S4 supply on pm8941
The S4 supply is sometimes called the boost regulator because it
outputs 5V. Typically it's connected to the 5vs1 and 5vs2
switches for use in USB OTG and HDMI applications. Add support
for this regulator which was mistakenly left out from the initial
submission of this driver.

Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: e92a404741 ("regulator: Add QCOM SPMI regulator driver")
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-26 12:24:07 +01:00
Alexandre Courbot 27bfa8893b regulator: pwm: Support for enable GPIO
Add an optional enable GPIO to the pwm-regulator driver.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-23 11:34:35 +01:00
Keerthy a0f78bc89c regulator: of: setup initial suspend state
Setup initial suspend state to mem, if suspend state is defined for
mem state. This makes sure that the regulators are in proper mode
already from boot.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-22 16:15:34 +01:00
Axel Lin 4335f6537a regulator: lp873x: Drop _nlr parameter from LP873X_REGULATOR()
No need to pass _nlr to LP873X_REGULATOR(), use ARRAY_SIZE to calculate it.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-21 18:43:48 +01:00
Mika Båtsman 8a092e682f regulator: anatop: allow regulator to be in bypass mode
Bypass support was added in commit d38018f201 ("regulator: anatop: Add
bypass support to digital LDOs"). A check for valid voltage selectors was
added in commit da0607c8df ("regulator: anatop: Fail on invalid voltage
selector") but it also discards all regulators that are in bypass mode. Add
check for the bypass setting. Errors below were seen on a Variscite mx6
board.

anatop_regulator 20c8000.anatop:regulator-vddcore@140: Failed to read a valid default voltage selector.
anatop_regulator: probe of 20c8000.anatop:regulator-vddcore@140 failed with error -22
anatop_regulator 20c8000.anatop:regulator-vddsoc@140: Failed to read a valid default voltage selector.
anatop_regulator: probe of 20c8000.anatop:regulator-vddsoc@140 failed with error -22

Fixes: da0607c8df ("regulator: anatop: Fail on invalid voltage selector")
Signed-off-by: Mika Båtsman <mbatsman@mvista.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-17 11:40:20 +01:00
Axel Lin 43160ffd12 regulator: qcom_smd: Remove list_voltage callback for rpm_smps_ldo_ops_fixed
Use regulator_list_voltage_linear_range in rpm_smps_ldo_ops_fixed is
wrong because it is used for fixed regulator without any linear range.
The rpm_smps_ldo_ops_fixed is used for pm8941_lnldo which has fixed_uV
set and n_voltages = 1. In this case, regulator_list_voltage() can return
rdev->desc->fixed_uV without .list_voltage implementation.

Fixes: 3bfbb4d1a4 ("regulator: qcom_smd: add list_voltage callback")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-15 10:18:50 +01:00
Mark Brown 0d2a8ef439 Merge remote-tracking branches 'regulator/fix/qcom-smd' and 'regulator/fix/tps51632' into regulator-linus 2016-06-13 16:51:57 +01:00
Srinivas Kandagatla 3bfbb4d1a4 regulator: qcom_smd: add list_voltage callback
This patch adds support to list_voltage callback, so that consumers
like mmc core, can get information of supported voltage range.

Without this patch there is no way for mmc core to know this voltage range.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-13 09:51:35 +01:00
Mark Brown fc1e1c4a24 regulator: Remove regulator_can_change_voltage()
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>
2016-06-09 11:40:34 +01:00
Ben Dooks 2ac1ea2c4a regulator: twl: fix use of integer as pointer
The TWL6030_FIXED_LDO() macro passes the TWL_FIXED_LDO()
macro an 0x0 instead of a NULL. Changing this to a NULL
fixes the following warnings:

drivers/regulator/twl-regulator.c:1068:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1069:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1070:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1071:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1072:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1073:1: warning: Using plain integer as NULL pointer

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-08 18:18:24 +01:00
Srinivas Kandagatla d1e44b6b28 regulator: qcom_smd: add regulator ops for pm8941 lnldo
After "regulator: qcom_smd: add list_voltage callback" patch adding
pm8941 lnldo regulators would bug on list_voltages as it is a fixed
regulator without any linear range.
This patch fixes that issue by adding dedicated ops for pm8941 lnldo
without list_voltages callback.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org # v4.6
2016-06-08 11:59:25 +01:00
Srinivas Kandagatla a8a47540eb regulator: qcom_smd: add list_voltage callback
This patch adds support to list_voltage callback, so that consumers
like mmc core, can get information of supported voltage range.

Without this patch there is no way for mmc core to know this voltage range.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org # v4.6
2016-06-08 11:59:00 +01:00
Fabio Estevam 7eeeab8c02 regulator: pfuze100-regulator: Adjust MODULE_DESCRIPTION()
Adjust the MODULE_DESCRIPTION() text to also include the PFUZE3000
as a supported device.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-06 19:13:48 +01:00
Fabio Estevam af2c55cd47 regulator: Kconfig: Mention that PFUZE3000 is also supported
The CONFIG_REGULATOR_PFUZE100 option also supports PFUZE3000, so
mention that in the Kconfig text.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-06 19:13:48 +01:00
Fabio Estevam 124256548f regulator: pfuze100-regulator: Remove global variable
We should better not use a global 'struct pfuze_regulator' variable,
as this could cause problems if multiple regulator chips are used.

Place it inside the private struct instead.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-06 19:13:48 +01:00
Hans de Goede 636e2a39cf regulator: axp20x: Add support for the (external) drivebus regulator
The axp20x pmics have 2 power inputs, one called ACIN which is intended
for to be supplied via a powerbarrel on the board and one called VBUS
which is intended to be supplied via an otg connector.

In the VBUS case the pmic needs to know if the board is supplying power
to the otg connector, because then it should not take any power from
its VBUS pin. The axp209 pmic has a N_VBUSEN input pin via which the
board can signal to the pmic whether the board is supplying power to the
otg connector or not.

On the axp221/axp223 this pin can alternatively be used as an output
which controls an external regulator which (optionally) supplies
power to the otg connector from the board. When the pin is used as
output it is called DRIVEVBUS in the datasheet.

This commit adds support for the DRIVEVBUS pin as an extra pmic
controlled regulator. Since this is optional a new x-powers,drivebus dt
property is added. When this is present the misc-control register is
written to change the N_VBUSEN input pin to DRIVEVBUS output pin mode and
the extra drivebus regulator is registered with the regulator subsystem.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-06 18:38:30 +01:00
Boris Brezillon 830583004e regulator: pwm: Drop unneeded pwm_enable() call
Now that the PWM regulator driver implements the ->enable/disable() hooks
we can remove the pwm_enable() call from pwm_regulator_set_voltage().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-03 11:42:48 +01:00
Chen-Yu Tsai a51f9f4622 regulator: axp20x: support AXP809 variant
The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221,
though a few LDOs were removed, and a new switch output added. Like the
AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained
to DCDC1 and DCDC5, respectively.

Add support for this new variant. Also remove the "axp22x_" prefix from
DC1SW/DC5LDO supply handling code, as the AXP809 uses it as well.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-31 18:37:07 +01:00
Axel Lin c714a588fc regulator: tps51632: Fix setting ramp delay
According to the datasheet:

SLEW Register(Address = 07h)
b7      b6      b5      b4      b3      b2      b1      b0
48mV/us 42mV/us 36mV/us 30mV/us 24mV/us 18mV/us 12mV/us 6mV/us

Current code does not set correct slew rate in some cases:
e.g. Assume ramp_delay is 10000, current code sets slew register to 6mV/us.
Fix the logic to set slew register.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-31 16:38:01 +01:00
Axel Lin d0abd6f5f5 regulator: max8973: Fix setting ramp delay
Current code can set ramp delay to a wrong setting that the return value
from .set_voltage_time_sel is not enough for proper delay.
Fix the logic in .set_ramp_delay and also remove unused ret_val variable.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-30 17:00:56 +01:00
Henry Chen 0569251327 regulator: mt6397: Add buck change mode regulator interface for mt6397
BUCKs of mt6397 have auto mode and pwm mode.
User can use regulator interfaces to control modes

Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-30 16:29:43 +01:00
Henry Chen fb69114b3e regulator: mt6397: Constify struct regulator_ops
Consitify the structure of regulator operations.

Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-30 16:29:43 +01:00
Axel Lin c8a28a0dbe regulator: pv880x0: Clean up unnecessary header inclusion
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-30 16:29:39 +01:00
Laxman Dewangan f5a6d35163 regulator: fixed: Remove workaround to handle of_get_named_gpio() return
The GPIO interface of_get_named_gpio() has implemented the proper
error returns even EPROBE_DEFER and hence caller need not to
implement any workaround for translating the returned error.

Remove the workaround implemented to handle the return of
of_get_named_gpio().

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-30 16:29:34 +01:00
Mark Brown 4f38c566a0 Merge remote-tracking branches 'regulator/topic/tps6524x' and 'regulator/topic/twl' into regulator-next 2016-05-13 14:23:49 +01:00
Mark Brown 39d652e066 Merge remote-tracking branches 'regulator/topic/pwm', 'regulator/topic/qcom-spmi', 'regulator/topic/rk808' and 'regulator/topic/s2mps11' into regulator-next 2016-05-13 14:23:46 +01:00
Mark Brown eb76d8407c Merge remote-tracking branches 'regulator/topic/max77686', 'regulator/topic/max8973', 'regulator/topic/maxim', 'regulator/topic/palmas' and 'regulator/topic/pv88080' into regulator-next 2016-05-13 14:23:38 +01:00
Mark Brown ce59dedfef Merge remote-tracking branches 'regulator/topic/fan53555', 'regulator/topic/lp3971', 'regulator/topic/lp3972', 'regulator/topic/lp873x' and 'regulator/topic/max77620' into regulator-next 2016-05-13 14:23:34 +01:00
Mark Brown 78d5501cf4 Merge remote-tracking branches 'regulator/topic/can-change', 'regulator/topic/constrain', 'regulator/topic/debugfs' and 'regulator/topic/doc' into regulator-next 2016-05-13 14:23:27 +01:00
Mark Brown 8595bb27ce Merge remote-tracking branches 'regulator/topic/abb', 'regulator/topic/act8865', 'regulator/topic/as3722' and 'regulator/topic/axp20x' into regulator-next 2016-05-13 14:23:08 +01:00
Mark Brown ab3688541d Merge remote-tracking branch 'regulator/topic/supply' into regulator-next 2016-05-13 14:23:01 +01:00
Mark Brown 170b649e40 Merge remote-tracking branch 'regulator/topic/core' into regulator-next 2016-05-13 14:22:57 +01:00
Mark Brown 75941a1ba3 Merge remote-tracking branch 'regulator/topic/bypass' into regulator-next 2016-05-13 14:22:55 +01:00
Mark Brown 93878cd540 Merge remote-tracking branches 'regulator/fix/constrain' and 'regulator/fix/defer' into regulator-linus 2016-05-13 14:22:43 +01:00
Mark Brown 5535fc7958 Merge remote-tracking branch 'regulator/fix/core' into regulator-linus 2016-05-13 14:22:41 +01:00
Mark Brown e9cb77d03c Merge remote-tracking branch 'regulator/fix/bypass' into regulator-linus 2016-05-13 14:22:38 +01:00
Wadim Egorov 9e9daa0a67 regulator: rk808: Migrate to regulator core's simplified DT parsing code
A common simplified DT parsing code for regulators was introduced in
commit a0c7b164ad ("regulator: of: Provide simplified DT parsing
method")

While at it also added RK8XX_DESC and RK8XX_DESC_SWITCH macros for the
regulator_desc struct initialization. This just makes the driver more compact.

Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-13 12:19:57 +01:00
Mark Brown 9689dab30a Merge remote-tracking branches 'regulator/fix/axp20x', 'regulator/fix/da9063', 'regulator/fix/gpio' and 'regulator/fix/s2mps11' into regulator-linus 2016-05-13 11:11:08 +01:00
Keerthy 994aae32b1 regulator: lp873x: Add support for lp873x PMIC regulators
The regulators set consists of 2 BUCKs and 2 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components. The ramp delay is configurable
for both BUCKs.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-11 17:53:08 +01:00
Geert Uytterhoeven ac40b44174 regulator: da9063: Correct module alias prefix to fix module autoloading
s/paltform/platform/

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-10 20:00:49 +01:00
Nishanth Menon 6c7d614fa2 regulator: tps65917/palmas: Simplify multiple dereference of match->of_node
Just dereference match->of_node once instead of using match->of_node.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-06 18:15:18 +01:00
Nishanth Menon 7f091e53c9 regulator: tps65917/palmas: Handle possible memory allocation failure
Stop the palmas regulator driver from imagining that the allocations
will always succeed. Since regulator dt nodes are optional in nature and
can be described in downstream drivers via platform data, continue to
maintain code flow as prior when of node is not found.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-06 18:15:18 +01:00
Nishanth Menon 1b42443db6 regulator: tps65917/palmas: Simplify multiple dereference of pdata->reg_init[idx]
Converting dt to platform data logic involves picking up information
that is unique per regulator, however we can improve readability of
the code by allocating and referencing pdata->reg_init[idx] once in
the loop.

While at it, use sizeof(*pointer) when allocating pointer. This allows
for structure name changes with minimal code change.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-06 18:15:17 +01:00
Nishanth Menon 036d193d33 regulator: tps65917/palmas: Simplify multiple dereference of ddata->palmas_matches[idx]
Converting dt to platform data logic involves picking up information
that is unique per regulator, however we can improve readability of
the code by dereferencing ddata->palmas_matches[idx] once in the loop.

While at it fix reuse of generic palmas_matches common variable
while reporting error for a specific regulator (which may be from
65917/palmas list).

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-06 18:15:17 +01:00
Mark Brown bc0868c62b Merge branch 'for-4.7/pwm-regulator' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm into regulator-pwm 2016-05-03 15:09:56 +01:00
Boris Brezillon 8c12ad8e91 regulator: pwm: Use pwm_get_args() where appropriate
The PWM framework has clarified the concept of reference PWM config (the
platform dependent config retrieved from the DT or the PWM lookup table)
and real PWM state.

Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.

This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has just
been requested (before the user calls pwm_config/enable/disable()).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-03 13:46:50 +02:00
Krzysztof Kozlowski a9597305d9 regulator: max77686: Configure enable time to properly handle regulator enable
The enable time for buck regulators was not configured but actually is
essential: consumers, like usb3503, doing hard reset (regulator off/on)
should wait for the regulator to settle.

Configure the enable time according to datasheet.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-29 12:31:39 +01:00
Hans de Goede f40d4896bf regulator: axp20x: Fix axp22x ldo_io registration error on cold boot
The maximum supported voltage for ldo_io# is 3.3V, but on cold
boot the selector comes up at 0x1f, which maps to 3.8V.

This causes _regulator_get_voltage() to fail with -EINVAL which
causes regulator registration to fail when constrains are used:

[    1.467788] vcc-touchscreen: failed to get the current voltage(-22)
[    1.474209] axp20x-regulator axp20x-regulator: Failed to register ldo_io1
[    1.483363] axp20x-regulator: probe of axp20x-regulator failed with error -22

This commits makes the axp20x regulator driver accept the 0x1f register
value, fixing this.

The datasheet does not guarantee reliable operation above 3.3V, so on
boards where this regulator is used the regulator-max-microvolt setting
must be 3.3V or less.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-29 11:43:50 +01:00
Wadim Egorov 129d7cf98f regulator: rk808: Add rk808_reg_ops_ranges for LDO3
LDO_REG3 descriptor is using linear_ranges.
Add and use proper ops for LDO_REG3.

Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-27 17:03:34 +01:00
Jon Hunter 45389c4752 regulator: core: Add early supply resolution for regulators
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>
2016-04-27 16:32:19 +01:00
Mark Brown cbc13a66fd Merge branch 'topic/bypass' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-supply 2016-04-27 16:32:14 +01:00
Hans de Goede a2262e5a12 regulator: axp20x: Fix axp22x ldo_io voltage ranges
The minium voltage of 1800mV is a copy and paste error from the axp20x
regulator info. The correct minimum voltage for the ldo_io regulators
on the axp22x is 700mV.

Fixes: 1b82b4e4f9 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-27 16:14:52 +01:00
Nishanth Menon e0341f1732 regulator: tps65917/palmas: Add bypass "On" value
When commit b554e14506 ("regulator: tps65917/palmas: Add bypass
ops for LDOs with bypass capability") introduced bypass capability
to palmas regulator, it went with the assumption that regulator
regmap helpers just check val against the bypass_mask.

Unfortunately, this ignored the explicit "on" and "off" values when
the register value is masked with bypass_mask in commit ca5d1b3524
("regulator: helpers: Modify helpers enabling multi-bit control").

With the recent commit dd1a571dae ("regulator: helpers: Ensure
bypass register field matches ON value"), this issue gets highlighted
and fails tps65917/palmas based platforms which need regulators/ldos
that have bypass capability.

Introduce the bypass_on value appropriately for tps65917/palmas
regulator.

Fixes: b554e14506 ("regulator: tps65917/palmas: Add bypass ops for LDOs with bypass capability")
Cc: Keerthy <j-keerthy@ti.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-26 17:41:38 +01:00
Maxime Ripard 8d4d5c3a7c regulator: axp20x: Fix LDO4 linear voltage range
The current linear voltage range for the LDO4 regulator found in the APX20X
PMICs assumes that the voltage is linear between 2.5 and 3.1V.

However, the PMIC can output up to 3.3V on that regulator by skipping the
2.6V and 2.9V steps.

Fix the ranges to read and set the proper voltages.

Fixes: 13d57e6435 ("regulator: axp20x: Use linear voltage ranges for AXP20X LDO4")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-26 15:57:45 +01:00
Arnd Bergmann 4a5ed8c1ad regulator: rk808: remove unused rk808_reg_ops_ranges
After removing all uses of the range operations in a recent patch,
we get a warning about the symbol not being referenced anywhere:

drivers/regulator/rk808-regulator.c:306:29: 'rk808_reg_ops_ranges' defined but not used

This removes the now-unused structure along with the
rk808_set_suspend_voltage_range function that is only referenced from
rk808_reg_ops_ranges.

Fixes: afcd666d9d ("regulator: rk808: remove linear range definitions with a single range")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-26 11:11:29 +01:00
WEN Pingbo 8a34e979f6 regulator: refactor valid_ops_mask checking code
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>
2016-04-25 18:52:06 +01:00
Wadim Egorov afcd666d9d regulator: rk808: remove linear range definitions with a single range
The driver was using only linear ranges. Now we remove linear range
definitions with a single range. So we have to add an ops struct for
ranges and adjust all other ops functions accordingly.

Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-25 18:38:11 +01:00
Laxman Dewangan 5aa43599da regulator: max77620: Add support for device specific ramp rate setting
Maxim advertised the ramp rate of the rail with some recommended
design specification like output capacitance of rail should be
2.2uF. This make sure that current change in the rail is within
maximum current limit and hence meet the advertised ramp rate.

If there is variation in design which causes the rail current to
change more that maximum current limit then device applies the
current limit. In this case, ramp rate is different than advertised
ramp rate.

Add device specific settings for ramp rate which need to be configure
on device register when measure ramp rate on platform is deviated from
advertised ramp rate. In this case, all delay time calculation for
voltage change is done with measured ramp rate and device ramp rate
is used for configuring the device register.

If measured ramp rate in the platform is same as advertised ramp rate
then regulator-ramp-delay is used for the device register configuration
and ramp time calculation for voltage change.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-22 16:26:41 +01:00
Jon Hunter dd1a571dae regulator: helpers: Ensure bypass register field matches ON value
When checking bypass state for a regulator, we check to see if any bits
in the bypass mask are set. For most cases this is fine because there is
typically, only a single bit used to determine if the regulator is in
bypass. However, for some regulators, such as LDO6 on AS3722, the bypass
state is indicate by a value rather than a single bit. Therefore, when
checking the bypass state, check that the bypass field matches the ON
value.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-22 11:49:03 +01:00
Jon Hunter c438b9d017 regulator: core: Move registration of regulator device
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>
2016-04-22 11:38:47 +01:00
Mark Brown f89ba3383e Merge branch 'topic/sysfs-init' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-supply 2016-04-22 11:38:42 +01:00
Jon Hunter 8e5356a736 regulator: core: Clear the supply pointer if enabling fails
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>
2016-04-22 11:35:54 +01:00
Jon Hunter 7ddede6a58 regulator: core: Don't terminate supply resolution early
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>
2016-04-22 11:34:47 +01:00
Richard Fitzgerald 2d80a91b2f regulator: core: Add debugfs to show constraint flags
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>
2016-04-22 10:28:52 +01:00
Mark Brown ae714c3b8e regulator: tps6524x: Fix broken use of spi_dev_get()
The tps6524x driver uses spi_dev_get() to take a copy of the SPI device
it uses but has no obvious reason to do so and never calls spi_dev_put()
to release the reference.  Fix this to just a straight copy.

Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-20 17:37:59 +01:00
Wadim Egorov e57cbb70b7 regulator: fan53555: Add support for FAN53555UC13X type
IC type options 00, 13 and 23 are sharing the same DIE_ID 0.
Let's differentiate between these revisions.
FAN53555UC13X has the ID 0 and REV 0xf, starts at 800mV and
increments in 10mV steps.

Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-20 10:57:26 +01:00
Wadim Egorov 5e39cf4972 regulator: fan53555: Add support for FAN53555BUC18X type
FAN53555BUC18X has the DIE_ID 8, starts at 600mV and
increments in 10mV steps.

Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-20 10:57:26 +01:00
Tero Kristo 07c5c3ad98 regulator: core: remove lockdep assert from suspend_prepare
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>
2016-04-18 18:13:24 +01:00
James Ban 99cf3af5e2 regulator: pv88080: new regulator driver
This is the driver for the Powerventure PV88080 BUCKs regulator.
It communicates via an I2C bus to the device.

Signed-off-by: James Ban <James.Ban..opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-18 17:53:57 +01:00
Krzysztof Kozlowski 94be46b9e5 regulator: s2mps11: Set default ramp delay for S2MPS11 LDOs
Driver did not provide default value for ramp delay for LDOs which lead
to warning in dmesg, e.g. on Odroid XU4:

[    1.486076] vdd_ldo9: ramp_delay not set
[    1.506875] vddq_mmc2: ramp_delay not set
[    1.523766] vdd_ldo15: ramp_delay not set
[    1.544702] vdd_sd: ramp_delay not set

The datasheet for all the S2MPS1x family is inconsistent here and does
not specify unambiguously the value of ramp delay for LDO. It mentions
30 mV/us in one timing diagram but then omits it completely in LDO
regulator characteristics table (it is specified for bucks).

However the vendor kernels for Galaxy S5 and Odroid XU3 use values of 12
mV/us or 24 mV/us.

Without the ramp delay value the consumers do not wait for voltage
settle after changing it. Although the proper value of ramp delay for
LDOs is unknown, it seems safer to use at least some value from
reference kernel than to leave it unset.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-18 17:31:38 +01:00
Stephen Boyd b1d21a24df regulator: qcom_spmi: Always return a selector when asked
I had a thinko in spmi_regulator_select_voltage_same_range() when
converting it to return selectors via the function's return value
instead of by modifying a pointer argument. I only tested
multi-range regulators so this passed through testing. Fix it by
returning the selector here.

Fixes: 1b5b196892 ("regulator: qcom_spmi: Only use selector based regulator ops")
Reported-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-18 11:05:11 +01:00
Dan Carpenter 7cb7348f75 regulator: lp3972: Silence uninitialized variable warning
This is harmless but my static checker complains that "tmp" is
uninitialized if lp3972_i2c_read() fails.  I have moved the line of code
below the error handling to silence the warning.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-14 14:46:19 +01:00
Dan Carpenter 40e1d79ee1 regulator: lp3971: Silence uninitialized variable warning
This is harmless but if lp3971_i2c_read() fails then "tmp" can be
uninitialized.  Silence the warning by moving the error handling up a
line.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-14 14:46:05 +01:00
Laxman Dewangan d2d5437bdf regulator: max8973: add support for junction thermal warning
The driver MAX8973 supports the driver for Maxim PMIC MAX77621.
MAX77621 supports the junction temp warning at 120 degC and
140 degC which is configurable. It generates alert signal when
junction temperature crosses these threshold.

MAX77621 does not support the continuous temp monitoring of
junction temperature. It just report whether junction temperature
crossed the threshold or not.

Add support to
- Configure junction temp warning threshold via DT property
to generate alert when it crosses the threshold.
- Add support to interrupt the host from this device when alert
occurred.
- read the junction temp via thermal framework.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-13 17:19:26 +01:00
Mark Brown 2c0a303a12 regulator: core: Fix locking of GPIO list on free
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>
2016-04-13 07:43:00 +01:00
Boris Brezillon 469b640e4f regulator: reorder initialization steps in regulator_register()
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>
2016-04-13 07:33:44 +01:00
Mark Brown fef9501901 regulator: core: Use parent voltage from the supply when bypassed
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>
2016-04-12 05:32:30 +01:00
Thierry Reding 162c5a368f regulator: as3722: Constify regulator ops
A const pointer to regulator ops is stored in regulator descriptors. The
operations never need to be modified, so define them as const as a hint
to the compiler that they can go into .rodata.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-11 15:15:36 +01:00
Jon Hunter 40a865500c regulator: as3722: Add bypass support for LDO6
LD06 on the AS3722 power management IC supports a bypass mode. Bypass
is enabled for the LDO by writing the value 0x3F to the voltage select
field in the control register for the LDO. Note that this is the same
register and field that is used to select the voltage as well for the
LDO.

Add support for bypass on LDO6 by specifying the various bypass
parameters for regulator and adding new function pointer tables for the
LDO. Note that the bypass OFF value is the same as the ON value simply
because there is no actual OFF value and bypass will be disabled when
a new voltage is written to the VSEL field.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-11 15:15:36 +01:00
Javier Martinez Canillas 314a8203b6 regulator: max77686: Use module_platform_driver() instead subsys initcall
The driver's init and exit function don't do anything besides registering
and unregistering the platform driver, so the module_platform_driver()
macro could just be used instead of having separate functions.

Currently the macro is not being used because the driver is initialized at
subsys init call level but this isn't necessary since consumer devices are
defined in the DT as dependencies so there's no need for init calls order.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-06 10:12:26 -07:00
Javier Martinez Canillas 5ab3c49495 regulator: s2mps11: Use module_platform_driver() instead subsys initcall
The driver's init and exit function don't do anything besides registering
and unregistering the platform driver, so the module_platform_driver()
macro could just be used instead of having separate functions.

Currently the macro is not being used because the driver is initialized at
subsys init call level but this isn't necessary since consumer devices are
defined in the DT as dependencies so there's no need for init calls order.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-06 10:12:00 -07:00
Ivaylo Dimitrov 74d8b45fa3 regulator: twl: Fix a typo in twl4030_send_pb_msg
Commit <2330b05c095bdeaaf1261c54cd2d4b9127496996> ("regulator: twl: Make
sure we have access to powerbus before trying to write to it")
has implemented the needed logic to correctly access powerbus through i2c,
however it brought a typo when powerbus configuration is restored, which
results in writing to a wrong register. Fix that by providing the correct
register value.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-06 10:10:50 -07:00
Laxman Dewangan fd786fb027 regulator: pwm: Try to avoid voltage error in duty cycle calculation
In continuous mode of the PWM regulators, the requested voltage
PWM duty cycle is calculated in terms of 100% scale where entire
range denotes 100%. The calculation for PWM pulse ON time(duty_pulse)
is done as:

	duty_cycle = ((requested - minimum) * 100) / voltage_range.

then duty pulse is calculated as
	duty_pulse = (pwm_period/100) * duty_cycle

This leads to the calculation error if we have the requested voltage
where accurate pulse time is possible.
For example: Consider following case
	voltage range is 800000uV to 1350000uV.
	pwm-period = 1550ns (1ns time is 1mV).

	Requested 900000uV.

	duty_cycle = ((900000uV - 800000uV) * 100)/ 1550000
		   = 6.45 but we will get 6.

	duty_pulse = (1550/100) * 6 = 90 pulse time.

90 pulse time is equivalent to 90mV and this gives us pulse time equivalent
to 890000uV instead of 900000uV.

Proposing the solution in which if requested voltage makes the accurate
duty pulse then there will not be any error. On this case, if
(req_uV - min_uV) * pwm_period is perfect dividable by voltage_range
then get the duty pulse time directly.

	duty_pulse = ((900000uV - 800000uV) * 1550)/1550000)
		   = 100

and this is equivalent to 100mV and so final voltage is
(800000 + 100000) = 900000uV which is same as requested,

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-05 11:39:25 -07:00
Krzysztof Kozlowski 724fef5344 regulator: max8997/max77802: Fix misspelled Samsung address
Correct smasung.com into samsung.com.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-05 11:37:49 -07:00
Ivaylo Dimitrov a221f95ef4 regulator: twl: Provide of_map_mode for twl4030
of_map_mode is needed so to be possible to set initial regulators mode from
the board DTS. Otherwise, for DT boot, regulators are left in their default
state after reset/reboot. Document device specific modes as well.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-05 11:35:33 -07:00
Stephen Boyd 1b5b196892 regulator: qcom_spmi: Only use selector based regulator ops
Mixing raw voltage and selector based regulator ops is
inconsistent. This driver already supports some selector based
ops via the list_voltage and set_voltage_time_sel ops but it uses
raw voltage ops for get_voltage and set_voltage. This causes
problems for regulator_set_voltage() and automatic insertion of
slewing delays because set_voltage_time_sel() is only used if the
regulator ops are all selector based. Put another way, delays
aren't happening at all right now when we should be waiting for
voltages to settle. Let's move to pure selector based regulator
ops so that the delays are inserted properly.

Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-31 10:32:41 -07:00