We get 2 warnings when building kernel with W=1:
drivers/regulator/dbx500-prcmu.c:78:6: warning: no previous prototype for 'ux500_regulator_suspend_debug' [-Wmissing-prototypes]
drivers/regulator/dbx500-prcmu.c:87:6: warning: no previous prototype for 'ux500_regulator_resume_debug' [-Wmissing-prototypes]

In fact, these functions are unused in
dbx500-prcmu.c, but should be removed.

So this patch removes the unused functions.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Three files are modified, the driver, header file and the binding document.

Updates for the regulator source file include and .of_match_table entry
and node match checking in the probe() function for a compatible pv88080
silicon type. A new "HVBUCK" is added in source file and added
regsiter definition in header file for pv88080 bb silicion.
The binding documentation changes have been made to reflect these updates.
Signed-off-by: NEric Jeong <eric.jeong.opensource@diasemi.com>
Signed-off-by: NMark 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: NJoonwoo Park <joonwoop@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

http://www.ti.com/lit/pdf/SWCZ010:
  DCDC o/p voltage can go higher than programmed value

Impact:
VDDI, VDD2, and VIO output programmed voltage level can go higher than
expected or crash, when coming out of PFM to PWM mode or using DVFS.

Description:
When DCDC CLK SYNC bits are 11/01:
* VIO 3-MHz oscillator is the source clock of the digital core and input
  clock of VDD1 and VDD2
* Turn-on of VDD1 and VDD2 HSD PFETis synchronized or at a constant
  phase shift
* Current pulled though VCC1+VCC2 is Iload(VDD1) + Iload(VDD2)
* The 3 HSD PFET will be turned-on at the same time, causing the highest
  possible switching noise on the application. This noise level depends
  on the layout, the VBAT level, and the load current. The noise level
  increases with improper layout.

When DCDC CLK SYNC bits are 00:
* VIO 3-MHz oscillator is the source clock of digital core
* VDD1 and VDD2 are running on their own 3-MHz oscillator
* Current pulled though VCC1+VCC2 average of Iload(VDD1) + Iload(VDD2)
* The switching noise of the 3 SMPS will be randomly spread over time,
  causing lower overall switching noise.

Workaround:
Set DCDCCTRL_REG[1:0]= 00.
Signed-off-by: NJan Remmet <j.remmet@phytec.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.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: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMark 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: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMark 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: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

We get 1 warning when building kernel with W=1:
drivers/regulator/hi6421-regulator.c:480:14: warning: no previous prototype for
'hi6421_regulator_ldo_get_optimum_mode' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fix typo in regulator Kconfig for the TPS80031 tristate string (trivial)
Signed-off-by: NSebastiaan Schalbroeck <schalbroeck@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Change my email address to kernel.org instead of Samsung one for the
purpose of any future contact.  The copyrights remain untouched and are
attributed to Samsung.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMark 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 3ff3f518.
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch adds support for the Linear Technology LTC3676
8-output I2C voltage regulator IC.

