summaryrefslogtreecommitdiffstats
path: root/drivers/regulator
Commit message (Collapse)AuthorAgeFilesLines
* regulator: act8865: Fix act8600_sudcdc_voltage_ranges settingAxel Lin2019-04-271-2/+3
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f01a7beb6791f1c419424c1a6958b7d0a289c974 ] The act8600_sudcdc_voltage_ranges setting does not match the datasheet. The problems in below entry: REGULATOR_LINEAR_RANGE(19000000, 191, 255, 400000), 1. The off-by-one min_sel causes wrong volatage calculation. The min_sel should be 192. 2. According to the datasheet[1] Table 7. (on page 43): The selector 248 (0b11111000) ~ 255 (0b11111111) are 41.400V. Also fix off-by-one for ACT8600_SUDCDC_VOLTAGE_NUM. [1] https://active-semi.com/wp-content/uploads/ACT8600_Datasheet.pdf Fixes: df3a950e4e73 ("regulator: act8865: Add act8600 support") Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: s2mpa01: Fix step values for some LDOsStuart Menefy2019-03-231-5/+5
| | | | | | | | | | | | | | | commit 28c4f730d2a44f2591cb104091da29a38dac49fe upstream. The step values for some of the LDOs appears to be incorrect, resulting in incorrect voltages (or at least, ones which are different from the Samsung 3.4 vendor kernel). Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: s2mps11: Fix steps for buck7, buck8 and LDO35Krzysztof Kozlowski2019-03-231-3/+3
| | | | | | | | | | | | | | | | commit 56b5d4ea778c1b0989c5cdb5406d4a488144c416 upstream. LDO35 uses 25 mV step, not 50 mV. Bucks 7 and 8 use 12.5 mV step instead of 6.25 mV. Wrong step caused over-voltage (LDO35) or under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420 Arndale Octa board). Cc: <stable@vger.kernel.org> Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: pfuze100: add .is_enable() for pfuze100_swb_regulator_opsAnson Huang2018-08-061-0/+1
| | | | | | | | | | | | | | | [ Upstream commit 0b01fd3d40fe6402e5fa3b491ef23109feb1aaa5 ] If is_enabled() is not defined, regulator core will assume this regulator is already enabled, then it can NOT be really enabled after disabled. Based on Li Jun's patch from the NXP kernel tree. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: of: Add a missing 'of_node_put()' in an error handling path of ↵Christophe JAILLET2018-05-301-0/+1
| | | | | | | | | | | | | | 'of_regulator_match()' [ Upstream commit 30966861a7a2051457be8c49466887d78cc47e97 ] If an unlikely failure in 'of_get_regulator_init_data()' occurs, we must release the reference on the current 'child' node before returning. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: anatop: set default voltage selector for pcieDong Aisheng2018-03-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9bf944548169f6153c3d3778cf983cb5db251a0e ] Set the initial voltage selector for vddpcie in case it's disabled by default. This fixes the below warning: 20c8000.anatop:regulator-vddpcie: Failed to read a valid default voltage selector. anatop_regulator: probe of 20c8000.anatop:regulator-vddpcie failed with error -22 Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Robin Gong <yibin.gong@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: fan53555: fix I2C device idsGuillaume Tucker2017-11-021-1/+4
| | | | | | | | | | | | | | | | | | | commit fc1111b885437f374ed54aadda44d8b241ebd2a3 upstream. The device tree nodes all correctly describe the regulators as syr827 or syr828, but the I2C device id is currently set to the wildcard value of syr82x in the driver. This causes udev to fail to match the driver module with the modalias data from sysfs. Fix this by replacing the I2C device ids with ones that match the device tree descriptions, with syr827 and syr828. Tested on Firefly rk3288 board. The syr82x id was not used anywhere. Fixes: e80c47bd738b (regulator: fan53555: Export I2C module alias information) Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: tps65023: Fix inverted core enable logic.Richard Cochran2017-05-251-2/+1
| | | | | | | | | | | | | | | | | | | | | | | commit c90722b54a4f5e21ac59301ed9a6dbaa439bdb16 upstream. Commit 43530b69d758328d3ffe6ab98fd640463e8e3667 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly") intended to replace working inline helper functions with standard regmap calls. However, it also inverted the set/clear logic of the "CORE ADJ Allowed" bit. That patch was clearly never tested, since without that bit cleared, the core VDCDC1 voltage output does not react to I2C configuration changes. This patch fixes the issue by clearing the bit as in the original, correct implementation. Note for stable back porting that, due to subsequent driver churn, this patch will not apply on every kernel version. Fixes: 43530b69d758 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly") Signed-off-by: Richard Cochran <rcochran@linutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: Clear the supply pointer if enabling failsJon Hunter2017-05-021-0/+1
| | | | | | | | | | | | | | | | | | | commit 8e5356a73604f53da6a1e0756727cb8f9f7bba17 upstream. During the resolution of a regulator's supply, we may attempt to enable the supply if the regulator itself is already enabled. If enabling the supply fails, then we will call _regulator_put() for the supply. However, the pointer to the supply has not been cleared for the regulator and this will cause a crash if we then unregister the regulator and attempt to call regulator_put() a second time for the supply. Fix this by clearing the supply pointer if enabling the supply after fails when resolving the supply for a regulator. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: Fix regulator_summary for deviceless consumersLeonard Crestez2017-03-121-2/+3
| | | | | | | | | | | | | | | commit e42a46b6f52473661ad192f76a128a68fe301df4 upstream. It is allowed to call regulator_get with a NULL dev argument (_regulator_get explicitly checks for it) but this causes an error later when printing /sys/kernel/debug/regulator_summary. Fix this by explicitly handling "deviceless" consumers in the debugfs code. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: stw481x-vmmc: fix ages old enable errorLinus Walleij2017-01-091-1/+2
| | | | | | | | | | | | | | | commit 295070e9aa015abb9b92cccfbb1e43954e938133 upstream. The regulator has never been properly enabled, it has been dormant all the time. It's strange that MMC was working at all, but it likely worked by the signals going through the levelshifter and reaching the card anyways. Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: tps65910: Work around silicon erratum SWCZ010Jan Remmet2016-10-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8f9165c981fed187bb483de84caf9adf835aefda upstream. 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: Jan Remmet <j.remmet@phytec.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: qcom_smd: Fix voltage ranges for pm8x41Stephen Boyd2016-10-071-8/+9
| | | | | | | | | | | | | | | | | | | | | commit 290284776bb281759b11faa287b8abccaf74bfcb upstream. 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: da65e367b67e ("regulator: Regulator driver for the Qualcomm RPM") Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: qcom_spmi: Update mvs1/mvs2 switches on pm8941Stephen Boyd2016-10-071-2/+2
| | | | | | | | | | | | | | | | | | | | commit 93bfe79b03365f410aa91caf04263173c008ecdf upstream. The mvs1 and mvs2 switches are actually called 5vs1 and 5vs2 on some datasheets. Let's rename them to match the datasheets and also match the RPM based regulator driver which calls these by their 5vs names (see qcom_smd-regulator.c). There aren't any users of these regulators so far, so there aren't any concerns of DT ABI breakage here. While we're here making updates to the switches, also mandate usage of the OCP irq for these switches too. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047419c ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: qcom_spmi: Add support for get_mode/set_mode on switchesStephen Boyd2016-10-071-0/+2
| | | | | | | | | | | | | | commit 919163f6362ac23138d31fc8befdd52e5d7e488d upstream. The voltage switches support mode switching, so add support for these ops to those types of regulators. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047419c ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: qcom_spmi: Add support for S4 supply on pm8941Stephen Boyd2016-10-071-0/+1
| | | | | | | | | | | | | | | | | commit c333dfe8dba7d3e47e97e1cee3c38123e19ae73c upstream. The S4 supply is sometimes called the boost regulator because it outputs 5V. Typically it's connected to the 5vs1 and 5vs2 switches for use in USB OTG and HDMI applications. Add support for this regulator which was mistakenly left out from the initial submission of this driver. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047419c ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: anatop: allow regulator to be in bypass modeMika Båtsman2016-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | commit 8a092e682f20f193f2070dba2ea1904e95814126 upstream. Bypass support was added in commit d38018f2019c ("regulator: anatop: Add bypass support to digital LDOs"). A check for valid voltage selectors was added in commit da0607c8df5c ("regulator: anatop: Fail on invalid voltage selector") but it also discards all regulators that are in bypass mode. Add check for the bypass setting. Errors below were seen on a Variscite mx6 board. anatop_regulator 20c8000.anatop:regulator-vddcore@140: Failed to read a valid default voltage selector. anatop_regulator: probe of 20c8000.anatop:regulator-vddcore@140 failed with error -22 anatop_regulator 20c8000.anatop:regulator-vddsoc@140: Failed to read a valid default voltage selector. anatop_regulator: probe of 20c8000.anatop:regulator-vddsoc@140 failed with error -22 Fixes: da0607c8df5c ("regulator: anatop: Fail on invalid voltage selector") Signed-off-by: Mika Båtsman <mbatsman@mvista.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: axp20x: Fix axp22x ldo_io voltage rangesHans de Goede2016-05-181-2/+2
| | | | | | | | | | | | | | | commit a2262e5a12e05389ab4c7fc5cf60016b041dd8dc upstream. The minium voltage of 1800mV is a copy and paste error from the axp20x regulator info. The correct minimum voltage for the ldo_io regulators on the axp22x is 700mV. Fixes: 1b82b4e4f954 ("regulator: axp20x: Add support for AXP22X regulators") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: s2mps11: Fix invalid selector mask and voltages for buck9Krzysztof Kozlowski2016-05-181-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3b672623079bb3e5685b8549e514f2dfaa564406 upstream. The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff instead of 0x1f) thus reading entire register as buck9's voltage. This effectively caused regulator core to interpret values as higher voltages than they were and then to set real voltage much lower than intended. The buck9 provides power to other regulators, including LDO13 and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower voltage caused SD card detection errors on Odroid XU3/XU4: mmc1: card never left busy state mmc1: error -110 whilst initialising SD card During driver probe the regulator core was checking whether initial voltage matches the constraints. With incorrect vsel_mask of 0xff and default value of 0x50, the core interpreted this as 5 V which is outside of constraints (3-3.775 V). Then the regulator core was adjusting the voltage to match the constraints. With incorrect vsel_mask this new voltage mapped to a vere low voltage in the driver. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: s5m8767: fix get_register() error handlingArnd Bergmann2016-05-041-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e07ff9434167981c993a26d2edbbcb8e13801dbb upstream. The s5m8767_pmic_probe() function calls s5m8767_get_register() to read data without checking the return code, which produces a compile-time warning when that data is accessed: drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe': drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized] This changes the s5m8767_get_register() function to return a -EINVAL not just for an invalid register number but also for an invalid regulator number, as both would result in returning uninitialized data. The s5m8767_pmic_probe() function is then changed accordingly to fail on a read error, as all the other callers of s5m8767_get_register() already do. In practice this probably cannot happen, as we don't call s5m8767_get_register() with invalid arguments, but the gcc warning seems valid in principle, in terms writing safe error checking. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 9c4c60554acf ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap") Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: Fix nested locking of suppliesThierry Reding2016-05-041-2/+9
| | | | | | | | | | | | | | | | | | | | | | | commit 70a7fb80e85ae7f78f8e90cec3fbd862ea6a4d4b upstream. Commit fa731ac7ea04 ("regulator: core: avoid unused variable warning") introduced a subtle change in how supplies are locked. Where previously code was always locking the regulator of the current iteration, the new implementation only locks the regulator if it has a supply. For any given power tree that means that the root will never get locked. On the other hand the regulator_unlock_supply() will still release all the locks, which in turn causes the lock debugging code to warn about a mutex being unlocked which wasn't locked. Cc: Mark Brown <broonie@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Fixes: fa731ac7ea04 ("regulator: core: avoid unused variable warning") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: Ensure we lock all regulatorsMark Brown2016-05-041-1/+1
| | | | | | | | | | | | | | | commit 49a6bb7a1c0963f260e4b0dcc2c0e56ec65a28b2 upstream. The latest workaround for the lockdep interface's not using the second argument of mutex_lock_nested() changed the loop missed locking the last regulator due to a thinko with the loop termination condition exiting one regulator too soon. Reported-by: Tyler Baker <tyler.baker@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: fix regulator_lock_supply regressionArnd Bergmann2016-05-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | commit bb41897e38c53458a88b271f2fbcd905ee1f9584 upstream. As noticed by Geert Uytterhoeven, my patch to avoid a harmless build warning in regulator_lock_supply() was total crap and introduced a real bug: > [ BUG: bad unlock balance detected! ] > kworker/u4:0/6 is trying to release lock (&rdev->mutex) at: > [<c0247b84>] regulator_set_voltage+0x38/0x50 we still lock the regulator supplies, but not the actual regulators, so we are missing a lock, and the unlock is unbalanced. This rectifies it by first locking the regulator device itself before using the same loop as before to lock its supplies. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 716fec9d1965 ("[SUBMITTED] regulator: core: avoid unused variable warning") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Revert "regulator: core: Fix nested locking of supplies"Greg Kroah-Hartman2016-05-041-9/+1
| | | | | | | | | | | | | | | | | This reverts commit b1999fa6e8145305a6c8bda30ea20783717708e6 which was commit 70a7fb80e85ae7f78f8e90cec3fbd862ea6a4d4b upstream. It causes run-time breakage in the 4.4-stable tree and more patches are needed to be applied first before this one in order to resolve the issue. Reported-by: Guenter Roeck <linux@roeck-us.net> Cc: Mark Brown <broonie@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Thierry Reding <treding@nvidia.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: Fix nested locking of suppliesThierry Reding2016-04-121-1/+9
| | | | | | | | | | | | | | | | | | | | | | commit 70a7fb80e85ae7f78f8e90cec3fbd862ea6a4d4b upstream. Commit fa731ac7ea04 ("regulator: core: avoid unused variable warning") introduced a subtle change in how supplies are locked. Where previously code was always locking the regulator of the current iteration, the new implementation only locks the regulator if it has a supply. For any given power tree that means that the root will never get locked. On the other hand the regulator_unlock_supply() will still release all the locks, which in turn causes the lock debugging code to warn about a mutex being unlocked which wasn't locked. Cc: Mark Brown <broonie@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Fixes: Fixes: fa731ac7ea04 ("regulator: core: avoid unused variable warning") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: avoid unused variable warningArnd Bergmann2016-04-121-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit fa731ac7ea04a7d3a5c6d2f568132478c02a83b3 upstream. The second argument of the mutex_lock_nested() helper is only evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we get this build warning for the new regulator_lock_supply function: drivers/regulator/core.c: In function 'regulator_lock_supply': drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable] To avoid the warning, this restructures the code to make it both simpler and to move the 'i++' outside of the mutex_lock_nested call, where it is now always used and the variable is not flagged as unused. We had some discussion about changing mutex_lock_nested to an inline function, which would make the code do the right thing here, but in the end decided against it, in order to guarantee that mutex_lock_nested() does not introduced overhead without CONFIG_DEBUG_LOCK_ALLOC. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 9f01cd4a915 ("regulator: core: introduce function to lock regulators and its supplies") Link: http://permalink.gmane.org/gmane.linux.kernel/2068900 Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: mt6311: MT6311_REGULATOR needs to select REGMAP_I2CHenry Chen2016-03-031-0/+1
| | | | | | | | | | | | commit aab3c3f34cc2dd8230052770712606d65de6538f upstream. This patch fix the below build error: drivers/regulator/mt6311-regulator.c:111: undefined reference to `__devm_regmap_init_i2c' Signed-off-by: Henry Chen <henryc.chen@mediatek.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: axp20x: Fix GPIO LDO enable value for AXP22xChen-Yu Tsai2016-03-031-2/+2
| | | | | | | | | | | | | | | commit 3cb99e2ea99a454c8837a55aac88753ef05fc1eb upstream. The enable/disable values for GPIO LDOs are reversed. It seems no one noticed as AXP22x support was introduced recently, and no one was using the GPIO LDOs, either because no designs actually use them or board support hasn't caught up. Fixes: 1b82b4e4f954 ("regulator: axp20x: Add support for AXP22X regulators") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'spi-v4.4' of ↵Linus Torvalds2015-11-051-1/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi updates from Mark Brown: "Quite a lot of activity in SPI this cycle, almost all of it in drivers with a few minor improvements and tweaks in the core. - Updates to pxa2xx to support Intel Broxton and multiple chip selects. - Support for big endian in the bcm63xx driver. - Multiple slave support for the mt8173 - New driver for the auxiliary SPI controller in bcm2835 SoCs. - Support for Layerscale SoCs in the Freescale DSPI driver" * tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (87 commits) spi: pxa2xx: Rework self-initiated platform data creation for non-ACPI spi: pxa2xx: Add support for Intel Broxton spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals spi: pxa2xx: Add output control for multiple Intel LPSS chip selects spi: pxa2xx: Use LPSS prefix for defines that are Intel LPSS specific spi: Add DSPI support for layerscape family spi: ti-qspi: improve ->remove() callback spi/spi-xilinx: Fix race condition on last word read spi: Drop owner assignment from spi_drivers spi: Add THIS_MODULE to spi_driver in SPI core spi: Setup the master controller driver before setting the chipselect spi: dw: replace magic constant by DW_SPI_DR spi: mediatek: mt8173 spi multiple devices support spi: mediatek: handle controller_data in mtk_spi_setup spi: mediatek: remove mtk_spi_config spi: mediatek: Update document devicetree bindings to support multiple devices spi: fix kernel-doc warnings about missing return desc in spi.c spi: fix kernel-doc warnings about missing return desc in spi.h spi: pxa2xx: Align a few defines spi: pxa2xx: Save other reg_cs_ctrl bits when configuring chip select ...
| *-. Merge remote-tracking branches 'spi/topic/omap-100k', ↵Mark Brown2015-11-041-1/+0
| |\ \ | | | | | | | | | | | | 'spi/topic/omap-uwire', 'spi/topic/owner', 'spi/topic/pxa' and 'spi/topic/pxa2xx' into spi-next
| | | * spi: Drop owner assignment from spi_driversAndrew F. Davis2015-10-281-1/+0
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | An spi_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| | |
| \ \
| \ \
| \ \
*---. \ \ Merge remote-tracking branches 'regulator/topic/supply', ↵Mark Brown2015-11-043-252/+295
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | 'regulator/topic/tps6105x' and 'regulator/topic/tps65023' into regulator-next
| | | * | | regulator: tps65023: add device tree supportThomas Elste2015-09-211-174/+108
| | | | |/ | | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add device tree based initialization support for tps65023 regulators. Therefore add macros for regulator definition setting of_match and regulators_node members. Add initialization of regulator_desc data using these macros. Remove old regulator_desc initialization. Add device tree binding document for tps65023 regulators. Signed-off-by: Thomas Elste <thomas.elste@imms.de> Signed-off-by: Mark Brown <broonie@kernel.org>
| | * / | mfd: tps6105x: Use i2c regmap to access registersGrigoryev Denis2015-10-051-8/+8
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch modifies tps6105x and associated function driver to use regmap instead of operating directly on i2c. Signed-off-by: Denis Grigoryev <grigoryev@fastwel.ru> Signed-off-by: Lee Jones <lee.jones@linaro.org>
| * | | regulator: Use regulator_lock_supply() for get_voltage() tooMark Brown2015-11-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we need to read voltages of parents as part of setting supply voltages we need to be able to do get_voltage() internally without taking locks so reorganize the locking to take locks on the full tree on entry rather than as we recurse when called externally. Reported-by: John Stultz <john.stultz@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: core: Propagate voltage changes to supply regulatorsSascha Hauer2015-10-221-2/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now changing the voltage of a regulator only ever effected the regulator itself, but never its supplies. It's a common pattern though to put LDO regulators behind switching regulators. The switching regulators efficiently drop the input voltage but have a high ripple on their output. The output is then cleaned up by the LDOs. For higher energy efficiency the voltage drop at the LDOs should be minimized. For this scenario we need to propagate the voltage change to the supply regulators. Another scenario where voltage propagation is desired is a regulator which only consists of a switch and thus cannot regulate voltages itself. In this case we can pass setting voltages to the supply. This patch adds support for voltage propagation. We do voltage propagation when the current regulator has a minimum dropout voltage specified or if the current regulator lacks a get_voltage operation (indicating it's a switch and not a regulator). Changing the supply voltage must be done carefully. When we are increasing the current regulators output we must first increase the supply voltage and then the regulator itself. When we are decreasing the current regulators voltage we must decrease the supply voltage after changing the current regulators voltage. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: core: Factor out regulator_map_voltageSascha Hauer2015-10-201-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _regulator_call_set_voltage has code to translate a minimum/maximum voltage pair into a selector. This code is useful for others aswell, so create a regulator_map_voltage function. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: core: create unlocked version of regulator_set_voltageSascha Hauer2015-10-161-23/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The unlocked version will be needed when we start propagating voltage changes to the supply regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: core: create unlocked version of regulator_list_voltageSascha Hauer2015-10-011-27/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The unlocked version will be needed when we start propagating voltage changes to the supply regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | regulator: core: introduce function to lock regulators and its suppliesSascha Hauer2015-10-011-0/+39
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each regulator_dev is locked with its own mutex. This is fine as long as only one regulator_dev is locked, but makes lockdep unhappy when we have to walk up the supply chain like it can happen in regulator_get_voltage: regulator_get_voltage -> mutex_lock(&regulator->rdev->mutex) -> _regulator_get_voltage(regulator->rdev) -> regulator_get_voltage(rdev->supply) -> mutex_lock(&regulator->rdev->mutex); This causes lockdep to issue a possible deadlock warning. There are at least two ways to work around this: - We can always lock the whole supply chain using the functions introduced with this patch. - We could store the current voltage in struct regulator_rdev so that we do not have to walk up the supply chain for the _regulator_get_voltage case. Anyway, regulator_lock_supply/regulator_unlock_supply will be needed once we allow regulator_set_voltage to optimize the supply voltages. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
| | |
| \ \
| \ \
| \ \
| \ \
| \ \
| \ \
| \ \
*-------. \ \ Merge remote-tracking branches 'regulator/topic/load', ↵Mark Brown2015-11-044-21/+47
|\ \ \ \ \ \ \ | | | |_|_|/ / | | |/| | | | | | | | | | | 'regulator/topic/max77802', 'regulator/topic/pwm', 'regulator/topic/qcom-smd' and 'regulator/topic/stw481x' into regulator-next
| | | | | * | regulator: stw481x: compile on COMPILE_TESTLuis de Bethencourt2015-10-231-1/+1
| | | |_|/ / | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver depends on MFD_STW481X but there isn't a build dependency so it's a good idea to allow the driver to always be built when the COMPILE_TEST option is enabled. That way, the driver can be built with a config generated by make allyesconfig and check if a patch would break the build. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | | * | regulator: qcom-smd: Correct set_load() unitBjorn Andersson2015-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The set_load() op deals with uA while the SMD packets used mA, so convert as we're building the packet. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | | * | regulator: qcom_smd: Handle big endian CPUsStephen Boyd2015-09-031-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The smd rpm structures are always in little endian, but this driver is not capable of being used on big endian CPUs. Annotate the little endian data members and update the code to do the proper byte swapping. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * | | regulator: pwm: implement ->enable(), ->disable() and ->is_enabled methodsBoris Brezillon2015-09-211-6/+29
| | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement the ->enable(), ->disable() and ->is_enabled methods and remove the PWM call in ->set_voltage_sel(). This is particularly important for critical regulators tagged as always-on, because not claiming the PWM (and its dependencies) might lead to unpredictable behavior (like a system hang because the PWM clk is only claimed when the PWM device is enabled). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * / / / regulator: Introduce property to flag set-load supportBjorn Andersson2015-09-171-0/+3
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce "regulator-allow-set-load" property to make it possible to flag in the board configuration that a regulator is allowed to have the load requirements changed. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | |
| \ \ \
*-. \ \ \ Merge remote-tracking branches 'regulator/topic/da9053' and ↵Mark Brown2015-11-042-1/+2
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | 'regulator/topic/da9063' into regulator-next
| | * | | | regulator: da9063: Remove unneeded semicolonJavier Martinez Canillas2015-09-141-1/+1
| | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's clearly a typo error that just creates a null statement so remove it. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * / / / regulator: da9053: Update regulator for DA9053 BC silicon supportSteve Twiss2015-10-161-0/+1
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide an additional case entry for DA9053_BC in the find_regulator_info() function in order to support BC type silicon for the DA9053 device. Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| | | |
| \ \ \
| \ \ \
| \ \ \
| \ \ \
| \ \ \
| \ \ \
| \ \ \
*-------. \ \ \ Merge remote-tracking branches 'regulator/topic/act8865', ↵Mark Brown2015-11-045-12/+91
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 'regulator/topic/anatop', 'regulator/topic/arizona', 'regulator/topic/axp20x' and 'regulator/topic/bcm590xx' into regulator-next
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-13 10:16:01 +0000