- Dec 20, 2018
-
-
Axel Lin authored
The n_voltages setting is not set, fix it. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Axel Lin authored
mcp16502_suspend/resume_noirq is only used by SET_NOIRQ_SYSTEM_SLEEP_PM_OPS when CONFIG_PM_SLEEP is defined. So use #ifdef CONFIG_PM_SLEEP instead CONFIG_SUSPEND guard. Signed-off-by:
-
Andrei.Stefanescu@microchip.com authored
This patch does the following: - align parameter with parenthesis - fix compile error If CONFIG_SUSPEND is not set the dummy pm_ops callbacks are named mcp16502_suspend and mcp16502_resume instead of mcp16502_suspend_noirq and mcp16502_resume_noirq. Excerpt from compile log (kbuild test robot): In file included from include/linux/device.h:23:0, from include/linux/gpio/driver.h:5, from include/asm-generic/gpio.h:13, from include/linux/gpio.h:62, from drivers/regulator/mcp16502.c:11: >> drivers/regulator/mcp16502.c:527:32: error: 'mcp16502_suspend_noirq' undeclared here (not in a function); did you mean 'mcp16502_suspend'? SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mcp16502_suspend_noirq, >> drivers/regulator/mcp16502.c:528:10: error: 'mcp16502_resume_noirq' undeclared here (not in a function); did you mean 'mcp16502_suspend_noirq'? mcp16502_resume_noirq) vim +527 drivers/regulator/mcp16502.c 524 525 #ifdef CONFIG_PM 526 static const struct dev_pm_ops mcp16502_pm_ops = { > 527 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mcp16502_suspend_noirq, > 528 mcp16502_resume_noirq) 529 }; 530 #endif 531 static const struct i2c_device_id mcp16502_i2c_id[] = { 532 { "mcp16502", 0 }, 533 { } 534 }; 535 MODULE_DEVICE_TABLE(i2c, mcp16502_i2c_id); 536 Signed-off-by:Andrei Stefanescu <andrei.stefanescu@microchip.com> Signed-off-by:
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/regulator/act8945a-regulator.c:340:1: warning: symbol 'act8945a_pm' was not declared. Should it be static? Fixes: 7482d6ec ("regulator: act8945a-regulator: Implement PM functionalities") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
- Dec 19, 2018
-
-
Kangjie Lu authored
If palmas_smps_read() fails, we should not use the read data in "reg" which may contain random value. The fix inserts a check for the return value of palmas_smps_read(): If it fails, we return the error code upstream and stop using "reg". Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Signed-off-by:
-
- Dec 17, 2018
-
-
Claudiu Beznea authored
Fix 'defined but not used' compiler warning for act8945a_suspend() function in case CONFIG_PM_SLEEP is not defined. Fixes: b5ebba46 ("regulator: act8945a-regulator: add shutdown function") Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Reported-by:
-
Priit Laes authored
Initial commit of set_ramp_delay feature was missing an assignment which should have populated slew_rate table for dcdc2 regulator. Add it. Fixes: d29f54df ("regulator: axp20x: add support for set_ramp_delay for AXP209") Signed-off-by:
Priit Laes <plaes@plaes.org> Signed-off-by:
-
- Dec 14, 2018
-
-
Andrei.Stefanescu@microchip.com authored
This patch adds support for entering/resuming suspend states. It does this by setting the LPM pin of the PMIC. When suspending the PMIC will enter the Low-power mode when the LPM pin will be set to high. If the suspend target state is suspend-to-mem, the PMIC will transition to Hibernate mode, otherwise, if it is standby, it will remain in Low-power mode. Signed-off-by:
-
Olliver Schinagl authored
The AXP20X_OFF define is an actual specific bit, define it as such. Signed-off-by:
Olliver Schinagl <oliver@schinagl.nl> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Olliver Schinagl authored
Add the bitops.h header as we need it, alphabetize header order. Signed-off-by:
-
Olliver Schinagl authored
The OLinuXino Lime2 has a big capacitor on its LDO3 output. It is actually too large, causing the PMIC to shutdown when toggling the LDO3. By enabling soft-start and ramp delay we increase the time for the capacitor to charge lowering the current drain on the power regulator. Signed-off-by:
-
Olliver Schinagl authored
In the past, there have been words on various lists that if LDO3 is disabled in u-boot, but enabled in the DTS, the axp209 driver would fail to continue/hang. Several enable/disable patches have been issues to devicetree's in both the kernel and u-boot to address this issue. What really happened however, was that the AXP209 shuts down without a notice and without setting an interrupt. This is caused when LDO3 gets overloaded, for example with large capacitors on the LDO3 output. Normally, we would expect that AXP209 would source 200 mA as per datasheet and set and trigger an interrupt when being overloaded. For some reason however, this does not happen. As a work-around, implement software-based 'regulator-soft-start' property for AXP209 LDO3 regulator, which is used to first bring up the LDO3 to the lowest possible voltage and then enable the LDO. After that, we can set the requested voltage as usual. Combining this setting with the regulator-ramp-delay allows LDO3 to come up slowly and staggered, potentially reducing overall inrush current. Signed-off-by:
-
Olliver Schinagl authored
In the past, there have been words on various lists that if LDO3 is disabled in u-boot, but enabled in the DTS, the axp209 driver would fail to continue/hang. Several enable/disable patches have been issues to devicetree's in both the kernel and u-boot to address this issue. What really happened however, was that the AXP209 shuts down without a notice and without setting an interrupt. This is caused when LDO3 gets overloaded, for example with large capacitors on the LDO3 output. Normally, we would expect that AXP209 would source 200 mA as per datasheet and set and trigger an interrupt when being overloaded. For some reason however, this does not happen. As a work-around, we use the soft-start constraint of the regulator node to first bring up the LDO3 to the lowest possible voltage and then enable the LDO. After that, we can set the requested voltage as usual. Combining this setting with the regulator-ramp-delay allows LDO3 to enable voltage slowly and staggered, potentially reducing overall inrush current. Signed-off-by:
-
Olliver Schinagl authored
The AXP209 supports ramping up voltages on several regulators such as DCDC2 and LDO3, therefore we can use the standard 'regulator-ramp-delay' property for those 2 regulators. Note that the voltage ramp only works when the regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V. When turning on the regulator, no voltage ramp is performed in hardware. What this means, is that if the bootloader brings up the voltage at 0.7 V, the ramp delay property is properly applied. If however, the bootloader leaves the power off, no ramp delay is applied when the power is enabled by the regulator framework. Signed-off-by:
-
Olliver Schinagl authored
The AXP209 supports ramping up voltages on several regulators such as DCDC2 and LDO3. This patch adds preliminary support for the regulator-ramp-delay property for these 2 regulators. Note that the voltage ramp only works when regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V. When turning on the regulator, no voltage ramp is performed in hardware. What this means, is that if the bootloader brings up the voltage at 0.7 V, the ramp delay property is properly applied. If however, the bootloader leaves the power off, no ramp delay is applied when the power is enabled by the regulator framework. Signed-off-by:
-
Olliver Schinagl authored
The current axp20x names the ramping register 'scal' which probably means scaling. Since the register really has nothing to do with scaling, but really is the voltage ramp we rename it appropriately. Signed-off-by:
-
Mark Brown authored
Merge branch 'topic/axp20x' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.21
-
- Dec 13, 2018
-
-
Andrei.Stefanescu@microchip.com authored
This patch adds a regulator driver for the MCP16502 PMIC. This drivers supports basic operations through the regulator interface such as: - setting/reading voltage - setting/reading operating mode - reading current status Signed-off-by:
-
Andrei.Stefanescu@microchip.com authored
This patch adds a maintainer for the MCP16502 PMIC driver. Signed-off-by:
-
Andrei.Stefanescu@microchip.com authored
This patch describes the compatible and the device tree bindings necessary for the MCP16502 PMIC. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Claudiu Beznea authored
Add documentation for regulator modes and suspend states. Signed-off-by:
-
Claudiu Beznea authored
Implement shutdown method to make sure the PMIC will not enter the suspend state when the system is shutdown. This work is based on work done by Borris Brezillon on [1]. [1] https://www.spinics.net/lists/kernel/msg2942960.html Signed-off-by:
-
Claudiu Beznea authored
Fix line over 80 chars checkpatch.pl warning. Signed-off-by:
-
Boris Brezillon authored
The regulator supports a dedicated suspend mode. Implement the appropriate ->set_suspend_xx() hooks, add support for ->set_mode(), and provide basic PM ops functionalities to setup the regulator in a suspend state when the system is entering suspend. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> [claudiu.beznea@microchip.com: remove shutdown function, use dev_pm_ops, fix checkpatch warning, adapt commit message, add LDO modes support, move modes constants to active-semi,8945a-regulator.h, remove rdevs from struct act8945a_pmic, add op_mode to act8945a_pmic] Signed-off-by:
-
Claudiu Beznea authored
Unlock expert registers for act8945a. This is based on orginal work of Boris Brezillon at [1]. [1] https://www.spinics.net/lists/kernel/msg2942960.html Signed-off-by:
-
Linus Walleij authored
After making sure that the regulator core always take over handling of the GPIO descriptors, the gpiod_put() on the errorpath of the Arizona LDO1 driver becomes redundant. Reported-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
-
Linus Walleij authored
After making sure that the regulator core always take over handling of the GPIO descriptors, the gpiod_put() on the errorpath of the wm8994 driver becomes redundant. Reported-by:
-
- Dec 12, 2018
-
-
Douglas Anderson authored
At the end of regulator_resolve_supply() we have historically turned on our supply in some cases. This could be for one of two reasons: 1. If resolving supplies was happening before the call to set_machine_constraints() we needed to predict if set_machine_constraints() was going to turn the regulator on and we needed to preemptively turn the supply on. 2. Maybe set_machine_constraints() happened before we could resolve supplies (because we failed the first time to resolve) and thus we might need to propagate an enable that already happened up to our supply. Historically regulator_resolve_supply() used _regulator_is_enabled() to decide whether to turn on the supply. Let's change things a little bit. Specifically: 1. Let's try to enable the supply and the regulator in the same place, both in set_machine_constraints(). This means that we have exactly the same logic for enabling the supply and the regulator. 2. Let's properly set use_count when we enable always-on or boot-on regulators even for those that don't have supplies. The previous commit 1fc12b05 ("regulator: core: Avoid propagating to supplies when possible") only did this right for regulators with supplies. 3. Let's make it clear that the only time we need to enable the supply in regulator_resolve_supply() is if the main regulator is currently in use. By using use_count (like the rest of the code) to decide if we're going to enable our supply we keep everything consistent. Overall the new scheme should be cleaner and easier to reason about. In addition to fixing regulator_summary to be more correct (because of the more correct use_count), this change also has the effect of no longer using _regulator_is_enabled() in this code path. _regulator_is_enabled() could return an error code for some regulators at bootup (like RPMh) that can't read their initial state. While one can argue that the design of those regulators is sub-optimal, the new logic sidesteps this brokenness. This fix in particular fixes observed problems on Qualcomm sdm845 boards which use the above-mentioned RPMh regulator. Those problems were made worse by commit 1fc12b05 ("regulator: core: Avoid propagating to supplies when possible") because now we'd think at bootup that the SD regulators were already enabled and we'd never try them again. Fixes: 1fc12b05 ("regulator: core: Avoid propagating to supplies when possible") Reported-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Mark Brown authored
Merge branch 'for-linus' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.21
-
- Dec 11, 2018
-
-
Mark Brown authored
-
Linus Walleij authored
The GPIO descriptors used by the S2MPS11 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before handing it over to the regulators core. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
-
Linus Walleij authored
The GPIO descriptors used by the TPS65090 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before handing it over to the regulators core. Signed-off-by:
-
Linus Walleij authored
The GPIO descriptors used by the S5M8767 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before handing it over to the regulators core. Signed-off-by:
-
Linus Walleij authored
The GPIO descriptors used by the DA9211 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before handing it over to the regulators core. Signed-off-by:
-
Linus Walleij authored
The probe path of this driver is a bit complex: sometimes the GPIO descriptor is passed to the regulator core, sometimes it is not. To handle it in a simple way: stick with the devm_* resource management and unhinge the GPIO descriptor devres handling right before passing it to the regulator core, if we pass it to the regulator core. Fixes: e7d2be69 ("regulator: max8973: Pass descriptor instead of GPIO number") Signed-off-by:
-
Linus Walleij authored
This adds a function named devm_gpiod_unhinge() that removes the resource management from a GPIO descriptor. I am not sure if this is the best anglosaxon name for the function, no other managed resources have an equivalent currently, but I chose "unhinge" as the closest intuitive thing I could imagine that fits Rusty Russell's API design criterions "the obvious use is the correct one" and "the name tells you how to use it". The idea came out of a remark from Mark Brown that it should be possible to handle over management of a resource from devres to the regulator core, and indeed we can do that. Signed-off-by:
-
Linus Walleij authored
When we get a nonexeclusive GPIO descriptor using managed resources, we should only add it to the list of managed resources once: on the first user. Augment the devm_gpiod_get_index() and devm_gpiod_get_from_of_node() calls to account for this by checking if the descriptor is already resource managed before we proceed to allocate a new resource management struct. Fixes: b0ce7b29 ("regulator/gpio: Allow nonexclusive GPIO access") Reported-by:
-
Linus Walleij authored
This makes gpiod_get_from_of_node() respect the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which is especially nice when getting regulator GPIOs right out of device tree nodes. Suggested-by:
-
Linus Walleij authored
Use the gpiod_get_from_of_node() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fix up the errorpath so that we free this descriptor if an error occurs in the callback. Rely on the regulator core to deal with it after this point: a previous patch fixed up the regulator core to properly dispose any GPIO descriptors once you call regulator_register(). Fixes: 96392c3d ("regulator: max77686: Pass descriptor instead of GPIO number") Signed-off-by:
-
Linus Walleij authored
This function already exist inside gpiolib, we were just reluctant to make it available to the kernel at large as the devm_* seemed to be enough for anyone. However we found out that regulators need to do their own lifecycle/refcounting on GPIO descriptors and explicitly call gpiod_put() when done with a descriptor, so export this function so we can hand the refcounting over to the regulator core for these descriptors after retrieveal. Signed-off-by:
-
