summaryrefslogtreecommitdiffstats
path: root/include/linux/regulator/consumer.h
Commit message (Collapse)AuthorAgeFilesLines
* regulator: add regulator_get_linear_step() stub helperArnd Bergmann2019-03-211-0/+5
| | | | | | | | | | | | | | | | | | | | The regulator header has empty inline functions for most interfaces, but not regulator_get_linear_step(), which has just grown a user that does not depend on regulators otherwise: drivers/clk/tegra/clk-tegra124-dfll-fcpu.c: In function 'get_alignment_from_regulator': drivers/clk/tegra/clk-tegra124-dfll-fcpu.c:555:19: error: implicit declaration of function 'regulator_get_linear_step'; did you mean 'regulator_get_drvdata'? [-Werror=implicit-function-declaration] align->step_uv = regulator_get_linear_step(reg); ^~~~~~~~~~~~~~~~~~~~~~~~~ regulator_get_drvdata cc1: all warnings being treated as errors scripts/Makefile.build:278: recipe for target 'drivers/clk/tegra/clk-tegra124-dfll-fcpu.o' failed Add the missing stub along the others. Fixes: b3cf8d069505 ("clk: tegra: dfll: CVB calculation alignment with the regulator") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Fix return value of _set_load() stubMark Brown2018-11-201-1/+1
| | | | | | | | | | | | The stub implementation of _set_load() returns a mode value which is within the bounds of valid return codes for success (the documentation just says that failures are negative error codes) but not sensible or what the actual implementation does. Fix it to just return 0. Reported-by: Cheng-Yi Chiang <cychiang@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Don't return or expect -errno from of_map_mode()Douglas Anderson2018-04-201-0/+1
| | | | | | | | | | | | | | | | | | | | | In of_get_regulation_constraints() we were taking the result of of_map_mode() (an unsigned int) and assigning it to an int. We were then checking whether this value was -EINVAL. Some implementers of of_map_mode() were returning -EINVAL (even though the return type of their function needed to be unsigned int) because they needed to signal an error back to of_get_regulation_constraints(). In general in the regulator framework the mode is always referred to as an unsigned int. While we could fix this to be a signed int (the highest value we store in there right now is 0x8), it's actually pretty clean to just define the regulator mode 0x0 (the lack of any bits set) as an invalid mode. Let's do that. Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and suspend modes") Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Add new notification for enabling of regulatorHarald Geyer2017-03-241-0/+1
| | | | | | | | | This is useful for devices, which need some time to start up, to help the drivers track how long the supply has been up already. Ie whether it can safely talk to the HW or needs to wait. Signed-off-by: Harald Geyer <harald@ccbib.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Fix regulator_get_error_flags() signature mismatchDavid Lechner2016-12-051-1/+2
| | | | | | | | | The function signature of does not match regulator_get_error_flags() when CONFIG_REGULATOR is not defined vs. when it is not defined. This makes both declarations match to prevent compiler errors. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Add new API to poll for error conditionsAxel Haslam2016-11-041-0/+26
| | | | | | | | | | | | 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>
* regulator: Remove support for optional supplies in the bulk APIBjorn Andersson2016-08-161-3/+0
| | | | | | | | | | The patch was based on my missinterpretation of the API and only accidentally worked for me. Let's clean it out to not confuse others. This reverts commit 3ff3f518a135fa4592fe2817e9ac2cce1fa23dc2. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Remove regulator_can_change_voltage()Mark Brown2016-06-091-6/+0
| | | | | | | | | | | | | | | | There is little obvious use case for a regualtor driver to know if it is possible to vary voltages at all by itself. If a consumer needs to limit what voltages it tries to set based on the system configuration then it will need to enumerate the possible voltages, and without that even if it is possible to change voltages that doesn't mean that constraints or other consumers will allow whatever change the driver is trying to do at a given time. It doesn't even indicate if _set_voltage() calls will work as noop _set_voltage() calls return success. There were no users of this API that weren't abusing it and now they're all gone so remove the API. Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Silence build warnings from regulator_can_change_voltage()Mark Brown2016-05-171-2/+2
| | | | | | | | | | | | | Cut down on noise for mainstream users of the API and people doing build testing by dropping the deprecated flag from regulator_can_change_voltage() as it triggers even on the EXPORT_SYMBOL_GPL() which affects all builds rather than just the remaining drivers with calls to it (for which fixes are currently pending). The function remains deprecated and is expected to be removed entirely in v4.8. Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Deprecate regulator_can_change_voltage()Mark Brown2016-03-301-2/+2
| | | | | | | | | | | | | | | | All current users of regulator_can_change_voltage() are abusing it, using it to wrap a call to regulator_set_voltage() on probe without any alternative handling for fixed voltages. Drivers should only be using regulator_set_voltage() if they need to vary voltages at runtime, fixed voltages should normally be set via machine constraints, and calling regulator_set_voltage() on a regulator which can't be varied will succeed if the current voltage is within the range requested so users shouldn't worry if they have permission to vary normally. Deprecate the API to try to stop any new users appearing while we fix the current callers. Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Make bulk API support optional suppliesBjorn Andersson2015-11-171-0/+3
| | | | | | | | Make it possible to use the bulk API with optional supplies, by allowing the consumer to marking supplies as optional in the regulator_bulk_data. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
*-. Merge remote-tracking branches 'regulator/topic/qcom-smd', ↵Mark Brown2015-08-301-0/+16
|\ \ | | | | | | | | | 'regulator/topic/qcom-spmi', 'regulator/topic/rk808', 'regulator/topic/stub' and 'regulator/topic/tol' into regulator-next
| | * regulator: core: Define regulator_set_voltage_triplet()Viresh Kumar2015-08-171-0/+10
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Voltage tolerance isn't necessarily same on both sides of the target voltage and regulator_set_voltage_tol() wouldn't be suitable in such cases. Add another routine regulator_set_voltage_triplet(), which accepts target, min and max voltages as arguments. This first tries to set the voltage between the target voltage and the upper limit, then fall back on the full range. The idea behind this is to set regulator's voltage as close to the target voltage, as possible. Based on regulator_set_voltage_tol(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
| * regulator: Add missing dummy definition for regulator_list_voltageSuzuki K. Poulose2015-07-101-0/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | Fixes a build break when CONFIG_REGULATOR is not selected. e.g, on linux-next - 07102015: drivers/clk/tegra/clk-dfll.c: In function ‘find_lut_index_for_rate’: drivers/clk/tegra/clk-dfll.c:691:3: error: implicit declaration of function ‘regulator_list_voltage’ [-Werror=implicit-function-declaration] if (regulator_list_voltage(td->vdd_reg, td->i2c_lut[i]) == uv) ^ CC drivers/clocksource/mmio.o CC fs/proc/softirqs.o cc1: some warnings being treated as errors make[3]: *** [drivers/clk/tegra/clk-dfll.o] Error 1 make[2]: *** [drivers/clk/tegra] Error 2 make[1]: *** [drivers/clk] Error 2 make[1]: *** Waiting for unfinished jobs.... This should be pushed to 4.2 as we have the issue in 4.2-rc1, just that nobody uses it without the REGULATOR(yet). Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org>
*---. Merge remote-tracking branches 'regulator/topic/mode', ↵Mark Brown2015-04-101-3/+18
|\ \ \ | | | | | | | | | | | | 'regulator/topic/notifier', 'regulator/topic/palmas', 'regulator/topic/qcom' and 'regulator/topic/stw481x' into regulator-next
| | * | regulator: core: Add devres versions of notifier registrationCharles Keepax2015-03-051-0/+16
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Add devm_regulator_register_notifier, this adds the resource against the device for the consumer supply we are registering the notifier for. There seem to be few use-cases where this wouldn't be the users intention and this ensures the notifiers will always be removed at the correct time. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | regulator: Drop temporary regulator_set_optimum_mode wrapperBjorn Andersson2015-03-091-7/+0
| | | | | | | | | | | | | | | Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | regulator: Rename regulator_set_optimum_modeBjorn Andersson2015-03-091-3/+9
| |/ | | | | | | | | | | | | | | Rename the regulator_set_optimum_mode() function regulator_set_load() to better represent what's going on. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* / regulator: core: Fix space before TABGeert Uytterhoeven2015-02-241-1/+1
|/ | | | | Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
*-. Merge remote-tracking branches 'regulator/topic/sky81452' and ↵Mark Brown2014-12-051-1/+1
|\ \ | | | | | | | | | 'regulator/topic/stub' into regulator-next
| | * regulator: Return an error from stubbed regulator_get_exclusive()Mark Brown2014-10-241-1/+1
| |/ | | | | | | | | | | | | | | The user hasn't got a regulator and shouldn't be mislead into thinking they have one; really we should probably remove this stub entirely (and may well before the next merge window). Signed-off-by: Mark Brown <broonie@kernel.org>
| |
| \
*-. \ Merge remote-tracking branches 'regulator/topic/anatop', ↵Mark Brown2014-12-051-0/+4
|\ \ \ | | |/ | |/| | | | 'regulator/topic/disable', 'regulator/topic/dummy' and 'regulator/topic/gpio' into regulator-next
| | * regulator: core: Add PRE_DISABLE notificationRichard Fitzgerald2014-11-241-0/+4
| |/ | | | | | | | | | | | | | | | | | | Add a PRE_DISABLE notification so that consumers can use a notifier to run any steps required to prepare for the regulator being switched off. Since the regulator disable can fail an abort notification is also added. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* / regulator: Include err.h from consumer.h to fix build failureGuenter Roeck2014-10-131-0/+2
|/ | | | | | | | | | | | | | | | | | | sh:sh2007_defconfig fails to build with the following error: In file included from include/linux/regulator/machine.h:18:0, from arch/sh/boards/board-sh2007.c:10: include/linux/regulator/consumer.h: In function 'regulator_get_optional': include/linux/regulator/consumer.h:271:2: error: implicit declaration of function 'ERR_PTR' include/linux/err.h: At top level: include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR' include/linux/regulator/consumer.h:271:9: note: previous implicit declaration of 'ERR_PTR' was here Since consumer.h uses ERR_PTR, it should include err.h. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)Heiko Stübner2014-08-291-0/+20
| | | | | | | | | | | In some cases we need to know when a regulator is about to be changed. Add a way for clients to be notified. Note that for set_voltage() we don't necessarily know what voltage we'll end up with, so we tell the client what the range will be so they can prepare. Signed-off-by: Heiko Stübner <heiko@sntech.de> Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie+linaro@kernel.org>
*-. Merge remote-tracking branches 'regulator/topic/da9211', ↵Mark Brown2014-08-051-0/+26
|\ \ | | | | | | | | | 'regulator/topic/getreg', 'regulator/topic/gpio' and 'regulator/topic/lp872x' into regulator-next
| | * regulator: Add missing statics and inlines for stub functionsMark Brown2014-07-291-6/+6
| | | | | | | | | | | | | | | | | | So we don't get multiple definitions. Signed-off-by: Mark Brown <broonie@linaro.org>
| | * regulator: Add helpers for low-level register accessTuomas Tynkkynen2014-07-251-0/+26
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add helper functions that allow regulator consumers to obtain low-level details about the regulator hardware, like the voltage selector register address and such. These details can be useful when configuring hardware or firmware that want to do low-level access to regulators, with no involvement from the kernel. The use-case for Tegra is a voltage-controlled oscillator clocksource which has control logic to change the supply voltage via I2C to achieve a desired output clock rate. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* | Merge remote-tracking branch 'regulator/fix/core' into regulator-linusMark Brown2014-06-161-0/+5
|\ \ | |/ |/|
| * regulator: add regulator_can_change_voltage stubArnd Bergmann2014-06-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CONFIG_REGULATOR is not set, we cannot call regulator_can_change_voltage() from a device driver, which results in a build error like video/fbdev/omap2/dss/hdmi5.c: In function 'hdmi_init_regulator': video/fbdev/omap2/dss/hdmi5.c:149:2: error: implicit declaration of function 'regulator_can_change_voltage' [-Werror=implicit-function-declaration] even for drivers that don't require the regulator API normally. Such a use was recently added in the omap2+ hdmi driver. This avoids the problem by adding a static inline function stub in the API header, as we have for most of the other regulator functions as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Mark Brown <broonie@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| |
| \
*-. \ Merge remote-tracking branches 'regulator/topic/s5m8767', ↵Mark Brown2014-06-021-0/+6
|\ \ \ | | |/ | |/| | | | 'regulator/topic/stub', 'regulator/topic/tps65090', 'regulator/topic/tps65217' and 'regulator/topic/tps65218' into regulator-next
| | * regulators: Add definition of regulator_set_voltage_time() for !CONFIG_REGULATORViresh Kumar2014-05-281-0/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already have dummy implementation for most of the regulators APIs for !CONFIG_REGULATOR case and were missing it for regulator_set_voltage_time(). Found this issue while compiling cpufreq-cpu0 driver without regulators support in kernel. drivers/cpufreq/cpufreq-cpu0.c: In function ‘cpu0_cpufreq_probe’: drivers/cpufreq/cpufreq-cpu0.c:186:3: error: implicit declaration of function ‘regulator_set_voltage_time’ [-Werror=implicit-function-declaration] Fix this by adding dummy definition for regulator_set_voltage_time(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
* | Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown2014-06-021-16/+20
|\ \
| * | regulator: Constify the pointer to alias name arrayLee Jones2014-05-231-16/+20
| |/ | | | | | | | | | | | | Toughen-up checks for read-only regulator names. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
* / regulator: core: Return error in get optional stubTim Kryger2014-04-181-2/+2
|/ | | | | | | | | | | | | Drivers that call regulator_get_optional are tolerant to the absence of that regulator. By modifying the value returned from the stub function to match that seen when a regulator isn't present, callers can wrap the regulator logic with an IS_ERR based conditional even if they happen to call regulator_is_supported_voltage. This improves efficiency as well as eliminates the possibility for a very subtle bug. Signed-off-by: Tim Kryger <tim.kryger@linaro.org> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
* regulator: core: Add ability to create a lookup alias for supplyCharles Keepax2013-10-181-0/+79
| | | | | | | | | | | | | | These patches add the ability to create an alternative device on which a lookup for a certain supply should be conducted. A common use-case for this would be devices that are logically represented as a collection of drivers within Linux but are are presented as a single device from device tree. It this case it is necessary for each sub device to locate their supply data on the main device. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* Merge remote-tracking branch 'regulator/topic/optional' into regulator-nextMark Brown2013-09-011-0/+25
|\
| * regulator: Add devm_regulator_get_exclusive()Matthias Kaehlcke2013-08-291-0/+2
| | | | | | | | | | | | | | Add a resource managed regulator_get_exclusive() Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net> Signed-off-by: Mark Brown <broonie@linaro.org>
| * regulator: core: Provide hints to the core about optional suppliesMark Brown2013-07-311-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While the majority of supplies on devices are mandatory and can't be physically omitted for electrical reasons some devices do have optional supplies and need to know if they are missing, MMC being the most common of these. Currently the core accurately reports all errors when regulators are requested since it does not know if the supply is one that must be provided even if by a regulator software does not know about or if it is one that may genuinely be disconnected. In order to allow this behaviour to be changed and stub regulators to be provided in the former case add a new regulator request function regulator_get_optional() which provides a hint to the core that the regulator may genuinely not be connected. Currently the implementation is identical to the current behaviour, future patches will add support in the core for returning stub regulators in the case where normal regulator_get() fails and the board has requested it. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Chris Ball <cjb@laptop.org>
| * regulator: core: Add missing stub for regulator_get_exclusive()Mark Brown2013-07-311-0/+7
| | | | | | | | Signed-off-by: Mark Brown <broonie@linaro.org>
* | regulator: core: Make set_voltage_tol() try for mid-range firstMark Brown2013-07-151-2/+5
|/ | | | | | | | | | | | | | | The expected semantic for something expressed as a tolerance is that it should deliver the specified value with some deviation allowed but this is not what set_voltage_tol() currently does. Instead it just passes the maximum possible range to set_voltage() which will typically result in a voltage aimed at lower than the target voltage. Instead first try to set a voltage between the target voltage and the upper limit, then fall back on the full range. This will be much more robust against physical variation in systems and makes the API behave more like users would expect. Signed-off-by: Mark Brown <broonie@linaro.org>
* regulator: core: add regulator_get_linear_step()Paul Walmsley2013-06-071-0/+1
| | | | | | | | | | | Add regulator_get_linear_step(), which returns the voltage step size between VSEL values for linear regulators. This is intended for use by regulator consumers which build their own voltage-to-VSEL tables. Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com> Reviewed-by: Andrew Chew <achew@nvidia.com> Cc: Matthew Longnecker <mlongnecker@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* regulator: core: Mark all get and enable calls as __must_checkMark Brown2013-03-041-7/+7
| | | | | | | It's generally important that devices have power when they expect it so drivers really ought to be checking for errors on the power up paths. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* Merge remote-tracking branch 'regulator/topic/tol' into regulator-nextMark Brown2012-12-101-0/+8
|\
| * regulator: core: Add regulator_is_supported_voltage_tol()Mark Brown2012-11-141-0/+8
| | | | | | | | | | | | | | | | If consumers wish to set voltages based on a tolerance it stands to reason that they will also want to query for support in the same manner. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | Merge remote-tracking branch 'regulator/topic/stub' into regulator-nextMark Brown2012-12-101-0/+4
|\ \
| * | regulator: add missing prototype for regulator_is_supported_voltagePhilip Rakity2012-11-211-0/+4
| |/ | | | | | | | | | | | | | | | | avoids needs for CONFIG_REGULATOR in sdhci.c Signed-off-by: Philip Rakity <prakity@nvidia.com> Reviewed-by: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* / regulators: add regulator_can_change_voltage() functionMarek Szyprowski2012-12-061-0/+1
|/ | | | | | | | | | Introduce a regulator_can_change_voltage() function for the subsytems or drivers which might check if applying voltage change is possible and use special workaround code when the driver is used with fixed regulators or regulators with disabled ability to change the voltage. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
*-. Merge remote-tracking branches 'regulator/topic/core', ↵Mark Brown2012-09-281-0/+15
|\ \ | | | | | | | | | 'regulator/topic/bypass', 'regulator/topic/tol', 'regulator/topic/drivers' and 'regulator/topic/tps6586x' into regulator-next
| | * regulator: add a new API regulator_set_voltage_tol()Shawn Guo2012-08-081-0/+7
| |/ |/| | | | | | | | | | | | | | | | | There are some use cases where a voltage range could be reasonably specified by a target voltage and tolerance. Add a new API regulator_set_voltage_tol() wrapping regulator_set_voltage() call to ease the users. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-01 18:38:07 +0000