11 Aug, 2010
1 commit
-
Acked-by: Linus Walleij
Acked-By: Mattias Wallin
Acked-By: Bengt JONSSON
Signed-off-by: Sundar R Iyer
Acked-by: Mark Brown
Acked-by: Samuel Ortiz
Signed-off-by: Liam Girdwood
28 Jul, 2010
1 commit
-
Acked-by: Mark Brown
In TPS6507x, depending on the status of DEFDCDC{2,3} pin either
DEFDCDC{2,3}_LOW or DEFDCDC{2,3}_HIGH register needs to be read or
programmed to change the output voltage.The current driver assumes DEFDCDC{2,3} pins are always tied low
and thus operates only on DEFDCDC{2,3}_LOW register. This need
not always be the case (as is found on OMAP-L138 EVM).Unfortunately, software cannot read the status of DEFDCDC{2,3} pins.
So, this information is passed through platform data depending on
how the board is wired.Signed-off-by: Anuj Aggarwal
Signed-off-by: Sekhar Nori
Signed-off-by: Liam Girdwood
25 May, 2010
1 commit
-
When one regulator supplies another allow the relationship to be specified
using names rather than struct regulators, in a similar manner to that
allowed for consumer supplies. This allows static configuration at compile
time, reducing the need for dynamic init code.Also change the references to LINE supply to be system supply since line
is sometimes used for actual supplies and therefore potentially confusing.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood
19 Apr, 2010
1 commit
-
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
Cc: Mark Brown
Cc: Jerome Oufella
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood
03 Mar, 2010
4 commits
-
Signed-off-by: Haojian Zhuang
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
Add a field to specify a delay for the start-up time of
a fixed voltage regulator.Signed-off-by: Adrian Hunter
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
Regulators may sometimes take longer to enable than the control operation
used to do so, either because the regulator has ramp rate control used to
limit inrush current or because the control operation is very fast (GPIO
being the most common example of this). In order to ensure that consumers
do not rely on the regulator before it is enabled provide an enable_time()
operation and have the core delay for that time before returning to the
caller.This is implemented as a function since the ramp rate may be specified in
voltage per unit time and therefore the time depend on the configuration.
In future it would be desirable to allow the bulk operations to run the
delays for multiple enables in parallel but this is not currently supported.Signed-off-by: Mark Brown
-
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
17 Dec, 2009
3 commits
-
consumer.h requires device.h for stand alone build.
Signed-off-by: Liam Girdwood
-
Since some regulators in the system may not support suspend mode
configuration we need to allow some regulators to have a missing
suspend mode configuration. Do this by requiring that disabled
regulators are explicitly flagged and then skip over regulators
that have no state specified.Try to avoid surprises by warning the if we could set the state
but no configuration is provided. This also ensures that an all
zeros configuration generates a warning rather than silently
disabling the regulator.Reported-by: Joonyoung Shim
Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
Tested with a MX25-based custom board.
Signed-off-by: Wolfram Sang
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood
22 Sep, 2009
8 commits
-
Document the possibility that is_enabled may also return with negative
errorcodes.Signed-off-by: Wolfram Sang
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
Fix a couple of typos I found while working with this subsystem.
Signed-off-by: Wolfram Sang
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
Now fixed regulators that have their enable pin connected to a GPIO line
can use the fixed regulator driver for regulator enable/disable control.
The GPIO number and polarity information is passed through platform data.
GPIO enable control is achieved using gpiolib.Signed-off-by: Roger Quadros
Reviewed-by: Philipp Zabel
Reviewed-by: Felipe Balbi
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
Simplify checking of support for voltage ranges by providing an API which
wraps the existing count and list operations.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
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
Signed-off-by: Liam Girdwood -
Signed-off-by: Haojian Zhuang
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
This allows machine drivers to build without ifdefs if they have
full constraints. Suggested by machine drivers contributed by
Haojian Zhuang .Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
Follow the approach suggested by Russell King and implemented by him in
the clkdev API and allow consumer device supply mapings to be set up
using the dev_name() for the consumer instead of the struct device.
In order to avoid making existing machines instabuggy and creating merge
issues the use of struct device is still supported for the time being.This resolves problems working with buses such as I2C which make the
struct device available late providing that the final device name is
known, which is the case for most embedded systems with fixed setups.Consumers must still use the struct device when calling regulator_get().
Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood
17 Sep, 2009
1 commit
-
This is useful for implementing get_status() in terms of get_mode().
Signed-off-by: Mark Brown
Signed-off-by: Samuel Ortiz
15 Jun, 2009
4 commits
-
The V3 regulator can be configured with an external resistor
connected to the feedback pin (R24 in the data sheet) to
increase the voltage range.For example, hx4700 has R24 = 3.32 kOhm to achieve a maximum
V3 voltage of 1.55 V which is needed for 624 MHz CPU frequency.Signed-off-by: Philipp Zabel
Acked-by: Mark Brown
Acked-by: Robert Jarzmik
Signed-off-by: Liam Girdwood -
This patch adds regulator drivers for National Semiconductors LP3971 PMIC.
This LP3971 PMIC controller has 3 DC/DC voltage converters and 5 low
drop-out (LDO) regulators. LP3971 PMIC controller uses I2C interface.Reviewed-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
The userspace-consumer driver allows control of voltage and current
regulator state from userspace. This is required for fine-grained
power management of devices that are completely controller by userspace
applications, e.g. a GPS transciever connected to a serial port.Signed-off-by: Mike Rapoport
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
The Maxim 1586 regulator is a voltage regulator with 2
voltage outputs, specially suitable for Marvell PXA
chips. One output is in the range of required VCC_CORE by
the PXA27x chips, the other in the VCC_USIM required as well
by PXA27x chips.The chip is controlled through the I2C bus.
Signed-off-by: Robert Jarzmik
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood
29 Apr, 2009
1 commit
-
Add regulator header file missing kernel-doc:
Warning(include/linux/regulator/driver.h:117): No description found for parameter 'set_mode'
Signed-off-by: Randy Dunlap
cc: Liam Girdwood
cc: Mark Brown
Signed-off-by: Liam Girdwood
31 Mar, 2009
13 commits
-
At present it is not possible for machine constraints to disable
regulators which have been left on when the system starts, for example
as a result of fixed default configurations in hardware. This means that
power may be wasted by these regulators if they are not in use.Provide intial support for this with a late_initcall which will disable
any unused regulators if the machine has enabled this feature by calling
regulator_has_full_constraints(). If this has not been called then print
a warning to encourage users to fully specify their constraints so that
we can change this to be the default behaviour in future.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
Rather than incrementing the reference count for boot_on regulators
(which prevents them being disabled later on) simply force the
regulator to be enabled when applying the constraints. Previously
boot_on was essentially equivalent to always_on.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
Add kerneldoc for the new get_status() message. Fix the existing
kerneldoc for that struct in two ways:(a) Syntax, making sure parameter descriptions immediately
follow the one-line struct description and that the first
blank lines is before any more expansive description;
(b) Presentation for a few points, to highlight the fact that
the previous "get" methods exist only to report the current
configuration, not to display actual status.Signed-off-by: David Brownell
Signed-off-by: Liam Girdwood -
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
Acked-by: Mark Brown
Signed-off-by: Liam Girdwood -
This is useful when wishing to run in a fixed operating mode that isn't
the default.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
Remove deceased email address and update to new address. Also update
website details in MAINTAINERS with correct page.Signed-off-by: Liam Girdwood
-
Fix regulator/driver.h missing kernel-doc:
Warning(linux-next-20090120//include/linux/regulator/driver.h:108): No description found for parameter 'get_status'
Signed-off-by: Randy Dunlap
cc: Liam Girdwood
cc: Mark Brown
Signed-off-by: Liam Girdwood -
Commit 872ed3fe176833f7d43748eb88010da4bbd2f983 caused regulator drivers
to take the struct regulator_dev lock themselves which requires that the
struct be visible to them. Band aid this by making the struct visible.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
Previously it was not possible to do so, making it impossible for
machines to configure the driver.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
Rather than having the regulator init data read from the platform_data
member of the struct device that is registered for the regulator make
the init data an explict argument passed in when registering. This
allows drivers to use the platform data for their own purposes if they
wish.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
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
Signed-off-by: Liam Girdwood -
Based on previous LKML discussions:
* Update docs for regulator sysfs class attributes to highlight
the fact that all current attributes are intended to be control
inputs, including notably "state" and "opmode" which previously
implied otherwise.* Define a new regulator driver get_status() method, which is the
first method reporting regulator outputs instead of inputs.
It can report on/off and error status; or instead of simply
"on", report the actual operating mode.For the moment, this is a sysfs-only interface, not accessible to
regulator clients. Such clients can use the current notification
interfaces to detect errors, if the regulator reports them.Signed-off-by: David Brownell
Signed-off-by: Liam Girdwood
09 Jan, 2009
2 commits
-
Fix kernel-doc warnings in regulator/driver.h:
Warning(linux-next-20090108//include/linux/regulator/driver.h:95): Excess struct/union/enum/typedef member 'set_current' description in 'regulator_ops'
Warning(linux-next-20090108//include/linux/regulator/driver.h:95): Excess struct/union/enum/typedef member 'get_current' description in 'regulator_ops'
Warning(linux-next-20090108//include/linux/regulator/driver.h:124): No description found for parameter 'irq'Signed-off-by: Randy Dunlap
cc: Liam Girdwood
cc: Mark Brown
Signed-off-by: Liam Girdwood -
This is only the documentation that the kerneldoc system warns about.
Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood