As documented in Application Note SWPA117 v2.1(NDA), LDO override has a
requirement that when switching from Bias active + override active
mode(FBB/RBB) to Bypass(nominal) mode, LDO reset must be performed
*after* LDO transitions to Bypass(nominal) mode.
The same rule in reverse applies when switching from a ABB bypass mode
to ABB enabled - LDO override *must* be performed prior to transition to
required ABB mode, if we do not do that, the same glitch takes place.
Currently while transitioning to ABB bypass, we reset the LDO overide
prior to the transition which causes a few milliseconds where ABB LDO
voltage could go all the way to 800mV(based on SoC process node),
during this period, the delta voltage between VDD rail and VBB rail
could cause the system to improperly function.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
Fix the linear range settings in commit 5ff26a14c3
"regulator: wm831x-ldo: Convert to use linear ranges".
For wm831x_gp_ldo:
We have below equations for list voltage before converting to linear ranges:
sel <= 0xe:
volt = 0.9-1.6V in 50mV steps
sel <= 0x1f:
volt = 1.7-3.3V in 100mV steps
max_uV for the first linear range should be 1600000 rather than 1650000. Fix it.
For wm831x_aldo:
We have below equations for list voltage before converting to linear ranges:
sel <= 0xc:
volt = 1-1.6V in 50mV steps
sel <= 0x1f
volt = 1.7-3.5V in 100mV steps
max_uV for the first linear range should be 1600000 rather than 1650000. Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
As per datasheet, voltage range for LDOs are as follows:
0000 = 0.9V
...(50mV steps)
01111 = 1.65V
10000 = 1.8V
... (100mV stepns)
11111 = 3.3V
So, there is no selector for 1.65V to 1.8V.
Correcting the range for max_uV for selector between 0 to 15.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Current equation on the comment is wrong.
For linear mapping starting from 0, the equation is (maxV-minV)/stepV + 1.
Since the linear mapping for PALMAS is not all starting from 0, the equation
on the comment is not useful and misleading. Thus remove it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
If CONFIG_OF=n:
drivers/regulator/da9063-regulator.c: In function ‘da9063_parse_regulators_dt’:
drivers/regulator/da9063-regulator.c:712: warning: passing argument 1 of ‘PTR_ERR’ makes pointer from integer without a cast
drivers/regulator/da9063-regulator.c:712: warning: return makes pointer from integer without a cast
Use ERR_PTR() to encode an error code in a pointer.
PTR_ERR() is meant to decode an error code from a pointer.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
As per datasheet (Referred TPS65913), the on-time for LDO is
500micro second. If LDO6 is in vibrator mode then the on-time
is 2000us.
Set the enable_time on regulator descriptor accordingly.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Pull PTR_RET() removal patches from Rusty Russell:
"PTR_RET() is a weird name, and led to some confusing usage. We ended
up with PTR_ERR_OR_ZERO(), and replacing or fixing all the usages.
This has been sitting in linux-next for a whole cycle"
[ There are still some PTR_RET users scattered about, with some of them
possibly being new, but most of them existing in Rusty's tree too. We
have that
#define PTR_RET(p) PTR_ERR_OR_ZERO(p)
thing in <linux/err.h>, so they continue to work for now - Linus ]
* tag 'PTR_RET-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
GFS2: Replace PTR_RET with PTR_ERR_OR_ZERO
Btrfs: volume: Replace PTR_RET with PTR_ERR_OR_ZERO
drm/cma: Replace PTR_RET with PTR_ERR_OR_ZERO
sh_veu: Replace PTR_RET with PTR_ERR_OR_ZERO
dma-buf: Replace PTR_RET with PTR_ERR_OR_ZERO
drivers/rtc: Replace PTR_RET with PTR_ERR_OR_ZERO
mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().
staging/zcache: don't use PTR_RET().
remoteproc: don't use PTR_RET().
pinctrl: don't use PTR_RET().
acpi: Replace weird use of PTR_RET.
s390: Replace weird use of PTR_RET.
PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.
PTR_RET is now PTR_ERR_OR_ZERO
With the following change
---------
commit ad02e84687
Author: Axel Lin <axel.lin@ingics.com>
regulator: palmas: Return raw register values as the selectors in [get|set]_voltage_sel
Don't adjust the selector in [get|set]_voltage_sel, fix it in list_voltage() instead.
For smps*(except smps10), the vsel reg-value and voltage mapping as below:
----------
The list_voltage() takes the true value of selector which is
programmed in the register. As per smsp voltage table
reg-value volt (uV) ( Assume RANGE is x1 )
0 0
1 500000
2 500000
3 500000
4 500000
5 500000
6 500000 (0.49V + 1 * 0.01V) * RANGE
7 510000 (0.49V + 2 * 0.01V) * RANGE
8 520000 (0.49V + 3 * 0.01V) * RANGE
9 530000 (0.49V + 4 * 0.01V) * RANGE
....
121 1650000 (0.49V + 116 * 0.1) * RANGE
Hence making n_voltages for smps to 122.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
