linux-toradex.git/drivers/regulator, branch v3.12-rc7 Linux kernel for Apalis and Colibri modules Merge remote-tracking branch 'regulator/fix/wm8350' into regulator-linus 2013-09-30T11:04:33+00:00 Mark Brown broonie@linaro.org 2013-09-30T11:04:33+00:00 f3d17a7e4d9ea9301fd2608c25de7802239e5fbb 






Merge remote-tracking branch 'regulator/fix/wm831x' into regulator-linus
2013-09-30T11:04:33+00:00

Mark Brown
broonie@linaro.org

2013-09-30T11:04:33+00:00

60c32f3ec879d7e75a5b7d1c57ba8acb6583d1bf












Merge remote-tracking branch 'regulator/fix/ti-abb' into regulator-linus
2013-09-30T11:04:32+00:00

Mark Brown
broonie@linaro.org

2013-09-30T11:04:32+00:00

0f5da28f93fb847a0aa64d359d46b99c73cd1d6e












Merge remote-tracking branch 'regulator/fix/palmas' into regulator-linus
2013-09-30T11:04:31+00:00

Mark Brown
broonie@linaro.org

2013-09-30T11:04:31+00:00

780a0ff76e9527fe7c784aa7250dcfc449560535












Merge remote-tracking branch 'regulator/fix/da9063' into regulator-linus
2013-09-30T11:04:29+00:00

Mark Brown
broonie@linaro.org

2013-09-30T11:04:29+00:00

e7b87825e8100e1e1456840fc0d99a951631c036












regulator: ti-abb: Fix bias voltage glitch in transition to bypass mode
2013-09-27T14:02:04+00:00

Nishanth Menon
nm@ti.com

2013-09-27T13:25:14+00:00

bf00ca35cec8f0894dcfd90f88b03af1d5c7b86f

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





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







regulator: wm831x-ldo: Fix max_uV for gp_ldo and aldo linear range settings
2013-09-23T11:04:54+00:00

Axel Lin
axel.lin@ingics.com

2013-09-23T07:54:20+00:00

f3ef11b485db3fa57e635c64a3fd86533f5e42c8

Fix the linear range settings in commit 5ff26a14c3331
"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>





Fix the linear range settings in commit 5ff26a14c3331
"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>







regulator: wm8350: correct the max_uV of LDO
2013-09-19T13:15:57+00:00

Laxman Dewangan
ldewangan@nvidia.com

2013-09-19T12:39:55+00:00

087e35ad71aac1daab0fcd21b61da15ffe7aaec5

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>





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>







regulator: palmas: Remove wrong comment for the equation calculating num_voltages
2013-09-16T23:52:13+00:00

Axel Lin
axel.lin@ingics.com

2013-09-12T01:38:12+00:00

ae3e101286df40cdde49c4737e2868289ed7f35b

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>





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>







regulator: da9063: Fix PTR_ERR/ERR_PTR mismatch
2013-09-10T17:11:41+00:00

Geert Uytterhoeven
geert@linux-m68k.org

2013-09-09T11:49:26+00:00

e8cb204c675e05105ab2c93c73c57607e09d6b41

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>





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>