summaryrefslogtreecommitdiffstats
path: root/drivers/regulator/da9062-regulator.c
Commit message (Collapse)AuthorAgeFilesLines
* regulator: da9062: Make the use of IRQ optionalChristoph Niedermaier2023-07-131-6/+5
| | | | | | | | | | | | This patch makes the use of IRQ optional to make the DA9061/62 usable for designs that don't have the IRQ pin connected, because the regulator is usable without IRQ. Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com> Reviewed-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230713090328.3879-1-cniedermaier@dh-electronics.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14Douglas Anderson2023-03-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc). While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually. Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe. The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver". [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: remove locking around regulator_notifier_call_chain()Michał Mirosław2020-09-071-2/+0
| | | | | | | | | | | regulator_notifier_call_chain() doesn't need rdev lock and rdev's existence is assumed in the code anyway. Remove the locks from drivers. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/42393f66dcc4d80dcd9797be45216b4035aa96cb.1597032945.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20200211234612.GA28682@embeddedor Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Return REGULATOR_MODE_INVALID for invalid modeAxel Lin2019-11-221-1/+1
| | | | | | | | | | -EINVAL is not a valid return value for .of_map_mode, return REGULATOR_MODE_INVALID instead. Fixes: 844e7492ee3d ("regulator: da9062: add of_map_mode support for bucks") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191122045154.802-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: add of_map_mode support for bucksChristoph Fritz2019-11-151-0/+21
| | | | | | | | | | | This patch adds of_map_mode support for bucks to set regulator modes from within regulator framework. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by: Christian Hemp <c.hemp@phytec.de> Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de> Link: https://lore.kernel.org/r/1573652416-9848-3-git-send-email-chf.fritz@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: refactor buck modes into headerChristoph Fritz2019-11-151-18/+10
| | | | | | | | | | | | This patch refactors buck modes into a header file so that device trees can make use of these mode constants. The new header filename uses da9063 because DA9063 was the earlier chip and its driver code will want updating at some point in a similar manner. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Link: https://lore.kernel.org/r/1573652416-9848-2-git-send-email-chf.fritz@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Simplify da9062_buck_set_mode for BUCK_MODE_MANUAL caseAxel Lin2019-10-081-6/+3
| | | | | | | | | | The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify the logic as the result is the same. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20191007115009.25672-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
* Merge branch 'regulator-5.4' into regulator-5.5Mark Brown2019-10-081-71/+47
|\
| * regulator: da9062: fix suspend_enable/disable preparationMarco Felsch2019-09-231-71/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the suspend reg_field maps to the pmic voltage selection bits and is used during suspend_enabe/disable() and during get_mode(). This seems to be wrong for both use cases. Use case one (suspend_enabe/disable): Those callbacks are used to mark a regulator device as enabled/disabled during suspend. Marking the regulator enabled during suspend is done by the LDOx_CONF/BUCKx_CONF bit within the LDOx_CONT/BUCKx_CONT registers. Setting this bit tells the DA9062 PMIC state machine to keep the regulator on in POWERDOWN mode and switch to suspend voltage. Use case two (get_mode): The get_mode callback is used to retrieve the active mode state. Since the regulator-setting-A is used for the active state and regulator-setting-B for the suspend state there is no need to check which regulator setting is active. Fixes: 4068e5182ada ("regulator: da9062: DA9062 regulator driver") Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20190917124246.11732-2-m.felsch@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: da9062: Simplify the code iterating all regulatorsAxel Lin2019-10-071-4/+1
|/ | | | | | | | | It's more straightforward to use for statement here. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Steve Twiss <stwiss.opensource@diasemi.com> Link: https://lore.kernel.org/r/20191007115009.25672-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Remove dev_err() usage after platform_get_irq()Stephen Boyd2019-08-021-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wrong. Let's remove these prints with a simple semantic patch. // <smpl> @@ expression ret; struct platform_device *E; @@ ret = ( platform_get_irq(E, ...) | platform_get_irq_byname(E, ...) ); if ( \( ret < 0 \| ret <= 0 \) ) { ( -if (ret != -EPROBE_DEFER) -{ ... -dev_err(...); -... } | ... -dev_err(...); ) ... } // </smpl> While we're here, remove braces on if statements that only have one statement (manually). Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20190730181557.90391-38-swboyd@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9061/62: Adjust LDO voltage selection minimum valueFelix Riemann2019-06-201-16/+24
| | | | | | | | | | | | | | | | | | | | | | According to the DA9061 and DA9062 datasheets the LDO voltage selection registers have a lower value of 0x02. This applies to voltage registers VLDO1_A, VLDO2_A, VLDO3_A and VLDO4_A. This linear offset of 0x02 was previously not observed by the driver, causing the LDO output voltage to be systematically lower by two steps (= 0.1V). This patch fixes the minimum linear selector offset by setting it to a value of 2 and increases the n_voltages by the same amount allowing voltages in the range 0x02 -> 0.9V to 0x38 -> 3.6V to be correctly selected. Also fixes an incorrect calculaton for the n_voltages value in the regulator LDO2. These fixes effect all LDO regulators for DA9061 and DA9062. Acked-by: Steve Twiss <stwiss.opensource@diasemi.com> Tested-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Felix Riemann <felix.riemann@sma.de> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9xxx: Switch to SPDX identifierAxel Lin2019-05-031-14/+5
| | | | | | | Convert Dialog Semiconductor DA9xxx regulator drivers to SPDX identifier. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Convert to use regulator_set/get_current_limit_regmapAxel Lin2019-03-181-93/+32
| | | | | | | | Use regulator_set/get_current_limit_regmap helpers to save some code. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Steve Twiss <stwiss@opensource.diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Fix notifier mutex lock warningSteve Twiss2019-03-131-0/+2
| | | | | | | | | | | | | | | | The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 4068e5182ada ("regulator: da9062: DA9062 regulator driver") Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Use struct_size() in devm_kzalloc()Gustavo A. R. Silva2019-02-261-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = alloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = alloc(struct_size(instance, entry, count), GFP_KERNEL) Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Select maximum current in specific range for ↵Axel Lin2019-02-191-1/+1
| | | | | | | | | | | | set_current_limit Selecting the minimal value is only true for voltage regulators. For current regulators the maximum in the given range should be selected instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Check return value of devm_regmap_field_alloc callsAxel Lin2019-01-281-5/+24
| | | | | | | Since devm_regmap_field_alloc can fail, add error checking for it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9061: BUCK and LDO regulator driverSteve Twiss2017-06-071-12/+291
| | | | | | | | | | | | | | | | | | | | Regulator support for the DA9061 is added into the DA9062 regulator driver. The regulators for DA9061 differ from those of DA9062. A new DA9061 enumeration list for the LDOs and Bucks supported by this device is added. Regulator information added: the old regulator information for DA9062 is renamed from local_regulator_info[] to local_da9062_regulator_info[] and a new array is added to support local_da9061_regulator_info[]. The probe() function switches on the da9062_compatible_types enumeration and configures the correct da9062_regulator_info array and number of regulator entries. Kconfig is updated to reflect support for DA9061 and DA9062 regulators. Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9*: constify regulator_ops structuresJulia Lawall2015-12-221-2/+2
| | | | | | | | | The regulator_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Drop owner assignment from platform_driverKrzysztof Kozlowski2015-07-141-1/+0
| | | | | | | | platform_driver does not need to set an owner because platform_driver_register() will set it. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Remove unused variable build warningS Twiss2015-06-021-1/+0
| | | | | | | | | | | Remove the unused variable build warning for reg_matches that appears during the compilation of the DA9062 regulator driver. da9062-regulator.c: In function da9062_regulator_probe: da9062-regulator.c:727:29: warning: unused variable reg_matches Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: Fix modaliasAxel Lin2015-05-251-1/+1
| | | | | | | Remove extra space between platform prefix and driver name in MODULE_ALIAS. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9062: DA9062 regulator driverS Twiss2015-05-211-0/+843
Add BUCK and LDO regulator driver support for DA9062 Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-02 11:49:26 +0000