aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/regulator/driver.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-03-03regulator: core: Add set/get_current_limit helpers for regmap usersAxel Lin1-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>
2019-03-03regulator: Fix comment for csel_reg and csel_maskAxel Lin1-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>
2019-02-14regulator: add regulator_desc_list_voltage_linear_rangeMatti Vaittinen1-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>
2019-02-06regulator: core: Only support passing enable GPIO descriptorsLinus Walleij1-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>
2019-01-09regulator: provide rdev_get_regmap()Bartosz Golaszewski1-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>
2018-11-22regulator: core: Only count load for enabled consumersDouglas Anderson1-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>
2018-11-19regulator: core: Use ww_mutex for regulators lockingDmitry Osipenko1-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>
2018-11-08regulator: core: Limit regulators coupling to a single coupleDmitry Osipenko1-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>
2018-09-28regulator: Support regulators where voltage ranges are selectableMatti Vaittinen1-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>
2018-07-05regulator: core: Change suspend_late to suspendpascal paillet1-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>
2018-06-18regulator: Fix typo in comment of struct regulator_linear_rangeMatthias Kaehlcke1-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>
2018-05-17regulator: core: Parse coupled regulators propertiesMaciej Purski1-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>
2018-05-17regulator: core: Make locks re-entrantMaciej Purski1-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>
2018-05-17regulator: core: Allow for regulators that can't be read at bootupDouglas Anderson1-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>
2018-02-16regulator: core: Support passing an initialized GPIO enable descriptorLinus Walleij1-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>
2018-01-26regulator: add PM suspend and resume hooksChunyan Zhang1-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>
2017-04-30Merge remote-tracking branches 'regulator/topic/helpers', 'regulator/topic/hi655x', 'regulator/topic/lm363x', 'regulator/topic/ltc3589' and 'regulator/topic/ltc3676' into regulator-nextMark Brown1-0/+16
2017-04-06regulator: helpers: Add regmap set_pull_down helperCharles Keepax1-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>
2017-04-06regulator: helpers: Add regmap set_soft_start helperCharles Keepax1-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>
2017-03-29regulator: core: Limit propagation of parent voltage count and listMatthias Kaehlcke1-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>
2016-11-04regulator: core: Add new API to poll for error conditionsAxel Haslam1-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>
2016-09-16regulator: core: Add set_voltage_time opMatthias Kaehlcke1-2/+8
The new op is analogous to set_voltage_time_sel. It can be used by regulators which don't have a table of discrete voltages. The function returns the time for the regulator output voltage to stabilize after being set to a new value, in microseconds. If the op is not set a default implementation is used to calculate the delay. This change also removes the ramp_delay calculation in the PWM regulator, since the driver now uses the core code for the calculation of the delay. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-13Merge remote-tracking branches 'regulator/topic/can-change', 'regulator/topic/constrain', 'regulator/topic/debugfs' and 'regulator/topic/doc' into regulator-nextMark Brown1-0/+5
2016-04-20regulator: core: Use a bitfield for continuous_voltage_rangeMark Brown1-1/+1
Using a bitfield enables the compiler to lay out the structure more efficiently when we have other boolean flags since multiple values can be included in a single byte. Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-23regulator: add missing description for set_over_current_protectionLuis de Bethencourt1-0/+3
Over current protection is missing descriptions for documentation. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-23regulator: add missing descriptions in regulator_descLuis de Bethencourt1-0/+2
Members csel_reg and csel_mask of the regulator_desc struct are missing descriptions for documentation. Adding them. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-02regulator: helper: Add helper to configure active-discharge using regmapLaxman Dewangan1-0/+14
Add helper function to set the state of active-discharge of regulator using regmap. The HW regulator driver can directly use this by providing the necessary information in the regulator descriptor. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-02regulator: core: Add support for active-discharge configurationLaxman Dewangan1-0/+3
Add support to enable/disable active discharge of regulator via machine constraints. This configuration is done when setting machine constraint during regulator register and if regulator driver implemented the callback ops. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-25regulator: tps65218: add support for LS3 current regulatorNikita Kiryanov1-0/+2
Add support for TPS65218 LS3 current regulator, which is capable of 4 current input limit modes: 100, 200, 500, and 1000 uA. Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-16regulator: introduce min_dropout_uVSascha Hauer1-0/+2
Many voltage Regulators need a input voltage that is higher than the output voltage. Allow to specify a minimum dropout voltage which will be used later to find the best input voltage for regulators. [Changed uv to uV for consistency and legibility -- broonie] Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-24regulator: Add over current protection (OCP) supportStephen Boyd1-0/+1
Some regulators can automatically shut down when they detect an over current event. Add an op (set_over_current_protection) and a DT property + constraint to support this capability. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-22Merge remote-tracking branches 'regulator/topic/of', 'regulator/topic/pwm', 'regulator/topic/qcom' and 'regulator/topic/soft-start' into regulator-nextMark Brown1-0/+1
2015-06-15regulator: Add docbook for soft startStephen Boyd1-0/+1
The docbook for these members is missing. Add them. Warning(include/linux/regulator/machine.h:147): No description found for parameter 'soft_start' Warning(include/linux/regulator/driver.h:197): No description found for parameter 'set_soft_start' Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-12regulator: Add input current limit supportStephen Boyd1-0/+3
Some regulators can limit their input current (typically annotated as ilim). Add an op (set_input_current_limit) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-12regulator: Add soft start supportStephen Boyd1-0/+2
Some regulators support a "soft start" feature where the voltage ramps up slowly when the regulator is enabled. Add an op (set_soft_start) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-12regulator: Add pull down supportStephen Boyd1-0/+5
Some regulators need to be configured to pull down a resistor when the regulator is disabled. Add an op (set_pull_down) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-10Merge remote-tracking branches 'regulator/topic/dbx500', 'regulator/topic/load-op', 'regulator/topic/max77693' and 'regulator/topic/max8660' into regulator-nextMark Brown1-0/+3
2015-04-10Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown1-0/+1
2015-04-01regulator: Defer lookup of supply to regulator_getBjorn Andersson1-0/+1
Instead of resolving regulator supplies during registration move this to the time of a consumer retrieving a handle. The benefit is that it's possible for one driver to register regulators with internal dependencies out of order. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-18regulator: Fix documentation for regmap in the configAxel Lin1-1/+1
dev_get_regulator() does not exist, fix the typo. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-23regulator: core: Introduce set_load opBjorn Andersson1-0/+3
Expose the requested load directly to the regulator implementation for hardware that does not support the normal enum based set_mode(). Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-01-08regulator: Allow parsing custom properties when using simplified DT parsingKrzysztof Kozlowski1-0/+13
When drivers use simplified DT parsing method (they provide 'regulator_desc.of_match') they still may want to parse custom properties for some of the regulators. For example some of the regulators support GPIO enable control. Add a driver-supplied callback for such case. This way the regulator core parses common bindings offloading a lot of code from drivers and still custom properties may be used. The callback, called for each parsed regulator, may modify the 'regulator_config' initially passed to regulator_register(). Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-12-05Merge remote-tracking branches 'regulator/topic/max77686', 'regulator/topic/max77693', 'regulator/topic/max77802', 'regulator/topic/power-off' and 'regulator/topic/rk808' into regulator-nextMark Brown1-0/+4
2014-11-26regulator: Add mode mapping function to struct regulator_descJavier Martinez Canillas1-0/+4
The "regulator-initial-mode" and "regulator-mode" DT properties allows to configure the regulator operating modes at startup or when a system enters into a susend state. But these properties use as valid values the operating modes supported by each device while the core deals with the standard operating modes. So a mapping function is needed to translate from the hardware specific modes to the standard ones. This mapping is a non-varying configuration for each regulator, so add a function pointer to struct regulator_desc that will allow drivers to define their callback to do the modes translation. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-10-20regulator: Add ena_gpio_initialized to regulator_configMarkus Pargmann1-0/+4
Most drivers do not set the ena_gpio field of struct regulator_config before passing it to the regulator core. This is fine as long as the gpio identifier that is passed is a positive integer. But the gpio identifier 0 is also valid. So we are not able to decide wether we got a real gpio identifier or not based on a 0 in ena_gpio. To be able to decide if it is a valid gpio that got passed, this patch adds a ena_gpio_initialized field that should be set if was initialized with a correct value, either a gpio >= 0 or a negative error number. The core then checks if ena_gpio or ena_gpio_initialized before handling it as a gpio. This way we maintain backwards compatibility and fix the behaviour for gpio number 0. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-09-30Merge remote-tracking branches 'regulator/topic/drivers', 'regulator/topic/enable', 'regulator/topic/fan53555', 'regulator/topic/hi6421' and 'regulator/topic/isl9305' into regulator-nextMark Brown1-1/+11
2014-09-10Merge branch 'topic/of' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-isl9305Mark Brown1-0/+4
2014-09-10regulator: of: Provide simplified DT parsing methodMark Brown1-0/+4
Currently regulator drivers which support DT all repeat very similar code to supply a list of known regulator identifiers to be matched with DT, convert that to platform data which is then matched up with the regulators as they are registered. This is both fiddly to get right and for devices which can use the standard helpers to provide their operations is the main source of code in the driver. Since this code is essentially identical for most drivers we can factor it out into the core, moving the identifiers in the match table into the regulator descriptors and also allowing drivers to pass in the name of the subnode to search. When a driver provides an of_match string for the regulator the core will attempt to use that to obtain init_data, allowing the driver to remove all explicit code for DT parsing and simply provide data instead. The current code leaks the phandles for the child nodes, this will be addressed incrementally and makes no practical difference for FDT anyway as the DT data structures are never freed. Signed-off-by: Mark Brown <broonie@linaro.org>
2014-08-28regulator: fix kernel-doc warnings in header filesRandy Dunlap1-0/+2
Fix kernel-doc warnings in regulator header files: Warning(..//include/linux/regulator/machine.h:140): No description found for parameter 'ramp_disable' Warning(..//include/linux/regulator/driver.h:279): No description found for parameter 'linear_ranges' Warning(..//include/linux/regulator/driver.h:279): No description found for parameter 'n_linear_ranges' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-08-21regulator: core: Add back the const qualifier for ops of struct regulator_descAxel Lin1-1/+1
Fix below build warning: CC [M] drivers/regulator/hi6421-regulator.o drivers/regulator/hi6421-regulator.c:356:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] This is a revert of commit 716845ebeb50 ("regulator: core: Fix build error due to const qualifier for ops"). The build error was fixed by commit 39f5460d7f9c ("regulator: core: add const to regulator_ops and fix build error in mc13892"). Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>