commit 73e705bf ("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: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Added one additional parameter to thermal_zone_device_update() to provide
caller with an optional capability to specify reason.
Currently this event is used by user space governor to trigger different
processing based on event code. Also it saves an additional call to read
temperature when the event is received.
The following events are cuurently defined:
- Unspecified event
- New temperature sample
- Trip point violated
- Trip point changed
- thermal device up and down
- thermal device power capability changed
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>

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>

The X-Powers AXP806 PMIC has a new set of buck and LDO regulators, and
also a switch. The buck regulators support teaming into multi-phase
groups, with A+B, A+B+C, D+E groupings.

Some registers controlling DCDC converter work settings are at different
offsets. Deal with them as well.

Add support for this new variant.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.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>

Add support for the rk818 regulator. The regulator module consists
of 4 DCDCs, 9 LDOs, 1 switch and 1 BOOST converter which is used to
power OTG and HDMI5V.

The output voltages are configurable and are meant to supply power
to the main processor and other components.
Signed-off-by: NWadim Egorov <w.egorov@phytec.de>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Change the MFD config option as per latest naming
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

In order to support the Qualcomm MDM9615 SoC, add support for the
PM8018 RPM regulator in the qcom_rpm-regulator driver.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.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>