summaryrefslogtreecommitdiff
path: root/drivers/regulator
Commit message (Collapse)AuthorAgeFilesLines
* regulator: arizona-ldo1: Correct default regulator init_dataCharles Keepax2014-05-151-4/+3
| | | | | | | | | | | | | | commit a35ff2861690eaf9dbb38fa744a8a9e6f4ebfd61 upstream. Both 5102 and 8997 have the regulator capable of supplying 1.8V, and the voltage step from the 5110 regulator is different from what is specified in the default description. This patch updates the default regulator description to match 5110 and selects the 1.8V capable description for 8997. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
* regulator: core: Replace direct ops->disable usageMarkus Pargmann2014-03-311-21/+13
| | | | | | | | | | | | | | | | commit 66fda75f47dc583f1c187556e9a2c082dd64f8c6 upstream. There are many places where ops->disable is called directly. Instead we should use _regulator_do_disable() which also handles gpio regulators. To be able to use the wrapper function from _regulator_force_disable(), I moved the _notifier_call_chain() call from _regulator_do_disable() to _regulator_disable(). This way, _regulator_force_disable() can use different flags for _notifier_call_chain() without calling it twice. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
* regulator: core: Replace direct ops->enable usageMarkus Pargmann2014-03-221-7/+7
| | | | | | | | | | | | | | | | | | | | | | 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>
* regulator: da9063: Bug fix when setting max voltage on LDOs 5-11Steve Twiss2014-03-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* regulator: pfuze100: Fix address of FABIDAxel Lin2013-12-201-1/+1
| | | | | | | | | | | | 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>
* regulator: pfuze100: allow misprogrammed IDTim Harvey2013-12-041-3/+9
| | | | | | | | | | | | 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>
* regulator: ti-abb: Fix operator precedence typoNishanth Menon2013-12-041-1/+1
| | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'regulator/fix/wm8350' into regulator-linusMark Brown2013-09-301-1/+1
|\
| * regulator: wm8350: correct the max_uV of LDOLaxman Dewangan2013-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'regulator/fix/wm831x' into regulator-linusMark Brown2013-09-301-2/+2
|\ \
| * | regulator: wm831x-ldo: Fix max_uV for gp_ldo and aldo linear range settingsAxel Lin2013-09-231-2/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'regulator/fix/ti-abb' into regulator-linusMark Brown2013-09-301-2/+14
|\ \
| * | regulator: ti-abb: Fix bias voltage glitch in transition to bypass modeNishanth Menon2013-09-271-2/+14
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge remote-tracking branch 'regulator/fix/palmas' into regulator-linusMark Brown2013-09-301-7/+7
|\ \
| * | regulator: palmas: Remove wrong comment for the equation calculating ↵Axel Lin2013-09-171-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | regulator: palmas: configure enable time for LDOsLaxman Dewangan2013-09-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | regulator: palmas: fix the n_voltages for smps to 122Laxman Dewangan2013-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge remote-tracking branch 'regulator/fix/da9063' into regulator-linusMark Brown2013-09-301-1/+1
|\ \ \ | |_|/ |/| |
| * | regulator: da9063: Fix PTR_ERR/ERR_PTR mismatchGeert Uytterhoeven2013-09-101-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge tag 'PTR_RET-for-linus' of ↵Linus Torvalds2013-09-041-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.Rusty Russell2013-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Sweep of the simple cases. Cc: netdev@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Cc: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: David S. Miller <davem@davemloft.net> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* | Merge remote-tracking branch 'regulator/topic/tps65912' into regulator-nextMark Brown2013-09-011-20/+19
|\ \
| * | regulator: tps65912: Convert tps65912_ops_ldo to use linear rangesAxel Lin2013-07-241-20/+19
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ldo voltage table is composed of linear ranges. Below is the equation in original code (tps65912_vsel_to_uv_ldo): 0 ... 32: uv = vsel * 25000 + 800000; 33 ... 60: uv = (vsel - 32) * 50000 + 1600000; = (vsel -33) * 50000 + 1650000; 61 ...63: uv = (vsel - 60) * 100000 + 3000000; = (vsel - 61) * 100000 + 3100000; This patch converts tps65912_ops_ldo to use multiple linear ranges APIs. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* | Merge remote-tracking branch 'regulator/topic/ti-abb' into regulator-nextMark Brown2013-09-011-10/+0
|\ \
| * | regulator: ti-abb: simplify platform_get_resource_byname/devm_ioremap_resourceJulia Lawall2013-08-221-10/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'regulator/topic/sec' into regulator-nextMark Brown2013-09-011-45/+200
|\ \
| * | regulator: s2mps11: Fix setting ramp_delayAxel Lin2013-08-131-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | regulator: s2mps11: Fix wrong arguments for regmap_update_bits() callAxel Lin2013-08-131-2/+2
| | | | | | | | | | | | | | | | | | | | | Current code calls regmap_update_bits() with mask and val arguments swapped. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: s2mps11: Convert driver completely to use set_ramp_delay callbackYadwinder Singh Brar2013-07-151-53/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since now we have ramp_delay and ramp_disable as standard regulator constraints and DT part using it so this patch removes legacy part i.e. getting ramp_delayxx and ramp_enable from pdata since it can be passed as standard regulator constraints. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: s2mps11: Add DT supportYadwinder Singh Brar2013-07-151-11/+38
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds DT support for parsing regulators constraints for parent(mfd) node and moves some common intialising code out of loop while registering. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: s2mps11: Implement set_ramp_rate callback for bucksYadwinder Singh Brar2013-07-151-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implementing set_ramp_rate() and using standard constraints for getting ramp_delay and ramp_disable, instead of getting it as s2mps11 specific data through platform data, makes driver more compliant with framework and reduces the complexity for adding DT support. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | Merge branch 'topic/ramp' of ↵Mark Brown2013-07-152-6/+13
| |\ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-sec
| * | | regulator: s2mps11: Implement set_voltage_time_sel() ops for bucksYadwinder Singh Brar2013-07-151-1/+52
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | Currently driver uses local struct s2mps11_info to store ramp rate for bucks whic its getting through platform data, so instead of using regulator constraints it should use s2mps11_info to calculate ramp delay. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* | | Merge remote-tracking branch 'regulator/topic/ramp' into regulator-nextMark Brown2013-09-012-6/+13
|\ \ \ | | |/ | |/|
| * | regulator: core: Remove redundant checksYadwinder Singh Brar2013-07-151-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In function _regulator_do_set_voltage(), old_selector gets intialised only if (_regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel && rdev->desc->ops->get_voltage_sel)) is true. Before calling set_voltage_time_sel() we checks if (old_selector >= 0) and it will true if it got intialised properly. so we don't need to check again _regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel before calling set_voltage_time_sel(). Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: core: Add support for disabling ramp delayYadwinder Singh Brar2013-07-152-5/+13
| |/ | | | | | | | | | | | | | | | | | | | | Some hardwares support disabling ramp delay, so adding ramp_disable flag to constraints. It will be used to figure out whether ramp_delay in constraints is explicitly set to zero or its unintialized (zero by default). And we don't need to call set_voltage_time_sel() for regulators for whom ramp delay is disabled in constraints. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* | Merge remote-tracking branch 'regulator/topic/pfuze100' into regulator-nextMark Brown2013-09-013-0/+454
|\ \
| * | regulator: pfuze100: Fix off-by-one for max_register settingAxel Lin2013-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | max_register should be register count - 1. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Robin Gong <b38343@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: pfuze100: Simplify pfuze100_set_ramp_delay implementationAxel Lin2013-07-311-16/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplify the equation to calculate ramp_delay. Below equations are equivalent: ramp_delay = 25000 / (2 * ramp_delay); ramp_delay = 50000 / (4 * ramp_delay); ramp_delay = 25000 / (2 * ramp_delay); ramp_delay = 12500 / ramp_delay; So we don't need to read BIT6 of rdev->desc->vsel_reg for applying different equations. Also use rdev->desc->vsel_reg instead of run-time calculate register address. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Robin Gong <b38343@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: pfuze100: Fix n_voltages setting for SW2~SW4 with high bit setAxel Lin2013-07-301-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current code adjust min_uV and uV_step but missed adjusting the n_voltages setting. When BIT6 is clear: n_voltages = (1975000 - 400000) / 25000 + 1 = 64 When BIT6 is set: n_voltages = (3300000 - 800000) / 50000 + 1 = 51 The n_voltages needs update because when BIT6 is set 0x73 ~ 0x7f are reserved. When using regulator_list_voltage_linear, the n_voltages does matter here because wrong n_voltages setting make the equation return wrong result. e.g. if selector is 63, regulator_list_voltage_linear returns 800000 + (50000 * 63) = 4000000 It should return -EINVAL if the selector is in the range of 51 ~ 63. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: pfuze100: Use regulator_map_voltage_ascendAxel Lin2013-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | All table based voltage list have ascendant order. Use regulator_map_voltage_ascend for them. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: pfuze100: Fix module alias prefixAxel Lin2013-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | i2c drivers use "i2c:" prefix for module alias. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: pfuze100: Use i2c_[set|get]_clientdataAxel Lin2013-07-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Since this is a i2c driver, use i2c_[set|get]_clientdata instead of dev_[set|get]_drvdata. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: pfuze100: REGULATOR_PFUZE100 needs to select REGMAP_I2CAxel Lin2013-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes below build errors: CC [M] drivers/regulator/pfuze100-regulator.o drivers/regulator/pfuze100-regulator.c:342:21: error: variable 'pfuze_regmap_config' has initializer but incomplete type drivers/regulator/pfuze100-regulator.c:343:2: error: unknown field 'reg_bits' specified in initializer drivers/regulator/pfuze100-regulator.c:343:2: warning: excess elements in struct initializer [enabled by default] drivers/regulator/pfuze100-regulator.c:343:2: warning: (near initialization for 'pfuze_regmap_config') [enabled by default] drivers/regulator/pfuze100-regulator.c:344:2: error: unknown field 'val_bits' specified in initializer drivers/regulator/pfuze100-regulator.c:344:2: warning: excess elements in struct initializer [enabled by default] drivers/regulator/pfuze100-regulator.c:344:2: warning: (near initialization for 'pfuze_regmap_config') [enabled by default] drivers/regulator/pfuze100-regulator.c:345:2: error: unknown field 'max_register' specified in initializer drivers/regulator/pfuze100-regulator.c:345:2: warning: excess elements in struct initializer [enabled by default] drivers/regulator/pfuze100-regulator.c:345:2: warning: (near initialization for 'pfuze_regmap_config') [enabled by default] drivers/regulator/pfuze100-regulator.c:346:2: error: unknown field 'cache_type' specified in initializer drivers/regulator/pfuze100-regulator.c:346:2: warning: excess elements in struct initializer [enabled by default] drivers/regulator/pfuze100-regulator.c:346:2: warning: (near initialization for 'pfuze_regmap_config') [enabled by default] drivers/regulator/pfuze100-regulator.c: In function 'pfuze100_regulator_probe': drivers/regulator/pfuze100-regulator.c:370:2: error: implicit declaration of function 'devm_regmap_init_i2c' [-Werror=implicit-function-declaration] drivers/regulator/pfuze100-regulator.c:370:21: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors make[2]: *** [drivers/regulator/pfuze100-regulator.o] Error 1 make[1]: *** [drivers/regulator] Error 2 make: *** [drivers] Error 2 Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: pfuze100: add MODULE_LICENSE() in pfuze100 driverRobin Gong2013-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix building error on x86_64 and i386: WARNING: modpost: missing MODULE_LICENSE() in drivers/regulator/pfuze100-regulator.o Signed-off-by: Robin Gong <b38343@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator:pfuze100: fix build warning and correct the binding docRobin Gong2013-07-261-1/+1
| | | | | | | | | | | | | | | | | | | | | fix building warning and correct the binding doc Signed-off-by: Robin Gong <b38343@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * | regulator: pfuze100: add pfuze100 regulator driverRobin Gong2013-07-253-0/+462
| | | | | | | | | | | | | | | | | | | | | | | | Add pfuze100 regulator driver. Signed-off-by: Robin Gong <b38343@freescale.com> Tested-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org>
* | | Merge remote-tracking branch 'regulator/topic/palmas' into regulator-nextMark Brown2013-09-011-6/+24
|\ \ \
| * | | regulator: palmas: model SMPS10 as two regulatorsKishon Vijay Abraham I2013-08-121-6/+24
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SMPS10 has two outputs OUT1 and OUT2 and have one input IN1. SMPS10-OUT2 is connected to SMPS10-IN1 and can be configured either in BOOST mode or BYPASS mode. regulator_enable of SMPS10-OUT2 configures it in BOOST mode. For BYPASS mode regulator_allow_bypass() API can be used. SMPS10-OUT1 is connected to SMPS10-OUT2 and can be enabled using regulator_enable(). [ axel.lin@ingics.com : Simplify regulator_desc setting for SMPS10_[OUT1|OUT2] Signed-off-by: J Keerthy <j-keerthy@ti.com> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* | | Merge remote-tracking branch 'regulator/topic/optional' into regulator-nextMark Brown2013-09-011-0/+89
|\ \ \
View Lorry Controller Status