If we fall through it means that we hit an unknown regulator/chip
combination so set -ENOENT as an explicit flag (the return code
is only used internally).
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
'static const int const' means the same thing as 'static const int'
and sparse complains about this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <jy0922.shim@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Some of the regulator API functions have code to allow the machine
constraints to override the device supplied name for the regulator
in the constraints in order to help tie logging to supplies on the
board and disambiguate when there is more than one regulator chip
in the system. Factor this code out into a new rdev_get_name()
function and use it throughout the regulator API so that we always
use the same name.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
When voltage or current constraints are either missing or specify
a range display the actual setting along with the constraints if
we can. This can aid debugging of configuration problems.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
It makes sense to do all the voltage configuration in the one split
out function.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This allows constraints to take effect on regulators that support
voltage setting but for which the board does not specify a voltage
range (for example, because it is fixed correctly at system startup).
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
If we're going to log an error we may as well log what the error
code that we're failing on is.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Hi Liam,
Since Samuel merged a new version of mfd 88pm8607 driver, I format a
new patch on regulator 88pm8607. I paste the new patch in mail. Please
help to review again. And I also attach the mfd driver in mail.
From: Haojian Zhuang <haojian.zhuang@marvell.com>
Date: Thu, 8 Oct 2009 09:36:53 -0400
Subject: [PATCH] regulator: Add 88PM8607 PMIC driver
This patch adds regulator drivers for Marvell 88PM8607 PMIC.
This controller contains 3 DVC and 14 LDO regulators. This controller
uses I2C interface.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The BuckWise DC-DC convertors in WM831x devices support switching to
a second output voltage using the logic level on one of the device
pins. This is intended to allow rapid voltage switching for uses like
cpufreq, replacing the I2C or SPI write used to configure the voltage
of the regulator with a much faster GPIO status change.
This is implemented by keeping the DVS voltage configured as the
maximum voltage permitted for the regulator. If a request is made
for the maximum voltage then the GPIO is used to switch to the DVS
voltage, otherwise the normal ON voltage is updated and used. This
follows the idiom used by most cpufreq drivers, which drop the
minimum voltage as the core frequency is dropped but use a constant
maximum - raising the voltage should normally be fast, but lowering
it may be slower.
Configuration of the DVS MFP on the device should be done externally,
for example via OTP.
Support is present in the hardware for monitoring the status of the
transition using a second GPIO. This is not currently implemented
but platform data is provided for it - the driver currently assumes
that the device will be configured to transition immediately - but
platform data is provided to reduce merge issues once it is.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Tested with a MX25-based custom board.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This patch updates the regulator driver to add support
for TWL6030 PMIC specific LDO regulators.
SMPS resources are not yet supported for TWL6030 and
also .set_mode and .get_status for LDO's are yet to
be implemented for TWL6030.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This patch renames all twl4030_ functions to twl so that regulator driver
can be reused by Triton - TWL4030 and Phoenix - TWL6030.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This patch renames function names like twl4030_i2c_write_u8,
twl4030_i2c_read_u8 to twl_i2c_write_u8, twl_i2c_read_u8
and also common variable in twl-core.c
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The upcoming TWL6030 is companion chip for OMAP4 like the current TWL4030
for OMAP3. The common modules like RTC, Regulator creates opportunity
to re-use the most of the code from twl4030.
This patch renames few common drivers twl4030* files to twl* to enable
the code re-use.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Bring the WM8350 IRQ API more in line with the generic IRQ API by
masking and unmasking interrupts as they are requested and freed.
This is mostly just a case of deleting the mask and unmask calls
from the individual drivers.
The RTC driver is changed to mask the periodic IRQ after requesting
it rather than only unmasking the alarm IRQ. If the periodic IRQ
fires in the period where it is reqested then there will be a
spurious notification but there should be no serious consequences
from this.
The CODEC drive is changed to explicitly disable headphone jack
detection prior to requesting the IRQs. This will avoid the IRQ
firing with no jack set up.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is done as simple code transformation, the semantics of the
IRQ API provided by the core are are still very different to those
of genirq (mainly with regard to masking).
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Currently the pcf50633-regulator driver data is set to the pcf50633 core
structure, but the pcf50633-regulator remove handler assumes that it is set to
the regulator device. This patch fixes the issue by accessing the pcf506533
core structure through its parent device and setting the driver data to the
regulator device.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The version that made it into mainline missed the initialisation of the
chip handle.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Don't dereference drvdata after it has been freed.
regards,
dan carpenter
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
If ret is unsigned, the checks for negative wm831x_reg_read() return values
are wrong. The error value should be transmitted to its caller, e.g.
wm831x_gp_ldo_get_status() which tests for a negative return value.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Specifying 'default n' is superfluous.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
For val to be greater than 7 or less than 20 is logically always true.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This makes _regulator_enable() properly handle the case where
a regulator is already on when you try to enable it. Currently
it will erroneously handle positive return values as an error.
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Fixes the following errors on both tps650xx regulator drivers :-
drivers/regulator/tps65023-regulator: struct i2c_device_id is 32 bytes. The last of 1 is:
0x74 0x70 0x73 0x36 0x35 0x30 0x32 0x33 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
FATAL: drivers/regulator/tps65023-regulator: struct i2c_device_id is not terminated with a NULL entry!
This patch also fixes the GPL v2 licence string for both drivers.
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Adding TPS65023 and TPS6507x regulator driver support in
drivers/regulator/Makefile and drivers/regulator/Kconfig
Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Adding support for TI TPS6507x regulator driver
Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Adding support for TI TPS65023 regulator driver
Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
and avoid introducing our own loops for creating
several sysfs entries.
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <ext-roger.quadros@nokia.com>
Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>
Reviewed-by: Felipe Balbi <felipe.balbi@nokia.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This patch implements list_voltage for the pcf50644 regulator driver.
As the voltages are linearly scaled the code to convert register values to
voltages can be reused and most of the code can be shared with get_voltage.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The regulator_enable() code wasn't actually checking that the
machine constraints had given permission to enable the regulator.
Add code to do that, but only if the regulator is not already on
due to something like always_on or being left on at startup since
in those cases there's no physical change being introduced and the
constraint wouldn't make any sense.
Also add matching code for disable(). We need to do less there since
either regulator_enable() should have succeeded first or the board
setup makes no sense.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Allows use by more of the internal regulator API code.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Report errors to the user and try harder to clean up if we're not
able to probe.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The patch to add support for looking up consumers by device name
had the side effect of causing us to require a device which is
at best premature since at least cpufreq still operates outside
the device model. Remove that requirement.
Reported-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
We're probably going to start oopsing fairly soon after this happens.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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>
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>
Make da903x driver to list voltage and count voltage.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
In PXA3xx SoC family, V_CORE power doamin is supplied by BUCK1 that is
controller by ADTV1 or ADTV2 register.
By default, v1 and v2 has the same copy. If v1 or v2 is updated, the last
value that is written to either register takes effect. It means that v1
and v2 has different copy. And the actual voltage output is determinated
by last update on either register.
DA9034/35 is binded with PXA3xx SoC family. While SoC is scaling OP or
entering/exiting lower power mode, SoC needs to change voltage of V_CORE
power doamin. In order to be efficient, POWER I2C (hardcode) mode could
be enabled in SoC. In this mode, SoC will control v2 register directly.
In original DA903x driver, software will only read regulator data from v1
register. But SoC controls v2 register directly. It results that v1 and v2
isn't synchronized. Wrong data will be read from v1 register. So access v2
register in da903x driver instead.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Support the operation of DA9030 BUCK2 in da903x driver.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Acked-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
BUCK3 is the new component in DA9035. So there're three BUCKs in DA9035.
And there're two BUCKs in DA9034.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This makes it easier to read the logs when doing testing.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The core will no longer complain so we should log an error here.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Ensure that reg is within the bounds of array wm8350->pmic.pdev[].
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This sets the number of voltages for the AB3100 regulators so that
they play well with the voltage listing functions and can be used
properly with the MMC regulator integration glue for example.
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This adds support for the regulators found in the AB3100
Mixed-Signal IC.
It further also defines platform data for the ST-Ericsson
U300 platform and extends the AB3100 MFD driver so that
platform/board data with regulation constraints and an init
function can be passed down all the way from the board to
the regulators.
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This driver provides basic support for the voltage regulators
integrated into the Freescale MC13783 PMIC. It is currently
only possible to enable/disable outputs, not to actually
set the voltage.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Right now the pcap core driver passes a reference to its pcap data abusing the
subdrivers platform drvdata, this is not good.
Get the reference directly from the parent device.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Register pcap-regulator earlier so it can be used with cpufreq
Signed-off-by: Daniel Ribeiro <drwyrm@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The WM831x series of PMICs provide two constant current sinks
designed to drive strings of serially connected LEDs for applications
such as backlights. This driver adds support for those regulators.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The WM831x series of PMICs include a single DC-DC boost convertor.
This adds basic support for this convertor.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The WM831x series of PMICs provide two optional outputs for
controlling external devices during power sequencing, for example
an external regulator. While in essence these are GPIOs the
hardware presents them as DCDCs with very little control so
provide support via the regulator API in that fashion.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The WM831x series of devices provide three types of LDO:
- General purpose LDOs supporting voltages from 0.9-3.3V
- High performance analogue LDOs supporting voltages from 1-3.5V
- Very low power consumption LDOs intended to support always on
functionality.
This patch adds support for all three kinds of LDO. Each regulator
is probed as an individual platform device with resources used to
provide the register map location of the regulator. Mixed hardware
and software control of regulators is not current supported.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The WM831x series of devices all have 3 DC-DC buck convertors. This
driver implements software control for these regulators via the
regulator API. Use with split hardware/software control of individual
regulators is not supported, though regulators not controlled by
software may be controlled via the hardware control interfaces.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is useful for implementing get_status() in terms of get_mode().
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Add (partial) support for the voltage regulators on the PCAP2 PMIC.
Signed-off-by: Daniel Ribeiro <drwyrm@gmail.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
On Thu, May 28, 2009 at 10:59 AM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, May 28, 2009 at 07:15:16AM +0200, Philipp Zabel wrote:
>> 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 <philipp.zabel@gmail.com>
>
> Looks good.
>
> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Thanks, but it turns out I hit a 32 bit integer overflow in
the gain calculation. I'd like to mend that with the following
patch. Now max_uV could be increased up to 4.294 V, enough to
charge LiPo cells.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <philipp.zabel@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
lp3971_i2c_remove' referenced in section `.data' of drivers/built-in.o:
defined in discarded section `.devexit.text' of drivers/built-in.o
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Several of the regulator drivers didn't have MODULE_ALIAS so couldn't be
auto loaded. Add the MODULE_ALIAS in case they do get built as modules.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Regulators need to be available early in init in order to allow them
to be available for consumers when requested. This is generally done
by registering them at subsys_initcall() time but not all regulator
drivers have done that. Convert these drivers to do so in order to
mimimise future support.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This patch fixes the follwing build failure on powerpc:-
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> drivers/regulator/userspace-consumer.c:43: error: conflicting types
> for 'show_state'
> include/linux/sched.h:273: note: previous definition of 'show_state'
> was here
>
> Caused by commit 5defa2bce704ca4151cfe24e4297aa7797cafd22 ("regulator:
> add userspace-consumer driver") which I have reverted for today.
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <mike@compulab.co.il>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <robert.jarzmik@free.fr>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Liam Girdwood <lrg@slimlogic.co.uk>
CC: Mike Rapoport <mike@compulab.co.il>
CC: Eric Miao <eric.miao@marvell.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Default voltage constraints were being provided for fixed voltage
regulator where board constraints were not provided but these constraints
used INT_MIN as the default minimum voltage which is not a valid value
since it is less than zero. Use 1uV instead.
Also set the default values we set in the constraints themselves since
otherwise the max_uV constraint we determine will not be stored in the
actual constraint strucutre and will therefore not be used.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This seems to be fallout from last October's regulator core rework.
It got noticed only because of recent regulator framework changes.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
During regulator registration, any error after device_register() will
cause a double-free on the struct regulator_dev 'rdev'. The bug is in
drivers/regulator/core.c:regulator_register():
...
scrub:
device_unregister(&rdev->dev);
clean:
kfree(rdev); <---
rdev = ERR_PTR(ret);
goto out;
...
device_unregister() calls regulator_dev_release() which frees rdev. The
subsequent kfree corrupts memory and causes some OMAP3 systems to oops on
boot in regulator_get().
Applies against 2.6.30-rc3.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
When regulator_desc->type is something different from REGULATOR_VOLTAGE or REGULATOR_CURRENT
the if should probably return ERR_PTR(-EINVAL)
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
@@ expression E; constant C; @@
(
- !E == C
+ E != C
)
Signed-off-by: Diego Liziero <diegoliz@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
I removed the extra semi-colon and indented the return statement.
The unreachable code was found by smatch (http://repo.or.cz/w/smatch.git).
The patch was compile tested.
regards,
dan carpenter
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Don't set use_count for regulators that are enabled at boot since this
stops the supply being disabled by well-behaved consumers which do
balanced enables and disabled. Any consumers which don't do disables
which are not matched by enables are unable to share regulators - shared
regulators are the common case so the API should facilitate them.
Consumers that want to disable regulators that are enabled when they
start have two options:
- Do a regulator_enable() prior to the disable to bring the use count
in sync with the hardware state; this will ensure that if the
regulator was enabled by another driver then this consumer will play
nicely with it.
- Use regulator_force_disable(); this explicitly bypasses any checks
done by the core and documents the inability of the driver to share
the supply.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Add VPLL2 to the set of twl4030-family regulators exposed for
use by various drivers. It's commonly used to power the digital
video outputs (e.g. LCD or DVI displays) on OMAP3 systems.
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>
Fix some refcounting issues in the regulator framework, supporting
regulator_disable() for regulators that were enabled at boot time
via machine constraints:
- Update those regulators' usecounts after enabling, so they
can cleanly be disabled at that level.
- Remove the problematic per-consumer usecount, so there's
only one level of enable/disable.
Buggy consumers could notice different bug symptoms. The main
example would be refcounting bugs; also, any (out-of-tree) users
of the experimental regulator_set_optimum_mode() stuff which
don't call it when they're done using a regulator.
This is a net minor codeshrink.
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>
The consumer can print a message if required, some consumers may have
optional regulators and wish to downgrade the logging for them or ignore
their absence.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Implement the recently added voltage step listing API for the WM835x
DCDCs and LDOs. DCDCs can use values up to 0x66, LDOs can use the full
range of values in the mask. Both masks are the lower bits of the
register.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The VAUX4 voltage table scrolls onto a second page in many versions
of the TWL4030 family manuals. This doesn't mean we should ignore
those values! Some boards use the (fully supported) 2.8V setting.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Specifying voltage constraints is optional (and only needed if the
consumer is allowed to change the voltage) so don't complain unless
a voltage has been specified.
Also avoid surprises with a dangling else while we're here.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Update previously-posted twl4030 regulator driver to export
supported voltages to upper layers using a new mechanism.
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>
Support most of the LDO regulators in the twl4030 family chips.
In the case of LDOs supporting MMC/SD, the voltage controls are
used; but in most other cases, the regulator framework is only
used to enable/disable a supplies, conserving power when a given
voltage rail is not needed.
The drivers/mfd/twl4030-core.c code already sets up the various
regulators according to board-specific configuration, and knows
that some chips don't provide the full set of voltage rails.
The omitted regulators are intended to be under hardware control,
such as during the hardware-mediated system powerup, powerdown,
and suspend states. Unless/until software hooks are known to
be safe, they won't be exported here.
These regulators implement the new get_status() operation, but
can't realistically implement get_mode(); the status output is
effectively the result of a vote, with the relevant hardware
inputs not exposed.
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>
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>
The WM835x regulators need a different register checking for force
mode on each DCDC. Previously the force mode status for DCDC1 was
checked.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This is useful when wishing to run in a fixed operating mode that isn't
the default.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Update the documentation to suggest the use of datasheet names for
the supplies requested by regulator consumers. Doing this makes it
easier to tie the design for a given platform up with the requirements
of the driver for a consumer.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Currently regulator_unregister does not clear regulator <--> consumer
mapping.
This patch introduces unset_regulator_supplies that clear the map.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This allows users to enable or disable support for these regulators at
build time as they can for other regulators rather than having platforms
force the regulators to be built in.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Previously it was not possible to do so, making it impossible for
machines to configure the driver.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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>
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 <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Minor cleanup to the regulator set_mode sysfs support:
switch to sysfs_streq() in set_mode(), which is also
a code shrink. Use the same strings that get_mode()
uses, shrinking data too.
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>
This workaround was needed when regulator/ was not linked before both
power/ and usb/otg/ in drivers/Makefile. Now that it is even linked
before mfd/, this patch makes sure that bq24022 isn't probed before the
GPIO expander is set up.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
A pointer to wm8400_regulator_probe is passed to the core via
platform_driver_register and so the function must not disappear when the
.init sections are discarded. Otherwise (if also having HOTPLUG=y)
unbinding and binding a device to the driver via sysfs will result in an
oops as does a device being registered late.
An alternative to this patch is using platform_driver_probe instead of
platform_driver_register plus removing the pointer to the probe function
from the struct platform_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Changes from V1:
- Removed support for suspend_enable & suspend_disable functions.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
Cc: Andy Green <andy@openmoko.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
* 'for-linus' of git://git.o-hand.com/linux-rpurdie-leds:
leds: ledtrig-timer - on deactivation hardware blinking should be disabled
leds: Add suspend/resume to the core class
leds: Add WM8350 LED driver
leds: leds-pcs9532 - Move i2c work to a workqueque
leds: leds-pca9532 - fix memory leak and properly handle errors
leds: Fix wrong loop direction on removal in leds-ams-delta
leds: fix Cobalt Raq LED dependency
leds: Fix sparse warning in leds-ams-delta
leds: Fixup kdoc comment to match parameter names
leds: Make header variable naming consistent
leds: eds-pca9532: mark pca9532_event() static
leds: ALIX.2 LEDs driver
Prevent registration of duplicate "struct regulator" names.
They'd be unavailable, and clearly indicate something wrong.
[Edited to remove check for NULL consumer device until we have a
solution for things like cpufreq -- broonie]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
There are some minor textual changes in here as well, mostly to enable()
and disable() but the primary goal of these changes is to fix
misrenderings of the kerneldoc documentation for the regulator API.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This is only the documentation that the kerneldoc system warns about.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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>
Some of the internal structures have no kerneldoc but the ** at the start
of the comment marking them for documentation. Remove the annotation
until some is added.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Clean up the sysfs interface to regulators by only exposing the
attributes that can be properly displayed. For example: when a
particular regulator method is needed to display the value, only
create that attribute when that method exists.
This cleaned-up interface is much more comprehensible. Most
regulators only support a subset of the possible methods, so
often more than half the attributes would be meaningless. Many
"not defined" values are no longer necessary. (But handling
of out-of-range values still looks a bit iffy.)
Documentation is updated to reflect that few of the attributes
are *always* present, and to briefly explain why a regulator may
not have a given attribute.
This adds object code, about a dozen bytes more than was removed
by the preceding patch, but saves a bunch of per-regulator data
associated with the now-removed attributes. So there's a net
reduction in memory footprint.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Shrink regulator core by removing duplication in attribute printing
and probe() cleanup paths. Saves about 340 bytes (object) on ARM.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Minor bugfixes in handling of regulator modes:
- have the routine verifying regulator modes check against
the set of legal modes (!);
- have regulator_set_optimum_mode() verify the return value
of regulator_ops.get_optimum_mode(), like drms_uA_update();
- one call to regulator_ops.set_mode() treated zero as a
failure code; make this consistent with other callers.
Both regulator_set_mode() and regulator_set_optimum_mode() now
require valid_ops_mask to include REGULATOR_CHANGE_MODE; that
seems like a bugfix too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Make the <linux/regulator.h> framework treat enable/disable call
pairs like the <linux/clk.h> and <linux/interrupt.h> frameworks do:
they're refcounted, so that different parts of a driver don't need
to put work into coordination that frameworks normally handle.
It's a minor object code shrink.
It also makes the regulator_is_disabled() kerneldoc say what it's
actually returning: return value is not a refcount, and may report
an error (e.g. I/O error from I2C).
It also fixes some minor regulator_put() goofage: removing unlocked
access to the enable state. (But still not making regulator put/get
match the refcounting pattern they invoke.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".
To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.
We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.
We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Thanks,
Kay
From: Kay Sievers <kay.sievers@vrfy.org>
Subject: regulator: struct device - replace bus_id with dev_name(), dev_set_name()
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The voltage and current regulators on the WM8350 AudioPlus PMIC can be
used in concert to provide a power efficient LED driver. This driver
implements support for this within the standard LED class.
Platform initialisation code should configure the LED hardware in the
init callback provided by the WM8350 core driver. The callback should
use wm8350_isink_set_flash(), wm8350_dcdc25_set_mode() and
wm8350_dcdc_set_slot() to configure the operating parameters of the
regulators for their hardware and then then use wm8350_register_led() to
instantiate the LED driver.
This driver was originally written by Liam Girdwood, though it has been
extensively modified since then.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Some WM8350 variants have fewer DCDCs and ISINKs. Identify these at
probe and refuse to use the absent DCDCs when running on these chips.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
Use menuconfig instead of flat configs so that you can disable/enable
regulator items with one selection. Also, use depends instead of
reverse selections to make life easier, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Changes the device registration part of the probe function to supply the
regulator device rather than its parent (the mfd device) as this caused
problems when the regulator core attempted to find constraints associated
with the regulators.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The WM8350 features six DCDC convertors (four buck and two boost), four
LDO voltage regulators and two constant current sinks. This driver adds
support for these through the regulator API.
This driver was written by Liam Girdwood with updates for submission
from Mark Brown.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Provide a new file 'name' in the regulator sysfs class with a human
readable name for the regulator for use in applications.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The WM8400 provides two programmable DCDC step-down (buck) convertors
and four low-dropout (LDO) regulators. This driver provides support for
runtime managment of these in the standard regulator API.
Support for configuration of the suspend and hibernate mode behaviour
of the regulators is not yet included.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
If the machine constraints mark a regulator as always_on but this was
not done by the bootloader then enable the regulator when applying
constraints.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Try to find a human readable name for the regulator we're failing on and
print a specific diagnostic when we fail to set the suspend state.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Since it is now mandatory to supply constraints via init_data on device
registration check for that when registering, saving us from oopsing
later on.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This improves the machine level API in order to configure
regulator constraints and consumers as platform data and removes the
old string based API that required several calls to set up each regulator.
The intention is to create a struct regulator_init_data, populate
it's fields with constraints, consumers devices, etc and then register
the regulator device from board.c in the standard Linux way.
e.g. regulator LDO2 (supplying codec and sim) platform data.
/* regulator LDO2 consumer devices */
static struct regulator_consumer_supply ldo2_consumers[] = {
{
.dev = &platform_audio_device.dev,
.supply = "codec_avdd",
},
{
.dev = &platform_sim_device.dev,
.supply = "sim_vcc",
}
};
/* regulator LDO2 constraints */
static struct regulator_init_data ldo2_data = {
.constraints = {
.min_uV = 3300000,
.max_uV = 3300000,
.valid_modes_mask = REGULATOR_MODE_NORMAL,
.apply_uV = 1,
},
.num_consumer_supplies = ARRAY_SIZE(ldo2_consumers),
.consumer_supplies = ldo2_consumers,
};
/* machine regulator devices with thier consumers and constraints */
static struct platform_device wm8350_regulator_devices[] = {
{
.name = "wm8350-regulator",
.id = WM8350_LDO_2,
.dev = {
.platform_data = &ldo2_data,
},
},
};
Changes in detail:-
o Removed all const char* regulator config functions in machine API.
o Created new struct regulator_init_data to contain regulator
machine configuration constraints and consmuers.
o Changed set_supply(), set_machine_constraints(),
set_consumer_device_supply() to remove their string identifier
parameters. Also made them static and moved functions nearer top of
core.c.
o Removed no longer used inline func to_rdev()
o Added regulator_get_init_drvdata() to retrieve init data.
o Added struct device* as parameter to regulator_register().
o Changed my email address.
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This adds a regulator driver for the TI bq24022 Single-Chip
Li-Ion Charger with its nCE and ISET2 pins connected to GPIOs.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
This patch adds kernel build support for the regulator core.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
This provides a virtual regulator test harness which exposes a sysfs
interface for setting power requirements, intended for test purposes only.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
This adds supports for regulator that are not software controlable. It allows
them to coexist in systems with mixed supplies.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
This adds the regulator framework core.
This framework is designed to provide a generic interface to voltage
and current regulators within the Linux kernel. It's intended to
provide voltage and current control to client or consumer drivers and
also provide status information to user space applications through a
sysfs interface.
The intention is to allow systems to dynamically control regulator
output in order to save power and prolong battery life. This applies
to both voltage regulators (where voltage output is controllable) and
current sinks (where current output is controllable).
This framework safely compiles out if not selected so that client
drivers can still be used in systems with no software controllable
regulators.
Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