Cc: Jaffer Kapasi <jkapasi@linear.com>
Signed-off-by: NTim Harvey <tharvey@gateworks.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The field "owner" is set by core. Thus delete an extra initialisation.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The voltage ranges listed here are wrong. The pma8084 pldo
supports three different overlapping voltage ranges with
differing step sizes and the pma8084 ftsmps supports two. These
ranges can be seen in the "native" spmi regulator driver
(qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
respectively. Port these ranges over to the RPM SMD regulator
driver so that we list the appropriate set of supported voltages
on these types of regulators.

Fixes: ee01d0c9 ("regulator: qcom-smd: Add support for PMA8084")
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Reviewed-by: NAndy Gross <andy.gross@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The voltage ranges listed here are wrong. The correct ranges can
be seen in the "native" spmi regulator driver
qcom_spmi-regulator.c at pldo_ranges[], ftsmps_ranges[] and
boost_ranges[] for the pldo, ftsmps, and boost type regulators.
Port these ranges over to the RPM SMD regulator driver so that we
list the appropriate set of supported voltages on pldos.

Doing this allows us to specify a voltage like 3075000 for l24,
whereas before that wasn't a supported voltage.

Fixes: da65e367 ("regulator: Regulator driver for the Qualcomm RPM")
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Reviewed-by: NAndy Gross <andy.gross@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The continuous mode allows one to declare a PWM regulator without having
to declare the voltage <-> dutycycle association table. It works fine as
long as your voltage(dutycycle) function is linear, but also has the
following constraints:

- dutycycle for min_uV = 0%
- dutycycle for max_uV = 100%
- dutycycle for min_uV < dutycycle for max_uV

While the linearity constraint is acceptable for now, we sometimes need to
restrict of the PWM range (to limit the maximum/minimum voltage for
example) or have a min_uV_dutycycle > max_uV_dutycycle (this could be
tweaked with PWM polarity, but not all PWMs support inverted polarity).

Add the pwm-dutycycle-range and pwm-dutycycle-unit DT properties to define
such constraints. If those properties are not defined, the PWM regulator
use the default pwm-dutycycle-range = <0 100> and
pwm-dutycycle-unit = <100> values (existing behavior).
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

This fix alters the minimum and maximum BUCK voltage limits for DA9052 and
DA9053. It does so for the following cases:

DA9052
- BUCK3 (MEM)
   min: 0.925V -> 0.950V
   max: 2.500V -> 2.525V

DA9053
- BUCK3 (MEM)
   min: 0.925V -> 0.950V
   max: 2.500V -> 2.525V
- BUCK4 (PERI)
   min: 0.925V -> 0.950V
   max: 2.500V -> 2.525V

The voltage range remains the same, but the limits are shifted by +0.025V.

This change is provided on DA9052:MEM, DA9053:MEM and DA9053:PERI
and is a voltage difference of 0.025V, compared to those measured before
this fix is applied. The patch has the effect of decreasing *all* measured
voltages on those BUCKs when compared against the previously measured
values for the same software voltage request.

For example, with this fix applied for DA9052:MEM, DA9053:MEM and
DA9053:PERI, the following is true.

Because the previous software defined slot 0 as being 0.925V, if a request
for 0.950V was previously sent, the slot 1 voltage would have been used.
This would have corresponded to an actual measured voltage of 0.975V. But,
with this patch fix, and with slot 0 properly aligned to 0.950V, if a
voltage of 0.950V is requested by software, a measured value of 0.950V will
be provided.
Tested-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.
Signed-off-by: NChen Zhong <chen.zhong@mediatek.com>
Signed-off-by: NJohn Crispin <john@phrozen.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Addition of device tree support for DA9210.
Two files are modified, the driver source file and the binding document.

Updates for the regulator source file include an .of_match_table entry and
node match checking in the probe() function for a compatible da9210 string.

Minor binding documentation changes have been made to the title and the
example.
Tested-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This node pointer is returned by of_get_child_by_name() with
refcount incremented in this function. of_node_put() is missing
when exitting this function while invalid device type. Fix it
by move of_get_child_by_name() code after device type check.

Found by Coccinelle.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NMark Brown <broonie@kernel.org>

There is only one instance of ab8500_regulator_platform_data, and it's
safe to assume we won't ever merge another one, so it's rather pointless
to pass it through multiple levels of platform data pointers.

This moves the structure and everything referenced by it into the
driver that uses it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The pm8x41_hfsmps ranges overlap. The first range is from 375000
to 1562500:

 375000 + (95 * 12500) == 1562500

and the second range starts at 1550000. Interestingly, the second
range ends at the correct value when it's set to be the
appropriate start value, 1575000:

 1575000 + ((158 - 96) * 25000) == 3125000
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Reviewed-by: NAndy Gross <andy.gross@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch fixes some of the LDOs and BUCKs voltage range as per
user manual of s2mps15 (REV0.4).

Fixes: 51af2067 ("regulator: s2mps11: Add support for S2MPS15 regulators")
Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

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 fd786fb0 ("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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

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: 4773be18 ("regulator: pwm-regulator: Add support for continuous-voltage")
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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: NVenkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is a patch for adding description for da9212/da9214.
Signed-off-by: NJames Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Extend the driver to support Ricoh RN5T567. Support the additional
DCDC and slightly different voltage range of LDORTC1.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

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: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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: NRuss Dill <Russ.Dill@ti.com>
[Enhanced commit log and added dynamic allocation for strobes]
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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: e92a4047 ("regulator: Add QCOM SPMI regulator driver")
Signed-off-by: NStephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

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: e92a4047 ("regulator: Add QCOM SPMI regulator driver")
Signed-off-by: NStephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>