summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2016-05-13Merge remote-tracking branches 'regulator/topic/tps6524x' and ↵Mark Brown
'regulator/topic/twl' into regulator-next
2016-05-13Merge remote-tracking branches 'regulator/topic/pwm', ↵Mark Brown
'regulator/topic/qcom-spmi', 'regulator/topic/rk808' and 'regulator/topic/s2mps11' into regulator-next
2016-05-13Merge remote-tracking branches 'regulator/topic/max77686', ↵Mark Brown
'regulator/topic/max8973', 'regulator/topic/maxim', 'regulator/topic/palmas' and 'regulator/topic/pv88080' into regulator-next
2016-05-13Merge remote-tracking branches 'regulator/topic/fan53555', ↵Mark Brown
'regulator/topic/lp3971', 'regulator/topic/lp3972', 'regulator/topic/lp873x' and 'regulator/topic/max77620' into regulator-next
2016-05-13Merge remote-tracking branches 'regulator/topic/can-change', ↵Mark Brown
'regulator/topic/constrain', 'regulator/topic/debugfs' and 'regulator/topic/doc' into regulator-next
2016-05-13Merge remote-tracking branches 'regulator/topic/abb', ↵Mark Brown
'regulator/topic/act8865', 'regulator/topic/as3722' and 'regulator/topic/axp20x' into regulator-next
2016-05-13Merge remote-tracking branch 'regulator/topic/supply' into regulator-nextMark Brown
2016-05-13Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2016-05-13Merge remote-tracking branch 'regulator/topic/bypass' into regulator-nextMark Brown
2016-05-13Merge remote-tracking branches 'regulator/fix/constrain' and ↵Mark Brown
'regulator/fix/defer' into regulator-linus
2016-05-13Merge remote-tracking branch 'regulator/fix/core' into regulator-linusMark Brown
2016-05-13Merge remote-tracking branch 'regulator/fix/bypass' into regulator-linusMark Brown
2016-05-13regulator: rk808: Migrate to regulator core's simplified DT parsing codeWadim Egorov
A common simplified DT parsing code for regulators was introduced in commit a0c7b164ad11 ("regulator: of: Provide simplified DT parsing method") While at it also added RK8XX_DESC and RK8XX_DESC_SWITCH macros for the regulator_desc struct initialization. This just makes the driver more compact. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-13Merge remote-tracking branches 'regulator/fix/axp20x', ↵Mark Brown
'regulator/fix/da9063', 'regulator/fix/gpio' and 'regulator/fix/s2mps11' into regulator-linus
2016-05-11regulator: lp873x: Add support for lp873x PMIC regulatorsKeerthy
The regulators set consists of 2 BUCKs and 2 LDOs. The output voltages are configurable and are meant to supply power to the main processor and other components. The ramp delay is configurable for both BUCKs. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-10regulator: da9063: Correct module alias prefix to fix module autoloadingGeert Uytterhoeven
s/paltform/platform/ Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-06regulator: tps65917/palmas: Simplify multiple dereference of match->of_nodeNishanth Menon
Just dereference match->of_node once instead of using match->of_node. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-06regulator: tps65917/palmas: Handle possible memory allocation failureNishanth Menon
Stop the palmas regulator driver from imagining that the allocations will always succeed. Since regulator dt nodes are optional in nature and can be described in downstream drivers via platform data, continue to maintain code flow as prior when of node is not found. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-06regulator: tps65917/palmas: Simplify multiple dereference of ↵Nishanth Menon
pdata->reg_init[idx] Converting dt to platform data logic involves picking up information that is unique per regulator, however we can improve readability of the code by allocating and referencing pdata->reg_init[idx] once in the loop. While at it, use sizeof(*pointer) when allocating pointer. This allows for structure name changes with minimal code change. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-06regulator: tps65917/palmas: Simplify multiple dereference of ↵Nishanth Menon
ddata->palmas_matches[idx] Converting dt to platform data logic involves picking up information that is unique per regulator, however we can improve readability of the code by dereferencing ddata->palmas_matches[idx] once in the loop. While at it fix reuse of generic palmas_matches common variable while reporting error for a specific regulator (which may be from 65917/palmas list). Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-03Merge branch 'for-4.7/pwm-regulator' of ↵Mark Brown
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm into regulator-pwm
2016-05-03regulator: pwm: Use pwm_get_args() where appropriateBoris Brezillon
The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework allowing the PWM framework to support hardware readout and expose real PWM state even when the PWM has just been requested (before the user calls pwm_config/enable/disable()). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-04-29regulator: max77686: Configure enable time to properly handle regulator enableKrzysztof Kozlowski
The enable time for buck regulators was not configured but actually is essential: consumers, like usb3503, doing hard reset (regulator off/on) should wait for the regulator to settle. Configure the enable time according to datasheet. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-29regulator: axp20x: Fix axp22x ldo_io registration error on cold bootHans de Goede
The maximum supported voltage for ldo_io# is 3.3V, but on cold boot the selector comes up at 0x1f, which maps to 3.8V. This causes _regulator_get_voltage() to fail with -EINVAL which causes regulator registration to fail when constrains are used: [ 1.467788] vcc-touchscreen: failed to get the current voltage(-22) [ 1.474209] axp20x-regulator axp20x-regulator: Failed to register ldo_io1 [ 1.483363] axp20x-regulator: probe of axp20x-regulator failed with error -22 This commits makes the axp20x regulator driver accept the 0x1f register value, fixing this. The datasheet does not guarantee reliable operation above 3.3V, so on boards where this regulator is used the regulator-max-microvolt setting must be 3.3V or less. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-27regulator: rk808: Add rk808_reg_ops_ranges for LDO3Wadim Egorov
LDO_REG3 descriptor is using linear_ranges. Add and use proper ops for LDO_REG3. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-27regulator: core: Add early supply resolution for regulatorsJon Hunter
The call to set_machine_constraints() in regulator_register(), will attempt to get the voltage for the regulator. If a regulator is in bypass will fail to get the voltage (ie. it's bypass voltage) and hence register the regulator, because the supply for the regulator has not been resolved yet. To fix this, add a call to regulator_resolve_supply() before we call set_machine_constraints(). If the call to regulator_resolve_supply() fails, rather than returning an error at this point, allow the registration of the regulator to continue because for some regulators resolving the supply at this point may not be necessary and it will be resolved later as more regulators are added. Furthermore, if the supply is still not resolved for a bypassed regulator, this will be detected when we attempt to get the voltage for the regulator and an error will be propagated at this point. If a bypassed regulator does not have a supply when we attempt to get the voltage, rather than returing -EINVAL, return -EPROBE_DEFER instead to allow the registration of the regulator to be deferred and tried again later. Please note that regulator_resolve_supply() will call regulator_dev_lookup() which may acquire the regulator_list_mutex. To avoid any deadlocks we cannot hold the regulator_list_mutex when calling regulator_resolve_supply(). Therefore, rather than holding the lock around a large portion of the registration code, just hold the lock when aquiring any GPIOs and setting up supplies because these sections may add entries to the regulator_map_list and regulator_ena_gpio_list, respectively. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-27Merge branch 'topic/bypass' of ↵Mark Brown
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-supply
2016-04-27regulator: axp20x: Fix axp22x ldo_io voltage rangesHans de Goede
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>
2016-04-26regulator: tps65917/palmas: Add bypass "On" valueNishanth Menon
When commit b554e1450658 ("regulator: tps65917/palmas: Add bypass ops for LDOs with bypass capability") introduced bypass capability to palmas regulator, it went with the assumption that regulator regmap helpers just check val against the bypass_mask. Unfortunately, this ignored the explicit "on" and "off" values when the register value is masked with bypass_mask in commit ca5d1b3524b4 ("regulator: helpers: Modify helpers enabling multi-bit control"). With the recent commit dd1a571daee7 ("regulator: helpers: Ensure bypass register field matches ON value"), this issue gets highlighted and fails tps65917/palmas based platforms which need regulators/ldos that have bypass capability. Introduce the bypass_on value appropriately for tps65917/palmas regulator. Fixes: b554e1450658 ("regulator: tps65917/palmas: Add bypass ops for LDOs with bypass capability") Cc: Keerthy <j-keerthy@ti.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-26regulator: axp20x: Fix LDO4 linear voltage rangeMaxime Ripard
The current linear voltage range for the LDO4 regulator found in the APX20X PMICs assumes that the voltage is linear between 2.5 and 3.1V. However, the PMIC can output up to 3.3V on that regulator by skipping the 2.6V and 2.9V steps. Fix the ranges to read and set the proper voltages. Fixes: 13d57e64352a ("regulator: axp20x: Use linear voltage ranges for AXP20X LDO4") Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-26regulator: rk808: remove unused rk808_reg_ops_rangesArnd Bergmann
After removing all uses of the range operations in a recent patch, we get a warning about the symbol not being referenced anywhere: drivers/regulator/rk808-regulator.c:306:29: 'rk808_reg_ops_ranges' defined but not used This removes the now-unused structure along with the rk808_set_suspend_voltage_range function that is only referenced from rk808_reg_ops_ranges. Fixes: afcd666d9db0 ("regulator: rk808: remove linear range definitions with a single range") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-25regulator: refactor valid_ops_mask checking codeWEN Pingbo
To make the code more compat and centralized, this patch add a unified function - regulator_ops_is_valid. So we can add some extra checking code easily later. Signed-off-by: WEN Pingbo <pingbo.wen@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-25regulator: rk808: remove linear range definitions with a single rangeWadim Egorov
The driver was using only linear ranges. Now we remove linear range definitions with a single range. So we have to add an ops struct for ranges and adjust all other ops functions accordingly. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-22regulator: max77620: Add support for device specific ramp rate settingLaxman Dewangan
Maxim advertised the ramp rate of the rail with some recommended design specification like output capacitance of rail should be 2.2uF. This make sure that current change in the rail is within maximum current limit and hence meet the advertised ramp rate. If there is variation in design which causes the rail current to change more that maximum current limit then device applies the current limit. In this case, ramp rate is different than advertised ramp rate. Add device specific settings for ramp rate which need to be configure on device register when measure ramp rate on platform is deviated from advertised ramp rate. In this case, all delay time calculation for voltage change is done with measured ramp rate and device ramp rate is used for configuring the device register. If measured ramp rate in the platform is same as advertised ramp rate then regulator-ramp-delay is used for the device register configuration and ramp time calculation for voltage change. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-22regulator: helpers: Ensure bypass register field matches ON valueJon Hunter
When checking bypass state for a regulator, we check to see if any bits in the bypass mask are set. For most cases this is fine because there is typically, only a single bit used to determine if the regulator is in bypass. However, for some regulators, such as LDO6 on AS3722, the bypass state is indicate by a value rather than a single bit. Therefore, when checking the bypass state, check that the bypass field matches the ON value. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-22regulator: core: Move registration of regulator deviceJon Hunter
The public functions to acquire a regulator, such as regulator_get(), internally look-up the regulator from the list of regulators that have been registered with the regulator device class. The registration of a new regulator with the regulator device class happens before the regulator has been completely setup. Therefore, it is possible that the regulator could be acquired before it has been setup successfully. To avoid this move the device registration of the regulator to the end of the regulator setup and update the error exit path accordingly. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-22Merge branch 'topic/sysfs-init' of ↵Mark Brown
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-supply
2016-04-22regulator: core: Clear the supply pointer if enabling failsJon Hunter
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>
2016-04-22regulator: core: Don't terminate supply resolution earlyJon Hunter
The function regulator_register_resolve_supply() is called from the context of class_for_each_dev() (during the regulator registration) to resolve any supplies added. regulator_register_resolve_supply() will return an error if a regulator's supply cannot be resolved and this will terminate the loop in class_for_each_dev(). This means that we will not attempt to resolve any other supplies after one has failed. Hence, this may delay the resolution of other regulator supplies until the failing one itself can be resolved. Rather than terminating the loop early, don't return an error code and keep attempting to resolve any other supplies for regulators that have been registered. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-22regulator: core: Add debugfs to show constraint flagsRichard Fitzgerald
There are debugfs entries for voltage and current, but not for the constraint flags. It's useful for debugging to be able to see what these flags are so this patch adds a new debugfs file. We can't use debugfs_create_bool for this because the flags are bitfields, so as this needs a special read callback they have been collected into a single file that lists all the flags. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-20regulator: tps6524x: Fix broken use of spi_dev_get()Mark Brown
The tps6524x driver uses spi_dev_get() to take a copy of the SPI device it uses but has no obvious reason to do so and never calls spi_dev_put() to release the reference. Fix this to just a straight copy. Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-20regulator: fan53555: Add support for FAN53555UC13X typeWadim Egorov
IC type options 00, 13 and 23 are sharing the same DIE_ID 0. Let's differentiate between these revisions. FAN53555UC13X has the ID 0 and REV 0xf, starts at 800mV and increments in 10mV steps. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-20regulator: fan53555: Add support for FAN53555BUC18X typeWadim Egorov
FAN53555BUC18X has the DIE_ID 8, starts at 600mV and increments in 10mV steps. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-18regulator: core: remove lockdep assert from suspend_prepareTero Kristo
suspend_prepare can be called during regulator init time also, where the mutex is not locked yet. This causes a false lockdep warning. To avoid the problem, remove the lockdep assertion from the function causing the issue. An alternative would be to lock the mutex during init, but this would cause other problems (some APIs used during init will attempt to lock the mutex also, causing deadlock.) Signed-off-by: Tero Kristo <t-kristo@ti.com> Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-18regulator: pv88080: new regulator driverJames Ban
This is the driver for the Powerventure PV88080 BUCKs regulator. It communicates via an I2C bus to the device. Signed-off-by: James Ban <James.Ban..opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-18regulator: s2mps11: Set default ramp delay for S2MPS11 LDOsKrzysztof Kozlowski
Driver did not provide default value for ramp delay for LDOs which lead to warning in dmesg, e.g. on Odroid XU4: [ 1.486076] vdd_ldo9: ramp_delay not set [ 1.506875] vddq_mmc2: ramp_delay not set [ 1.523766] vdd_ldo15: ramp_delay not set [ 1.544702] vdd_sd: ramp_delay not set The datasheet for all the S2MPS1x family is inconsistent here and does not specify unambiguously the value of ramp delay for LDO. It mentions 30 mV/us in one timing diagram but then omits it completely in LDO regulator characteristics table (it is specified for bucks). However the vendor kernels for Galaxy S5 and Odroid XU3 use values of 12 mV/us or 24 mV/us. Without the ramp delay value the consumers do not wait for voltage settle after changing it. Although the proper value of ramp delay for LDOs is unknown, it seems safer to use at least some value from reference kernel than to leave it unset. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-18regulator: qcom_spmi: Always return a selector when askedStephen Boyd
I had a thinko in spmi_regulator_select_voltage_same_range() when converting it to return selectors via the function's return value instead of by modifying a pointer argument. I only tested multi-range regulators so this passed through testing. Fix it by returning the selector here. Fixes: 1b5b19689278 ("regulator: qcom_spmi: Only use selector based regulator ops") Reported-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-14regulator: lp3972: Silence uninitialized variable warningDan Carpenter
This is harmless but my static checker complains that "tmp" is uninitialized if lp3972_i2c_read() fails. I have moved the line of code below the error handling to silence the warning. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-14regulator: lp3971: Silence uninitialized variable warningDan Carpenter
This is harmless but if lp3971_i2c_read() fails then "tmp" can be uninitialized. Silence the warning by moving the error handling up a line. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-13regulator: max8973: add support for junction thermal warningLaxman Dewangan
The driver MAX8973 supports the driver for Maxim PMIC MAX77621. MAX77621 supports the junction temp warning at 120 degC and 140 degC which is configurable. It generates alert signal when junction temperature crosses these threshold. MAX77621 does not support the continuous temp monitoring of junction temperature. It just report whether junction temperature crossed the threshold or not. Add support to - Configure junction temp warning threshold via DT property to generate alert when it crosses the threshold. - Add support to interrupt the host from this device when alert occurred. - read the junction temp via thermal framework. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>