summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2015-02-13Reset to 3.12.37Scott Wood
2014-05-14Reset to 3.12.19Scott Wood
2014-03-22regulator: core: Replace direct ops->enable usageMarkus Pargmann
commit 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b upstream. There are some direct ops->enable in the regulator core driver. This is a potential issue as the function _regulator_do_enable() handles gpio regulators and the normal ops->enable calls. These gpio regulators are simply ignored when ops->enable is called directly. One possible bug is that boot-on and always-on gpio regulators are not enabled on registration. This patch replaces all ops->enable calls by _regulator_do_enable. [Handle missing enable operations -- broonie] Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
2014-03-05regulator: da9063: Bug fix when setting max voltage on LDOs 5-11Steve Twiss
commit ebf6dad0de89677aa58a4d8b009014ff88a23452 upstream. Bug fix to allow the setting of maximum voltage for certain LDOs. What the bug is: There is a problem caused by an invalid calculation of n_voltages in the driver. This n_voltages value has the potential to be different for each regulator. The value for linear_min_sel is set as DA9063_V##regl_name# which can be different depending upon the regulator. This is chosen according to the following definitions in the DA9063 registers.h file: DA9063_VLDO1_BIAS 0 DA9063_VLDO2_BIAS 0 DA9063_VLDO3_BIAS 0 DA9063_VLDO4_BIAS 0 DA9063_VLDO5_BIAS 2 DA9063_VLDO6_BIAS 2 DA9063_VLDO7_BIAS 2 DA9063_VLDO8_BIAS 2 DA9063_VLDO9_BIAS 3 DA9063_VLDO10_BIAS 2 DA9063_VLDO11_BIAS 2 The calculation for n_voltages is valid for LDOs whose BIAS value is zero but this is not correct for those LDOs which have a non-zero value. What the fix is: In order to take into account the non-zero linear_min_sel value which is set for the regulators LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 and LDO11, the calculation for n_voltages should take into account the missing term defined by DA9063_V##regl_name#. This will in turn allow the core constraints calculation to set the maximum voltage limits correctly and therefore allow users to apply the maximum expected voltage to all of the LDOs. Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
2013-12-20regulator: pfuze100: Fix address of FABIDAxel Lin
commit a1b6fa85c639ad0d5447d1a5e7d1463bbe29fcd3 upstream. According to the datasheet, the address of FABID is 0x4. Fix it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Robin Gong <b38343@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-04regulator: pfuze100: allow misprogrammed IDTim Harvey
commit 88baf7148e899db7e0b676e4363647f50e48eaed upstream. prior to week 08 of 2013 Freescale misprogrammed between 1 and 3% of PFUZE1000 parts with a ID=0x8 instead of the expected ID=0x0 Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-04regulator: ti-abb: Fix operator precedence typoNishanth Menon
commit 9a633a2bced158c57b73cf4d8e87be60473de1d2 upstream. commit 40b1936e (regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver) missed a pair of brackets which cause the wrong vset data to be picked up from efuse, resulting in bad VBB voltage values. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-30Merge remote-tracking branch 'regulator/fix/wm8350' into regulator-linusMark Brown
2013-09-30Merge remote-tracking branch 'regulator/fix/wm831x' into regulator-linusMark Brown
2013-09-30Merge remote-tracking branch 'regulator/fix/ti-abb' into regulator-linusMark Brown
2013-09-30Merge remote-tracking branch 'regulator/fix/palmas' into regulator-linusMark Brown
2013-09-30Merge remote-tracking branch 'regulator/fix/da9063' into regulator-linusMark Brown
2013-09-27regulator: ti-abb: Fix bias voltage glitch in transition to bypass modeNishanth Menon
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
2013-09-23regulator: wm831x-ldo: Fix max_uV for gp_ldo and aldo linear range settingsAxel Lin
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>
2013-09-19regulator: wm8350: correct the max_uV of LDOLaxman Dewangan
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>
2013-09-16regulator: palmas: Remove wrong comment for the equation calculating ↵Axel Lin
num_voltages 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>
2013-09-10regulator: da9063: Fix PTR_ERR/ERR_PTR mismatchGeert Uytterhoeven
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>
2013-09-10regulator: palmas: configure enable time for LDOsLaxman Dewangan
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>
2013-09-05Merge tag 'PTR_RET-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux 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
2013-09-04regulator: palmas: fix the n_voltages for smps to 122Laxman Dewangan
With the following change --------- commit ad02e846878ca35e9d3fa584be8ee770e9e14fce 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>
2013-09-01Merge remote-tracking branch 'regulator/topic/tps65912' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/ti-abb' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/sec' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/ramp' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/pfuze100' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/palmas' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/optional' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/max8660' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/lp8755' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/lp872x' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/linear-range' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/kconfig' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/helpers' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/da9063' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2013-09-01Merge remote-tracking branch 'regulator/topic/as3711' into regulator-nextMark Brown
2013-09-01regulator: da9063: Statize da9063_ldo_lim_eventAxel Lin
da9063_ldo_lim_event() is only referenced in this driver, make it static. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-30regulator: lp872x: Make REGULATOR_LP872X depend on I2C rather than I2C=yAxel Lin
lp872x regulator driver can be built a module after commit 631a1fc "regulator: build: Allow most regulators to be built as modules". Make REGULATOR_LP872X depend on I2C to allow building lp872x module when I2C=m. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-30regulator: tps65217: Convert to use linear rangesAxel Lin
Below is the equation in original code: tps65217_uv1_ranges: 0 ... 24: uV = vsel * 25000 + 900000; 25 ... 52: uV = (vsel - 24) * 50000 + 1500000; = (vsel - 25) * 50000 + 1550000; 53 ... 55: uV = (vsel - 52) * 100000 + 2900000; = (vsel - 53) * 100000 + 3000000; 56 ... 62: uV = 3300000; tps65217_uv2_ranges: 0 ... 8: uV = vsel * 50000 + 1500000; 9 ... 13: uV = (vsel - 8) * 100000 + 1900000; = (vsel - 9) * 100000 + 2000000; 14 ... 31: uV = (vsel - 13) * 50000 + 2400000; = (vsel - 14) * 50000 + 2450000; The voltage tables are composed of linear ranges. This patch converts this driver to use multiple linear ranges APIs. In original code, voltage range for DCDC1 is 900000 ~ 1800000 and voltage range for DCDC3 is 900000 ~ 1500000. This patch separates the range 25~52 in tps65217_uv1_ranges table to two linear ranges: 25~30 and 31~52. This change makes it possible to reuse the same linear_ranges table for DCDCx. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-30regulator: da9063: Use IS_ERR to check return value of regulator_register()Axel Lin
regulator_register() does not return NULL, it returns ERR_PTR on error. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-30regulator: da9063: Optimize da9063_set_current_limit implementationAxel Lin
All the current limit tables have the values in ascend order. So we can slightly optimize the for loop iteration because the first match is the minimal value. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-29regulator: build: Allow most regulators to be built as modulesMark Brown
Mostly for testing without bloating the kernel image rather than actual utility. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-29regulator: Add devm_regulator_get_exclusive()Matthias Kaehlcke
Add a resource managed regulator_get_exclusive() Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-29regulator: da9063: Add Dialog DA9063 voltage regulators support.Krystian Garbaciak
The driver adds support for the following DA9063 PMIC regulators: - 11x LDOs (named LDO1 - LDO11), - 6x buck converters (BCORE1, BCORE2, BPRO, BMEM, BIO, BPERI), Regulators provide following operations: - REGULATOR_CHANGE_STATUS and REGULATOR_CHANGE_VOLTAGE for all regulators, - REGULATOR_CHANGE_MODE for LDOs and buck converters, where: - LDOs allow REGULATOR_MODE_NORMAL and REGULATOR_MODE_STANDBY, - buck converters allow REGULATOR_MODE_FAST, REGULATOR_MODE_NORMAL and REGULATOR_MODE_STANDBY, - REGULATOR_CHANGE_CURRENT for buck converters (current limits). The driver generates REGULATOR_EVENT_OVER_CURRENT for LDO3, LDO4, LDO7, LDO8 and LDO11. Internally, PMIC provides two voltage configurations for normal and suspend system state for each regulator. The driver switches between those on suspend/wake-up to provide quick and fluent output voltage change. This driver requires MFD core driver for operation. Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-22regulator: ti-abb: simplify platform_get_resource_byname/devm_ioremap_resourceJulia Lawall
Remove unneeded error handling on the result of a call to platform_get_resource_byname when the value is passed to devm_ioremap_resource. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression pdev,res,e,e1; expression ret != 0; identifier l; @@ res = platform_get_resource_byname(...); - if (res == NULL) { ... \(goto l;\|return ret;\) } e = devm_ioremap_resource(e1, res); // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-18regulator: core: Use bool for exclusivitity flagMark Brown
Just for neatness. Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-14regulator: 88pm800: forever loop in pm800_regulator_probe()Dan Carpenter
This is supposed to be testing "i < ARRAY_SIZE()" instead of just "ARRAY_SIZE()". Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-13regulator: da9210: Remove redundant MODULE_ALIASAxel Lin
The modalias is set by the MODULE_DEVICE_TABLE, thus remove redundant MODULE_ALIAS. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-13regulator: 88pm800: Fix checking whether num_regulator is validAxel Lin
The code to check whether num_regulator is valid is wrong because it should iterate all array entries rather than break from the for loop if pdata->regulators[i] is NULL. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-13regulator: s2mps11: Fix setting ramp_delayAxel Lin
Current code has wrong mask and val arguments for updating ramp_delay. Fix it. Also ensure the return value of get_ramp_delay() won't greater than 3 because the mask field for ramp_val only takes 2 bits. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>