summaryrefslogtreecommitdiffstats
path: root/include/linux/regulator/driver.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'regulator-v5.17' of ↵Linus Torvalds2022-01-111-13/+54
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator updates from Mark Brown: "This has been a fairly quiet release for the regulator API, the main thing has been the addition of helpers for interrupt handling from Matti Vaittinen. We do also have support for quite a few new devices. Summary: - Helpers for trivial interrupt notifications, making it easier for drivers to handle error interrupts. - Support for Dialog DA914x, Maxim MAX2008x, Qualcomm PM8826, PMG1100, and PM8450 and TI TPS68470" * tag 'regulator-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (30 commits) regulator: Add MAX20086-MAX20089 driver dt-bindings: regulators: Add bindings for Maxim MAX20086-MAX20089 regulator: qcom_smd: Align probe function with rpmh-regulator regulator: remove redundant ret variable regulator: qcom-labibb: OCP interrupts are not a failure while disabled regulator: dt-bindings: samsung,s5m8767: Move fixed string BUCK9 to 'properties' regulator: Introduce tps68470-regulator driver drivers/regulator: remove redundant ret variable regulator: fix bullet lists of regulator_ops comment regulator: Fix type of regulator-coupled-max-spread property regulator: maxim,max8973: Document interrupts property regulator: qcom-rpmh: Add support for PM8450 regulators regulator: qcom,rpmh: Add compatible for PM8450 regulator: da9121: Add DA914x binding info regulator: da9121: Remove erroneous compatible from binding regulator: da9121: Add DA914x support regulator: da9121: Prevent current limit change when enabled regulator: qcom-rpmh: Add PMG1110 regulators dt-bindings: regulator: Add compatible for pmg1110 regulator: qcom_spmi: Add pm8226 regulators ...
| * regulator: fix bullet lists of regulator_ops commentYanteng Si2021-12-071-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 89a6a5e56c82("regulator: add property parsing and callbacks to set protection limits") which introduced a warning: Documentation/driver-api/regulator:166: ./include/linux/regulator/driver.h:96: WARNING: Unexpected indentation. Documentation/driver-api/regulator:166: ./include/linux/regulator/driver.h:98: WARNING: Block quote ends without a blank line; unexpected unindent. Let's fix them. Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: https://lore.kernel.org/r/20211207123230.2262047-1-siyanteng@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
| * regulator: irq_helper: Provide helper for trivial IRQ notificationsMatti Vaittinen2021-11-241-0/+2
| | | | | | | | | | | | | | | | | | | | | | Provide a generic map_event helper for regulators which have a notification IRQ with single, well defined purpose. Eg, IRQ always indicates exactly one event for exactly one regulator device. For such IRQs the mapping is trivial. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/603b7ed1938013a00371c1e7ccc63dfb16982b87.1637736436.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * regulator: Add regulator_err2notif() helperMatti Vaittinen2021-11-241-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | Help drivers avoid storing both supported notification and supported error flags by supporting conversion from regulator error to notification. This may help saving some bytes. Add helper for finding the regulator notification corresponding to a regulator error. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/eb1755ac0569ff07ffa466cf8912c6fd50e7c7c6.1637736436.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * regulator: Drop unnecessary struct memberMatti Vaittinen2021-11-241-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The irq_flags from the regulator IRQ helper description struct was never used. The IRQ flags are passed as parameters to helper registration instead. Remove the unnecessary struct field. Fixes: 7111c6d1b31b ("regulator: IRQ based event/error notification helpers") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/5f6371e178453fa2b165da50452f7db4e986debb.1637736436.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * regulator: Add units to limit documentationMatti Vaittinen2021-11-181-3/+5
| | | | | | | | | | | | | | | | | | | | | | The documentation for limits used at protection level setting did not mention the units. Fix the units in documentation to match values passed in from device-tree (uV, uA, Kelvin) to avoid confusion. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/111114aca991e41e49a32f89b74e95285f07c1e3.1637233864.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: Update protection IRQ helper docsMatti Vaittinen2021-11-181-6/+8
|/ | | | | | | | | | | | | The documentation of IRQ notification helper had still references to first RFC implementation which called BUG() while trying to protect the hardware. Behaviour was improved as calling the BUG() was not a proper solution. Current implementation attempts to call poweroff if handling of potentially damaging error notification fails. Update the documentation to reflect the actual behaviour. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/0c9cc4bcf20c3da66fd5a85c97ee4288e5727538.1637233864.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Documentation fix for regulator error notification helperMatti Vaittinen2021-08-231-3/+4
| | | | | | | | | | | | | | | | | The helper to send IRQ notification for regulator errors had still old description mentioning calling BUG() as a last resort when error status reading has kept failing for more times than a given threshold. The impementation calling BUG() did never end-up in-tree but was replaced by hopefully more sophisticated handler trying to power-off the system. Fix the documentation to reflect actual behaviour. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210823075651.GA3717293@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Minor regulator documentation fixes.Matti Vaittinen2021-08-181-1/+7
| | | | | | | | | The newly added regulator ramp-delay specifiers in regulator desc lacked the documentation. Add some. Also fix a typo. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210818041513.GA2408290@dc7vkhyh15000m40t6jht-3.rev.dnainternet.fi Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: devres: remove devm_regulator_unregister() functionAlexandru Ardelean2021-07-111-1/+0
| | | | | | | | | | | | | | | | | | This API hook isn't used anywhere and most-likely exists because of the general principle of C APIs, where if an API function does an allocation/registration, it must also have an equivalent deallocation/deregistration counterpart. For devm_ functions this isn't all that true (for all cases), as the idea of these function is to provide an auto-cleanup logic on drivers/system de-init. Removing this also discourages any weird logic that could be created with such an API function. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625122324.327585-3-aardelean@deviqon.com Signed-off-by: Mark Brown <broonie@kernel.org>
* Merge series "Extend regulator notification support" from Matti Vaittinen ↵Mark Brown2021-06-211-4/+182
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <matti.vaittinen@fi.rohmeurope.com>: Extend regulator notification support This series extends the regulator notification and error flag support. Initial discussion on the topic can be found here: https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.camel@fi.rohmeurope.com/ In a nutshell - the series adds: 1. WARNING level events/error flags. (Patch 3) Current regulator 'ERROR' event notifications for over/under voltage, over current and over temperature are used to indicate condition where monitored entity is so badly "off" that it actually indicates a hardware error which can not be recovered. The most typical hanling for that is believed to be a (graceful) system-shutdown. Here we add set of 'WARNING' level flags to allow sending notifications to consumers before things are 'that badly off' so that consumer drivers can implement recovery-actions. 2. Device-tree properties for specifying limit values. (Patches 1, 5) Add limits for above mentioned 'ERROR' and 'WARNING' levels (which send notifications to consumers) and also for a 'PROTECTION' level (which will be used to immediately shut-down the regulator(s) W/O informing consumer drivers. Typically implemented by hardware). Property parsing is implemented in regulator core which then calls callback operations for limit setting from the IC drivers. A warning is emitted if protection is requested by device tree but the underlying IC does not support configuring requested protection. 3. Helpers which can be registered by IC. (Patch 4) Target is to avoid implementing IRQ handling and IRQ storm protection in each IC driver. (Many of the ICs implementin these IRQs do not allow masking or acking the IRQ but keep the IRQ asserted for the whole duration of problem keeping the processor in IRQ handling loop). 4. Emergency poweroff function (refactored out of the thermal_core to kernel/reboot.c) which is called if IC fires error IRQs but IC reading fails and given retry-count is exceeded. (Patches 2, 4) Please note that the mutex in the emergency shutdown was replaced by a simple atomic in order to allow call from any context. The helper was attempted to be done so it could be used to implement roughly same logic as is used in qcom-labibb regulator. This means amongst other things a safety shut-down if IC registers are not readable. Using these shut-down retry counters are optional. The idea is that the helper could be also used by simpler ICs which do not provide status register(s) which can be used to check if error is still active. ICs which do not have such status register can simply omit the 'renable' callback (and retry-counts etc) - and helper assumes the situation is Ok and re-enables IRQ after given time period. If problem persists the handler is ran again and another notification is sent - but at least the delay allows processor to avoid IRQ loop. Patch 7 takes this notification support in use at BD9576MUF. Patch 8 is related to MFD change which is not really related to the RFC here. It was added to this series in order to avoid potential conflicts. Patch 9 adds a maintainers entry. Changelog v10-RESEND: - rebased on v5.13-rc4 Changelog v10: - rebased on v5.13-rc2 - Move rdev_*() print macros to the internal.h and use rdev_dbg() from irq_helpers.c - Export rdev_get_name() and move it from coupler.h to driver.h for others to use. (It was already in coupler.h but not exported - usage was limited and coupler.h does not sound like optimal place as rdev_name is not only used by coupled regulators) - Send all regulator notifications from irq_helpers.c at one OR'd event for the sake of simplicity. For BD9576 this does not matter as it has own IRQ for each event case. Header defining events says they may be OR'd. - Change WARN() at protection shutdown to pr_emerg as suggested by Petr. Changelog v9: - rebases on v5.13-rc1 - Update thermal documentation - Fix regulator notification event number Changelog v8: - split shutdown API adding and thermal core taking it in use to own patches. - replace the spinlock with atomic when ensuring the emergency shutdown is only called once. Changelog v7: general: - rebased on v5.12-rc7 - new patch for refactoring the hw-failure reboot logic out of thermal_core.c for others to use. notification helpers: - fix regulator error_flags query - grammar/typos - do not BUG() but attempt to shut-down the system - use BITS_PER_TYPE() Changelog v6: Add MAINTAINERS entry Changes to IRQ notifiers - move devm functions to drivers/regulator/devres.c - drop irq validity check - use devm_add_action_or_reset() - fix styling issues - fix kerneldocs Changelog v5: - Fix the badly formatted pr_emerg() call. Changelog v4: - rebased on v5.12-rc6 - dropped RFC - fix external FET DT-binding. - improve prints for cases when expecting HW failure. - styling and typos Changelog v3: Regulator core: - Fix dangling pointer access at regulator_irq_helper() stpmic1_regulator: - fix function prototype (compile error) bd9576-regulator: - Update over current limits to what was given in new data-sheet (REV00K) - Allow over-current monitoring without external FET. Set limits to values given in data-sheet (REV00K). Changelog v2: Generic: - rebase on v5.12-rc2 + BD9576 series - Split devm variant of delayed wq to own series Regulator framework: - Provide non devm variant of IRQ notification helpers - shorten dt-property names as suggested by Rob - unconditionally call map_event in IRQ handling and require it to be populated BD9576 regulators: - change the FET resistance property to micro-ohms - fix voltage computation in OC limit setting
| * regulator: add property parsing and callbacks to set protection limitsMatti Vaittinen2021-06-211-4/+37
| | | | | | | | | | | | | | | | | | Add DT property parsing code and setting callback for regulator over/under voltage, over-current and temperature error limits. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/e7b8007ba9eae7076178bf3363fb942ccb1cc9a5.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * regulator: IRQ based event/error notification helpersMatti Vaittinen2021-06-211-0/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | Provide helper function for IC's implementing regulator notifications when an IRQ fires. The helper also works for IRQs which can not be acked. Helper can be set to disable the IRQ at handler and then re-enabling it on delayed work later. The helper also adds regulator_get_error_flags() errors in cache for the duration of IRQ disabling. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/ebdf86d8c22b924667ec2385330e30fcbfac0119.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * regulator: move rdev_print helpers to internal.hMatti Vaittinen2021-06-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The rdev print helpers are a nice way to print messages related to a specific regulator device. Move them from core.c to internal.h As the rdev print helpers use rdev_get_name() export it from core.c. Also move the declaration from coupler.h to driver.h because the rdev name is not just a coupled regulator property. I guess the main audience for rdev_get_name() will be the regulator core and drivers. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/dc7fd70dc31de4d0e820b7646bb78eeb04f80735.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: core: Add regulator_sync_voltage_rdev()Dmitry Osipenko2021-06-011-0/+1
|/ | | | | | | | | | | | Some NVIDIA Tegra devices use a CPU soft-reset method for the reboot and in this case we need to restore the coupled voltages to the state that is suitable for hardware during boot. Add new regulator_sync_voltage_rdev() helper which is needed by regulator drivers in order to sync voltage of a coupled regulators. Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
* regulator: core: Fix off_on_delay handlingVincent Whitchurch2021-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The jiffies-based off_on_delay implementation has a couple of problems that cause it to sometimes not actually delay for the required time: (1) If, for example, the off_on_delay time is equivalent to one jiffy, and the ->last_off_jiffy is set just before a new jiffy starts, then _regulator_do_enable() does not wait at all since it checks using time_before(). (2) When jiffies overflows, the value of "remaining" becomes higher than "max_delay" and the code simply proceeds without waiting. Fix these problems by changing it to use ktime_t instead. [Note that since jiffies doesn't start at zero but at INITIAL_JIFFIES ("-5 minutes"), (2) above also led to the code not delaying if the first regulator_enable() is called when the ->last_off_jiffy is not initialised, such as for regulators with ->constraints->boot_on set. It's not clear to me if this was intended or not, but I've preserved this behaviour explicitly with the check for a non-zero ->last_off.] Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20210423114524.26414-1-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Add regmap helper for ramp-delay settingMatti Vaittinen2021-04-021-0/+5
| | | | | | | | | | | Quite a few regulator ICs do support setting ramp-delay by writing a value matching the delay to a ramp-delay register. Provide a simple helper for table-based delay setting. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/f101f1db564cf32cb58719c77af0b00d7236bb89.1617020713.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: helpers: Export helper voltage listingMatti Vaittinen2021-04-021-0/+2
| | | | | | | | | | | Some drivers need to translate voltage values to selectors prior regulator registration. Currently a regulator_desc based list_voltages helper is only exported for regulators using the linear_ranges. Export similar helper also for regulators using simple linear mapping. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/1200ef7a50c84327ada019b85f6527b4fc9b5ce1.1617020713.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: add of_match_full_name boolean flagCristian Marussi2020-11-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | During regulators registration, if .of_match and .regulators_node are defined as non-null strings in struct regulator_desc the core searches the DT subtree rooted at .regulators_node trying to match, at first, .of_match against the 'regulator-compatible' property and, then, falling back to use the name of the node itself to determine a good match. Property 'regulator-compatible', though, is now deprecated and falling back to match against the node name, works fine only as long as the involved nodes are named in an unique way across the searched subtree; if that's not the case, like when using <common-name>@<unit> style naming for properties indexed via 'reg' property (as advised by the standard), the above matching mechanism based on the simple common name will lead to multiple matches and the only viable alternative would be to properly define the now deprecated 'regulator-compatible' as the node full name, i.e. <common-name>@<unit>. In order to address this case without using such deprecated binding, define a new boolean flag .of_match_full_name in struct regulator_desc to force the core to match against the node full-name instead of the plain name. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20201119191051.46363-4-cristian.marussi@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: unexport regulator_lock/unlock()Michał Mirosław2020-09-211-3/+0
| | | | | | | | | | regulator_lock/unlock() was used only to guard regulator_notifier_call_chain(). As no users remain, make the functions internal. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/d3381aabd2632aff5e7b839d55868bec6e85c811.1600550732.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Correct kernel-doc inconsistencyColton Lewis2020-07-171-1/+1
| | | | | | | | | | | Silence documentation build warning by correcting kernel-doc comments. ./include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' ./include/linux/regulator/driver.h:206: warning: Function parameter or member 'resume' not described in 'regulator_ops' Signed-off-by: Colton Lewis <colton.w.lewis@protonmail.com> Link: https://lore.kernel.org/r/20200715191438.29312-1-colton.w.lewis@protonmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Allow regulators to verify enabled during enable()Sumit Semwal2020-07-151-0/+5
| | | | | | | | | | | | | Some regulators might need to verify that they have indeed been enabled after the enable() call is made and enable_time delay has passed. This is implemented by repeatedly checking is_enabled() upto poll_enabled_time, waiting for the already calculated enable delay in each iteration. Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20200622124110.20971-2-sumit.semwal@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: use linear_ranges helperMatti Vaittinen2020-05-081-22/+5
| | | | | | | | | | | Change the regulator helpers to use common linear_ranges code. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: driver.h: fix regulator_map_* function namesMauro Carvalho Chehab2020-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | The toolchain produces a warning on this driver when building the docs: ./include/linux/regulator/driver.h:284: WARNING: Unknown target name: "regulator_regmap_x_voltage". While fixing it, we notices that there's no function names with the above pattern. It seems that some previous patch renamed it to regulator_map_* instead. So, change the function name, replacing "x" by "*", with is a more used way to add a wildcard, and escape those with ``literal`` markup, in order to avoid the toolchain to think that this is a link to some existing document chapter. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/b9f5687bcf981a88c9d1fd04d759a540fda53a99.1584456635.git.mchehab+huawei@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
* Merge remote-tracking branch 'regulator/topic/coupled' into regulator-nextMark Brown2019-07-041-3/+3
|\
| * regulator: core: Introduce API for regulators coupling customizationDmitry Osipenko2019-06-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Right now regulator core supports only one type of regulators coupling, the "voltage max-spread" which keeps voltages of coupled regulators in a given range from each other. A more sophisticated coupling may be required in practice, one example is the NVIDIA Tegra SoCs which besides the max-spreading have other restrictions that must be adhered. Introduce API that allow platforms to provide their own customized coupling algorithms. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* | Merge branch 'regulator-5.3' into regulator-nextMark Brown2019-07-041-0/+6
|\ \
| * | regulator: implement selector steppingBartosz Golaszewski2019-07-041-0/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | Some regulators require that the requested voltage be reached gradually by setting all or some of the intermediate values. Implement a new field in the regulator description struct that allows users to specify the number of selectors by which the regulator API should step when ramping the voltage up/down. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190703161035.31808-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
* / treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-191-4/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: Add set/get_current_limit helpers for regmap usersAxel Lin2019-03-031-0/+7
| | | | | | | | | By setting curr_table, n_current_limits, csel_reg and csel_mask, the regmap users can use regulator_set_current_limit_regmap and regulator_get_current_limit_regmap for set/get_current_limit callbacks. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Fix comment for csel_reg and csel_maskAxel Lin2019-03-031-2/+2
| | | | | | | | The csel_reg and csel_mask fields in struct regulator_desc needs to be generic for drivers. Not just for TPS65218. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: add regulator_desc_list_voltage_linear_rangeMatti Vaittinen2019-02-141-0/+6
| | | | | | | | | | | | | Add regulator_desc_list_voltage_linear_range which can be used by drivers for getting the voltages before regulator is registered. This may be useful for drivers which need to fetch the voltage selectors at device-tree parsing callback. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Mark Brown <broonie@kernel.org> Tested-by: Angus Ainslie <angus@akkea.ca> Reviewed-by: Angus Ainslie <angus@akkea.ca> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Only support passing enable GPIO descriptorsLinus Walleij2019-02-061-11/+1
| | | | | | | | | | | | Now that we changed all providers to pass descriptors into the core for enable GPIOs instead of a global GPIO number, delete the support for passing GPIO numbers in, and we get a cleanup and size reduction in the core, and from a GPIO point of view we use the modern, cleaner interface. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: provide rdev_get_regmap()Bartosz Golaszewski2019-01-091-0/+1
| | | | | | | Provide a helper allowing to access regulator's regmap. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Only count load for enabled consumersDouglas Anderson2018-11-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In general when the consumer of a regulator requests that the regulator be disabled it no longer will be drawing much load from the regulator--it should just be the leakage current and that should be very close to 0. Up to this point the regulator framework has continued to count a consumer's load request for disabled regulators. This has led to code patterns that look like this: enable_my_thing(): regular_set_load(reg, load_uA) regulator_enable(reg) disable_my_thing(): regulator_disable(reg) regulator_set_load(reg, 0) Sometimes disable_my_thing() sets a nominal (<= 100 uA) load instead of setting a 0 uA load. I will make the assertion that nearly all (if not all) places where we set a nominal load of 100 uA or less we end up with a result that is the same as if we had set a load of 0 uA. Specifically: - The whole point of setting the load is to help set the operating mode of the regulator. Higher loads may need less efficient operating modes. - The only time this matters at all is if there is another consumer of the regulator that wants the regulator on. If there are no other consumers of the regulator then the regulator will turn off and we don't care about the operating mode. - If there's another consumer that actually wants the regulator on then presumably it is requesting a load that makes our nominal <= 100 uA load insignificant. A quick survey of the existing callers to regulator_set_load() to see how everyone uses it: Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Use ww_mutex for regulators lockingDmitry Osipenko2018-11-191-1/+5
| | | | | | | | | Wait/wound mutex shall be used in order to avoid lockups on locking of coupled regulators. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Suggested-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Limit regulators coupling to a single coupleDmitry Osipenko2018-11-081-1/+1
| | | | | | | | | Device tree binding was changed in a way that now max-spread values must be defied per regulator pair. Limit number of pairs in order to adapt to the new binding without changing regulators code. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Support regulators where voltage ranges are selectableMatti Vaittinen2018-09-281-1/+19
| | | | | | | | | | For example ROHM BD71837 and ROHM BD71847 Power management ICs have regulators which provide multiple linear ranges. Ranges can be selected by individual non contagious bit in vsel register. Add regmap helper functions for selecting ranges. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Change suspend_late to suspendpascal paillet2018-07-051-1/+1
| | | | | | | | | Change suspend_late ops to suspend normal ops. The goal is to avoid requesting all the regulator drivers to be operational in suspend late phase. Signed-off-by: pascal paillet <p.paillet@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Fix typo in comment of struct regulator_linear_rangeMatthias Kaehlcke2018-06-181-1/+1
| | | | | | | regulator_map_linar_range() => regulator_map_linear_range() Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Parse coupled regulators propertiesMaciej Purski2018-05-171-0/+18
| | | | | | | | | | | | | | | | | | | | | | On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Add new structure "coupling_desc" to regulator_dev, which contains pointers to all coupled regulators including the owner of the structure, number of coupled regulators and counter of currently resolved regulators. Add of_functions to parse all data needed in regulator coupling. Provide method to check DTS data consistency. Check if each coupled regulator's max_spread is equal and if their lists of regulators match. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Make locks re-entrantMaciej Purski2018-05-171-0/+2
| | | | | | | | | | | | | | | | | | | | Setting voltage, enabling/disabling regulators requires operations on all regulators related with the regulator being changed. Therefore, all of them should be locked for the whole operation. With the current locking implementation, adding additional dependency (regulators coupling) causes deadlocks in some cases. Introduce a possibility to attempt to lock a mutex multiple times by the same task without waiting on a mutex. This should handle all reasonable coupling-supplying combinations, especially when two coupled regulators share common supplies. The only situation that should be forbidden is simultaneous coupling and supplying between a pair of regulators. The idea is based on clk core. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Allow for regulators that can't be read at bootupDouglas Anderson2018-05-171-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regulators attached via RPMh on Qualcomm sdm845 apparently are write-only. Specifically you can send a request for a certain voltage but you can't read back to see what voltage you've requested. What this means is that at bootup we have absolutely no idea what voltage we could be at. As discussed in the patches to try to support the RPMh regulators [1], the fact that regulators are write-only means that its driver's get_voltage_sel() should return an error code if it's called before any calls to set_voltage_sel(). This causes problems in machine_constraints_voltage() when trying to apply the constraints. A proposed fix was to come up with an error code that could be returned by get_voltage_sel() which would cause the regulator framework to simply try setting the voltage with the current constraints. In this patch I propose the error code -ENOTRECOVERABLE. In errno.h this error is described as "State not recoverable". Though the error code was originally intended "for robust mutexes", the description of the error code seems to apply here because we can't read the state of the regulator. Also note that the only existing user of this error code in the regulator framework is tps65090-regulator.c which returns this error code from the enable() call (not get_voltage() or get_voltage_sel()), so there should be no existing regulators that might accidentally get the new behavior. (Side note is that tps65090 seems to interpret this error code to mean an error that you can't recover from rather than some data that can't be recovered). [1] https://patchwork.kernel.org/patch/10340897/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Support passing an initialized GPIO enable descriptorLinus Walleij2018-02-161-0/+3
| | | | | | | | | | | | | | | | | | | | We are currently passing a GPIO number from the global GPIO numberspace into the regulator core for handling enable GPIOs. This is not good since it ties into the global GPIO numberspace and uses gpio_to_desc() to overcome this. Start supporting passing an already initialized GPIO descriptor to the core instead: leaf drivers pick their descriptors, associated directly with the device node (or from ACPI or from a board descriptor table) and use that directly without any roundtrip over the global GPIO numberspace. This looks messy since it adds a bunch of extra code in the core, but at the end of the patch series we will delete the handling of the GPIO number and only deal with descriptors so things end up neat. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: add PM suspend and resume hooksChunyan Zhang2018-01-261-0/+2
| | | | | | | | | | | | | | | | | | | In this patch, consumers are allowed to set suspend voltage, and this actually just set the "uV" in constraint::regulator_state, when the regulator_suspend_late() was called by PM core through callback when the system is entering into suspend, the regulator device would act suspend activity then. And it assumes that if any consumer set suspend voltage, the regulator device should be enabled in the suspend state. And if the suspend voltage of a regulator device for all consumers was set zero, the regulator device would be off in the suspend state. This patch also provides a new function hook to regulator devices for resuming from suspend states. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
*-. Merge remote-tracking branches 'regulator/topic/helpers', ↵Mark Brown2017-04-301-0/+16
|\ \ | | | | | | | | | 'regulator/topic/hi655x', 'regulator/topic/lm363x', 'regulator/topic/ltc3589' and 'regulator/topic/ltc3676' into regulator-next
| * | regulator: helpers: Add regmap set_pull_down helperCharles Keepax2017-04-061-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Add a helper function regulator_set_pull_down_regmap to allow regmap based regulators to easily enable pull down. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | regulator: helpers: Add regmap set_soft_start helperCharles Keepax2017-04-061-0/+8
| |/ | | | | | | | | | | | | | | Add a helper function regulator_set_soft_start_regmap to allow regmap based regulators to easily enable soft start. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* / regulator: core: Limit propagation of parent voltage count and listMatthias Kaehlcke2017-03-291-0/+2
|/ | | | | | | | | | | | | | | | | | | Commit 26988efe11b1 ("regulator: core: Allow to get voltage count and list from parent") introduces the propagation of the parent voltage count and list for regulators that don't provide this information themselves. The goal is to support simple switch regulators, however as a side effect normal continuous regulators can leak details of their supplies and provide consumers with inconsistent information. Limit the propagation of the voltage count and list to switch regulators. Fixes: 26988efe11b1 ("regulator: core: Allow to get voltage count and list from parent") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> 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>
* regulator: core: Add new API to poll for error conditionsAxel Haslam2016-11-041-0/+4
| | | | | | | | | | | | Regulator consumers can receive event notifications when errors are reported to the driver, but currently, there is no way for a regulator consumer to know when the error is over. To allow a regulator consumer to poll for error conditions add a new API: regulator_get_error_flags. Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-07 15:00:19 +0000