summaryrefslogtreecommitdiffstats
path: root/include/linux/regulator/consumer.h
Commit message (Collapse)AuthorAgeFilesLines
*-. 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>
| * regulator: core: Support bypass modeMark Brown2012-09-101-0/+8
|/ | | | | | | | | | | | | | | | | | Many regulators support a bypass mode where they simply switch their input supply to the output. This is mainly used in low power retention states where power consumption is extremely low so higher voltage or less clean supplies can be used. Support this by providing ops for the drivers and a consumer API which allows the device to be put into bypass mode if all consumers enable it and the machine enables permission for this. This is not supported as a mode since the existing modes are rarely used due to fuzzy definition and mostly redundant with modern hardware which is able to respond promptly to load changes. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Graeme Gregory <gg@slimlogic.co.uk>
* regulator: add missing defintion regulator_is_supported_voltagePhilip Rakity2012-07-011-0/+6
| | | | | | | | | | | This definition is missing when CONFIG_REGULATOR is not defined. This causes compiler errors when compiling sdhci.c. This can be worked around by adding #ifdef CONFIG_REGULATOR .. #endif but since other definitions are there we have defined the missing definition Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* regulator: stubs: Make stub regulator_get_voltage() return an errorMark Brown2012-06-181-1/+1
| | | | | | | | Returning 0 isn't useful, it's not even meaningful if there is a real regulator there. Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* Merge tag 'device-for-3.4' of ↵Linus Torvalds2012-03-241-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux Pull <linux/device.h> avoidance patches from Paul Gortmaker: "Nearly every subsystem has some kind of header with a proto like: void foo(struct device *dev); and yet there is no reason for most of these guys to care about the sub fields within the device struct. This allows us to significantly reduce the scope of headers including headers. For this instance, a reduction of about 40% is achieved by replacing the include with the simple fact that the device is some kind of a struct. Unlike the much larger module.h cleanup, this one is simply two commits. One to fix the implicit <linux/device.h> users, and then one to delete the device.h includes from the linux/include/ dir wherever possible." * tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: device.h: audit and cleanup users in main include dir device.h: cleanup users outside of linux/include (C files)
| * device.h: audit and cleanup users in main include dirPaul Gortmaker2012-03-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The <linux/device.h> header includes a lot of stuff, and it in turn gets a lot of use just for the basic "struct device" which appears so often. Clean up the users as follows: 1) For those headers only needing "struct device" as a pointer in fcn args, replace the include with exactly that. 2) For headers not really using anything from device.h, simply delete the include altogether. 3) For headers relying on getting device.h implicitly before being included themselves, now explicitly include device.h 4) For files in which doing #1 or #2 uncovers an implicit dependency on some other header, fix by explicitly adding the required header(s). Any C files that were implicitly relying on device.h to be present have already been dealt with in advance. Total removals from #1 and #2: 51. Total additions coming from #3: 9. Total other implicit dependencies from #4: 7. As of 3.3-rc1, there were 110, so a net removal of 42 gives about a 38% reduction in device.h presence in include/* Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* | regulator: Add devm_regulator_put in consumer.hAxel Lin2012-01-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | Commit d5ad34f7cb "regulator: Implement devm_regulator_free()" actually implements devm_regulator_put. Thus rename devm_regulator_free to devm_regulator_put. Also add empty devm_regulator_put for !CONFIG_REGULATOR Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | regulator: Add empty devm_regulator_bulk_get for !CONFIG_REGULATORAxel Lin2012-01-271-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes below build error if CONFIG_REGULATOR is disabled. CC sound/soc/codecs/wm5100.o sound/soc/codecs/wm5100.c: In function ‘wm5100_i2c_probe’: sound/soc/codecs/wm5100.c:2462: error: implicit declaration of function ‘devm_regulator_bulk_get’ make[3]: *** [sound/soc/codecs/wm5100.o] Error 1 make[2]: *** [sound/soc/codecs] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | regulator: Provide devm_regulator_bulk_get()Mark Brown2012-01-221-0/+2
| | | | | | | | | | | | | | Allow drivers to benefit from both the bulk APIs and managed resources simultaneously. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | regulator: Implement devm_regulator_free()Mark Brown2012-01-221-0/+1
| | | | | | | | | | | | | | Allow consumers to free regulators allocated using devm_regulator_get() if they need to. This will not normally be required. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | regulator: Add devm_regulator_get()Stephen Boyd2012-01-201-0/+9
|/ | | | | | | | | | | | Add a resource managed regulator_get() to simplify regulator usage in drivers. This allows driver authors to "get and forget" about their regulators by automatically calling regulator_put() when the driver is detached. [Fixed up a couple of coding style issues -- broonie] Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* regulator: add regulator_bulk_force_disable functionDonggeun Kim2012-01-031-0/+8
| | | | | | | | | | This patch allows consumers to forcibly disable multiple regulator clients in a single API call. Signed-off-by: Donggeun Kim <dg77.kim@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* regulator: add regulator_force_disable() definition for !CONFIG_REGULATORMyungJoo Ham2012-01-021-0/+5
| | | | | | | | | regulator_force_disable() was omitted in consumer.h for !CONFIG_REGULATOR case. Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* Merge branch 'for-linus' of ↵Linus Torvalds2011-10-281-0/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (549 commits) ALSA: hda - Fix ADC input-amp handling for Cx20549 codec ALSA: hda - Keep EAPD turned on for old Conexant chips ALSA: hda/realtek - Fix missing volume controls with ALC260 ASoC: wm8940: Properly set codec->dapm.bias_level ALSA: hda - Fix pin-config for ASUS W90V ALSA: hda - Fix surround/CLFE headphone and speaker pins order ALSA: hda - Fix typo ALSA: Update the sound git tree URL ALSA: HDA: Add new revision for ALC662 ASoC: max98095: Convert codec->hw_write to snd_soc_write ASoC: keep pointer to resource so it can be freed ASoC: sgtl5000: Fix wrong mask in some snd_soc_update_bits calls ASoC: wm8996: Fix wrong mask for setting WM8996_AIF_CLOCKING_2 ASoC: da7210: Add support for line out and DAC ASoC: da7210: Add support for DAPM ALSA: hda/realtek - Fix DAC assignments of multiple speakers ASoC: Use SGTL5000_LINREG_VDDD_MASK instead of hardcoded mask value ASoC: Set sgtl5000->ldo in ldo_regulator_register ASoC: wm8996: Use SND_SOC_DAPM_AIF_OUT for AIF2 Capture ASoC: wm8994: Use SND_SOC_DAPM_AIF_OUT for AIF3 Capture ...
| * regulator: Implement deferred disable supportMark Brown2011-09-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is a reasonably common pattern for hardware to require some delay after being quiesced before the disable has finalised, especially in mixed signal devices. For example, an active discharge may be required to ensure that the circuit starts up again in a known state. Avoid having to implement such delays in the regulator API by providing regulator_deferred_disable() which will do a regulator_disable() a specified number of milliseconds after it is called. Due to the reference counting done on regulators a deferred disable can be cancelled by doing another regulator_enable(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | regulator: fix kernel-doc warning in consumer.hRandy Dunlap2011-09-081-1/+1
|/ | | | | | | | | | | Fix kernel-doc warning about internal/private data by marking it as "private:" so that kernel-doc will ignore it. Warning(include/linux/regulator/consumer.h:128): No description found for parameter 'ret' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* regulator: Do bulk enables of regulators in parallelMark Brown2011-05-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | In order to reduce the impact of ramp times rather than enabling the regulators for a device in series use async tasks to run the actual enables. This means that the delays which the enables implement can all run in parallel, though it does mean that the order in which the supplies come on may be unstable. For super bonus fun points if any of the regulators are shared between multiple supplies on the same device (as is rather likely) then this will test our locking. Note that in this case we only delay once for each physical regulator so the threads shouldn't block each other while delaying. It'd be even nicer if we could coalesce writes to a shared enable registers in PMICs but that's definitely future work, and it may also be useful and is certainly more achievable to optimise out the parallelism if none of the regulators implement ramp delays. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
* regulator: provide consumer interface for fall/rise timeLinus Walleij2011-03-261-0/+2
| | | | | | | | | | This exposes the functionality for rise/fall fime when setting voltage to the consumers. Cc: Bengt Jonsson <bengt.g.jonsson@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
* regulator: Add API to re-apply voltage to hardwareMark Brown2011-01-121-0/+1
| | | | | | | | | | | When cooperating with an external control source the regulator setup may be changed underneath the API. Currently consumers can just redo the regulator_set_voltage() to restore a previously set configuration but provide an explicit API for doing this as optimsations in the regulator_set_voltage() implementation will shortly prevent that. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
* regulator: Let drivers know when they use the stub APIJean Delvare2010-04-191-2/+6
| | | | | | | | | | | Have the stub variant of regulator_get() return NULL, so that drivers can (but still don't have to) handle this case specifically. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Jerome Oufella <jerome.oufella@savoirfairelinux.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
* regulator: Add notifier event on regulator disableMark Brown2010-03-031-1/+3
| | | | | | | | | | | The intended use case is for drivers which disable regulators to save power but need to do some work to restore the hardware state when restarting. If the supplies are not actually disabled due to board limits or sharing with other active devices this notifier allows the driver to avoid unneeded reinitialisation, particularly when used with runtime PM. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* regulator: consumer.h - fix build when consumer.h is #included first.Liam Girdwood2009-12-171-0/+2
| | | | | | consumer.h requires device.h for stand alone build. Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
* regulator: Add regulator voltage range check APIMark Brown2009-09-221-0/+2
| | | | | | | | Simplify checking of support for voltage ranges by providing an API which wraps the existing count and list operations. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
* regulator: Add regulator_get_exclusive() APIMark Brown2009-09-221-0/+2
| | | | | | | | | | | | | | | | | | | | | Some consumers require complete control of the regulator and can't tolerate sharing it with other consumers, most commonly because they need to have the regulator actually disabled so can't have other consumers forcing it on. This new regulator_get_exclusive() API call allows these consumers to explicitly request this, documenting the assumptions that they are making. In order to simplify coding of such consumers the use count for regulators they request is forced to match the enabled state of the regulator when it is requested. This is not possible for consumers which can share regulators due to the need to keep track of the ownership of use counts. A new API call is used rather than an additional argument to the existing regulator_get() in order to avoid merge headaches with driver code in other trees. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
* regulator: enumerate voltages (v2)David Brownell2009-03-311-0/+2
| | | | | | | | | | | | | | | | | | | Add a basic mechanism for regulators to report the discrete voltages they support: list_voltage() enumerates them using selectors numbered from 0 to an upper bound. Use those methods to force machine-level constraints into bounds. (Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board constraints for that rail are 2.0V to 3.6V ... so the range of voltages is then 2.4V to 3.3V on this board.) Export those voltages to the regulator consumer interface, so for example regulator hooked up to an MMC/SD/SDIO slot can report the actual voltage options available to cards connected there. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
* regulator: email - update email address and regulator webpage.Liam Girdwood2009-03-311-1/+1
| | | | | | | Remove deceased email address and update to new address. Also update website details in MAINTAINERS with correct page. Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
OpenPOWER on IntegriCloud