| 174e964ec224c3c591b83a6b5f0984d905d3678f |
|
09-Oct-2014 |
Guenter Roeck <linux@roeck-us.net> |
regulator: Include err.h from consumer.h to fix build failure
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>
|
| 7179569aeb52197fd2a9909ba226c4c9cc0e2e2a |
|
28-Aug-2014 |
Heiko Stübner <heiko@sntech.de> |
regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
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>
|
| 3bc0312e67f0be679039980291f88405f20b0a95 |
|
25-Jul-2014 |
Mark Brown <broonie@linaro.org> |
regulator: Add missing statics and inlines for stub functions
So we don't get multiple definitions.
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| 04eca28cde52cdf9eb91e127cc358ad79a8ec53b |
|
21-Jul-2014 |
Tuomas Tynkkynen <ttynkkynen@nvidia.com> |
regulator: Add helpers for low-level register access
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>
|
| b14903e10a06347234b387f7364f86aa07252d9f |
|
04-Jun-2014 |
Arnd Bergmann <arnd@arndb.de> |
regulator: add regulator_can_change_voltage stub
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>
|
| d660e92a97aac08aa33cd41e00a325066e00f1ef |
|
27-May-2014 |
Viresh Kumar <viresh.kumar@linaro.org> |
regulators: Add definition of regulator_set_voltage_time() for !CONFIG_REGULATOR
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>
|
| 9f8c0fe9542141fd0008d5c0f6ae365890f6da94 |
|
23-May-2014 |
Lee Jones <lee.jones@linaro.org> |
regulator: Constify the pointer to alias name array
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>
|
| df7926fffa9a4c0bceb0189386b4c5edc012fcbb |
|
17-Apr-2014 |
Tim Kryger <tim.kryger@linaro.org> |
regulator: core: Return error in get optional stub
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>
|
| a06ccd9c3785fa5550917ae036944f4e080b5749 |
|
15-Oct-2013 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Add ability to create a lookup alias for supply
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>
|
| 9efdd27678ef5e22c27c230a08a211b702768f3a |
|
25-Aug-2013 |
Matthias Kaehlcke <matthias.list@kaehlcke.net> |
regulator: Add devm_regulator_get_exclusive()
Add a resource managed regulator_get_exclusive()
Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| de1dd9fd2156874b45803299b3b27e65d5defdd9 |
|
29-Jul-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Provide hints to the core about optional supplies
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>
|
| 4bdfb2729c3a396fe7400c9332c49aee2b971bd8 |
|
29-Jul-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Add missing stub for regulator_get_exclusive()
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| dc9ceed6a12aff627c81e01ada191e8a23fcbe3e |
|
04-Jul-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Make set_voltage_tol() try for mid-range first
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>
|
| 2a668a8bc2cbe7a464ab1212475a3efb23a94b1e |
|
07-Jun-2013 |
Paul Walmsley <pwalmsley@nvidia.com> |
regulator: core: add regulator_get_linear_step()
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>
|
| c8801a8e715d7793e1e7bcd2f6fe132234741753 |
|
19-Mar-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Mark all get and enable calls as __must_check
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>
|
| d1e7de3007c6e34c5e6d5e1b707b5aba4a1cd57f |
|
04-Dec-2012 |
Marek Szyprowski <m.szyprowski@samsung.com> |
regulators: add regulator_can_change_voltage() function
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>
|
| 1a8f85d402a2bf3b86c08c696a0adf36656f770a |
|
20-Nov-2012 |
Philip Rakity <prakity@nvidia.com> |
regulator: add missing prototype for regulator_is_supported_voltage
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>
|
| fe1e43f7190da98b396265639845a6cc0d748aad |
|
14-Nov-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Add regulator_is_supported_voltage_tol()
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>
|
| f59c8f9fe689790248ae7aa7426579982050638c |
|
31-Aug-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Support bypass mode
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>
|
| 3f1965776f6ec769192400810b6260fe48301bbb |
|
05-Aug-2012 |
Shawn Guo <shawn.guo@linaro.org> |
regulator: add a new API regulator_set_voltage_tol()
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>
|
| 4fe23791a4052ad4c8ba79dab9ff5febc8095714 |
|
01-Jul-2012 |
Philip Rakity <prakity@marvell.com> |
regulator: add missing defintion regulator_is_supported_voltage
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>
|
| 08aed2f6fb09c9f8efc9258c152072ed614db226 |
|
11-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: stubs: Make stub regulator_get_voltage() return an error
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>
|
| 313162d0b83836e2f57e51b9b8650fb4b9c396ea |
|
30-Jan-2012 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
device.h: audit and cleanup users in main include dir
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>
|
| 2950c4bbf397fc7d3d778a97c32bba0e955b47fe |
|
29-Jan-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: Add devm_regulator_put in consumer.h
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>
|
| e24abd6ec6c2dabccb825dc41d1725bc496b3a54 |
|
26-Jan-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: Add empty devm_regulator_bulk_get for !CONFIG_REGULATOR
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>
|
| e6e740304aa2a49ef09497e6c0bb906ed7987f6b |
|
20-Jan-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Provide devm_regulator_bulk_get()
Allow drivers to benefit from both the bulk APIs and managed resources
simultaneously.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
| d5ad34f7cb8b23ab165cabef69577a2a20d53195 |
|
20-Jan-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Implement devm_regulator_free()
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>
|
| 070b9079226d4f3e3e7c9f4eb81f2e02e7d99572 |
|
17-Jan-2012 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Add devm_regulator_get()
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>
|
| e1de2f423462a5c6ba2c902dff1f5ddd8d3dbde3 |
|
03-Jan-2012 |
Donggeun Kim <dg77.kim@samsung.com> |
regulator: add regulator_bulk_force_disable function
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>
|
| 935a521066113e16c15b842852ed681bbbdfbc63 |
|
02-Jan-2012 |
MyungJoo Ham <myungjoo.ham@samsung.com> |
regulator: add regulator_force_disable() definition for !CONFIG_REGULATOR
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>
|
| da07ecd93b196819dcec488b7ebec69a71f3819e |
|
11-Sep-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Implement deferred disable support
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>
|
| bff747c58cf97bf4fc8b499ee0f419b59d6b226d |
|
08-Sep-2011 |
Randy Dunlap <rdunlap@xenotime.net> |
regulator: fix kernel-doc warning in consumer.h
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>
|
| 84f8508a7d0357f841c2fa66b7c39d98c5b5e13e |
|
04-Aug-2011 |
Randy Dunlap <rdunlap@xenotime.net> |
regulator: fix regulator/consumer.h kernel-doc warning
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: Liam Girdwood <lrg@slimlogic.co.uk>
|
| f21e0e81d81b649ad309cedc7226f1bed72982e0 |
|
24-May-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Do bulk enables of regulators in parallel
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>
|
| 88cd222b259d62148ab8c82398498b1a01314476 |
|
17-Mar-2011 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: provide consumer interface for fall/rise time
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>
|
| 606a25628187ce863b48d43ca42bc0cbe8342de9 |
|
16-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add API to re-apply voltage to hardware
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>
|
| be1a50d4eba4cdb3ebf9d97a0a8693c153436775 |
|
03-Apr-2010 |
Jean Delvare <khali@linux-fr.org> |
regulator: Let drivers know when they use the stub API
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>
|
| 84b6826306119dc3c41ef9d7ed6c408112f63301 |
|
01-Dec-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add notifier event on regulator disable
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>
|
| b56daf13eb77ee24f48f0bb34c2492f46a432ec4 |
|
11-Nov-2009 |
Liam Girdwood <lrg@slimlogic.co.uk> |
regulator: consumer.h - fix build when consumer.h is #included first.
consumer.h requires device.h for stand alone build.
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
| a7a1ad9066e0266c8a4357ba3dbaeebfb80f531d |
|
21-Jul-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add regulator voltage range check API
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>
|
| 5ffbd136e6c51c8d1eec7a4a0c5d2180c81aea30 |
|
21-Jul-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add regulator_get_exclusive() API
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>
|
| 4367cfdc7c657ad8a797f51b9ffd3c64b31910e7 |
|
26-Feb-2009 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: enumerate voltages (v2)
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>
|
| 1dd68f01886a2d5cabbbe90b86e82f70917de89c |
|
02-Feb-2009 |
Liam Girdwood <lrg@slimlogic.co.uk> |
regulator: email - update email address and regulator webpage.
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>
|
| b136fb4463d13eea129bf090a8a465bba6bf0003 |
|
19-Jan-2009 |
Jonathan Cameron <jic23@cam.ac.uk> |
Regulator: Push lock out of _notifier_call_chain + add voltage change event.
Regulator: Push lock out of _notifier_call_chain and into caller functions
(side effect of fixing deadlock in regulator_force_disable)
+ Add a voltage changed event.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
| 69279fb9a95051971ac03e558c4d46e7ba84ab3a |
|
31-Dec-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Clean up kerneldoc warnings
Remove kerneldoc warnings that don't relate to missing documentation,
mostly by renaming parameters in the documentation to match their
actual names.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
| e2ce4eaa76214f65a3f328ec5b45c30248115768 |
|
30-Apr-2008 |
Liam Girdwood <lg@opensource.wolfsonmicro.com> |
regulator: consumer device interface
Add support to allow consumer device drivers to control their regulator
power supply.
This uses a similar API to the kernel clock interface in that consumer
drivers can get and put a regulator (like they can with clocks atm) and
get/set voltage, current limit, mode, enable and disable. This should
allow consumers complete control over their supply voltage and current
limit. This also compiles out if not in use so drivers can be reused in
systems with no regulator based power control.
Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|