Some drivers (at least 3 drivers) have such variant of linear mapping that
the first few selectors are invalid and the reset are linear mapping.
Let's support this case in core.
This patch adds linear_min_sel in struct regulator_desc,
so we can allow specific minimal selector for starting linear mapping.
Then extends regulator_[map|list]_voltage_linear() to support this feature.
Note that for selectors less than min_linear_index, we need count them to
n_voltages so regulator_list_voltage() won't fail while checking the boundary
for selector before calling list_voltage callback.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some regulators can set any voltage within the constraints range,
not being limited to specified operating points.
This patch makes it possible to describe such regulator and makes
the regulator_is_supported_voltage() function behave correctly.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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>
The regulators should be tending to the maximum in the available range and
consumers should specify the widest range possible.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
REGULATOR_STATUS_UNDEFINED is to be returned by regulator, if any other state
doesn't really apply.
Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It is very common for regulators to support having their enable signal
controlled by a GPIO. Since there are a bunch of fiddly things to get
right like handling the operations when the enable signal is tied to
a rail and it's just replicated code add support for this to the core.
Drivers should set ena_gpio in their config if they have a GPIO control,
using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for
the initial state) and ena_gpio_invert if the GPIO is active low. The
core will then override any enable and disable operations the driver has
and instead control the specified GPIO.
This will in the future also allow us to further extend the core by
identifying when several enable signals have been tied together and
handling this properly.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Many regulators have a fixed specification for their enable time. Allow
this to be set in the regulator_desc as a number to save them having to
implement an explicit operation.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This change makes it possible to set ramp_delay with 0.xxx mV/uS without
truncation issue.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
For some hardwares ramp_delay for BUCKs is a configurable parameter which can
be configured through DT or board file.This patch adds ramp_delay to regulator
constraints and allow user to configure it for regulators which supports this
feature, through DT or board file. It will provide two ways of setting the
ramp_delay for a regulator:
First, by setting it as constraints in board file(for configurable
regulators) and set_machine_constraints() will take care of setting it on
hardware by calling(the provided) .set_ramp_delay() operation(callback).
Second, by setting it as data in regulator_desc(as fixed/default
ramp_delay rate) for a regulator in driver.
regulator_set_voltage_time_sel() will give preference to
constraints->ramp_delay while reading ramp_delay rate for regulator. Similarly
users should also take care accordingly while refering ramp_delay rate(in case
of implementing their private .set_voltage_time_sel() callbacks for different
regulators).
[Rewrote subject for 80 columns -- broonie]
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This patch adds regulator_set_voltage_time_sel(), to move into core, the
commonly used code by drivers to provide the .set_voltage_time_sel callback.
It will also allow us to configure different ramp delay for different
regulators easily.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some regulator hardware use table based mapping can set volt_table in
regulator_desc and use regulator_list_voltage_table() for their list_voltage
callback.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A lot of regulator hardware maps selectors on to voltages with a simple
linear mapping function
selector = base + (selector * step size)
Provide off the shelf list_voltage() and map_voltage() operations which
use new min_uV and uV_step members in the regulator_desc to implement
this function.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
In order to allow more drivers to factor things out into data allow
drivers to provide a mapping function to convert voltages into selectors.
This allows any driver to use set_voltage_sel(). The existing mapping
based on iterating over list_voltage() is provided as an operation which
can be assigned to the new map_voltage() function though for ease of
transition it is treated as the default.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Since the enable(), disable() and is_enabled() operations for most regmap
based regulators come down to reading and updating a single register bit
we can factor out the code and allow these drivers to just define which
bit to update using the enable_reg and enable_mask fields in their desc
and then use operations provided by the core.
As well as the code saving this opens the door to future optimisation of
the bulk operations - if the core can realise that we are updating a
single register for multiple regulators then it should be able to combine
these updates into a single physical operation.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Since the voltage selector operations are intended to directly map a
bitfield in the device register map into regulator API operations the
code for implementing them is usually very standard we can save some
code by providing standard implementations for devices using the regmap
API.
Drivers using regmap can pass their regmap in in the regmap_config
struct, set vsel_reg and vsel_mask in their regulator_desc and then
use regulator_{get,set}_voltage_sel_regmap in their ops. This saves
a small amount of code from each driver.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Since many regulators use regmap for register I/O and since there's quite
a few very common patterns in the code allow drivers to pass in a regmap
to the core for use in generic code.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Rather than adding new arguments to regulator_register() every time we
want to add a new bit of dynamic information at runtime change the function
to take these via a struct. By doing this we avoid needing to do further
changes like the recent addition of device tree support which required each
regulator driver to be updated to take an additional parameter.
The regulator_desc which should (mostly) be static data is still passed
separately as most drivers are able to configure this statically at build
time.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Drivers should be able to declare their descriptors const and the framework
shouldn't ever be modifying the desciptor. Make the parameter and the
pointer in regulator_dev const to enforce this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If CONFIG_DEBUG_FS=y debugfs functions will never return an
ERR_PTR. Instead they'll return NULL. The intent is to remove
ifdefs in calling code.
Update the code to reflect this. We gain an extra dentry pointer
per struct regulator and struct regulator_dev but that should be
ok because most distros have debugfs compiled in anyway.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The 'mode' is defined in consumer.h.
* patch base version : linux-3.2.4
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = <®ulator1>;
vpll-supply = <®ulator2>;
};
The driver would then do a regulator_get(dev, "vmmc"); to get
regulator1 and do a regulator_get(dev, "vpll"); to get
regulator2.
of_get_regulator() extracts the regulator node for a given
device, based on the supply name.
Use it to look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Also, since the regulator dt nodes can use the same binding to
associate with a parent regulator/supply, allow the drivers to
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
With device tree support for regulators, its needed that the
regulator_dev->dev device has the right of_node attached.
To be able to do this add an additional parameter to the
regulator_register() api, wherein the dt-adapted driver can
then pass this additional info onto the regulator core.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This was implicitly appearing by way of module.h -- but when
we fix that, we'll get this:
In file included from drivers/regulator/dummy.c:21:
include/linux/regulator/driver.h:197: error: field 'notifier' has incomplete type
make[3]: *** [drivers/regulator/dummy.o] Error 1
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
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>
Currently the regulator supply implementation is somewhat complex and
fragile as it doesn't look like standard consumers but is instead a
parallel implementation. This causes issues with locking and reference
counting.
Move the implementation over to using standard consumers to address this.
Rather than only notifying the supply on the first enable/disable we do so
every time the regulator is enabled or disabled, simplifying locking as we
don't need to hold a lock on the consumer we are about to enable.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This makes it possible to set the stabilization time for voltage
regulators in the same manner as enable_time(). The interface
only supports regulators that implements fixed selectors.
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>
We only expose the use and open counts to userspace, providing a tiny
bit of insight into what the API is up to.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Many regulator drivers implement voltage setting by looping through a
table of possible values, normally because the set of available voltages
can't be mapped onto selectors with simple calcuation. Factor out these
loops by providing a variant of set_voltage() which takes a selector rather
than a voltage range as an argument and implementing a loop through the
available selectors in the core.
This is not going to be suitable for use with all devices as when the
regulator voltage can be mapped onto selector values with a simple
calculation the linear scan through the available values will be more
expensive than just doing the calculation, especially for regulators
that provide fine grained voltage control.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Since drivers already have to provide an API for translating selectors
into voltages they may as well just report the selector values directly
to the core API rather than implement the lookup themselves. The old
interface is left in place for now, but may be removed in future.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Currently the regulator API uses the constraints structure passed in to
the core throughout the lifetime of the object. This means that it is not
possible to mark the constraints as __initdata so if the kernel supports
many boards the constraints for all of them are kept around throughout the
lifetime of the system, consuming memory needlessly. By copying constraints
that are actually used we allow the use of __initdata, saving memory when
multiple boards are supported.
This also means the constraints can be const.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Change the interface used by set_voltage() to report the selected value
to the regulator core in terms of a selector used by list_voltage().
This allows the regulator core to know the voltage that was chosen
without having to do an explict get_voltage(), which would be much more
expensive as it will generally access hardware.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <broonie@opensource.wolfsonmicro.com>
Document the possibility that is_enabled may also return with negative
errorcodes.
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>
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>
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 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 <randy.dunlap@oracle.com>
cc: Liam Girdwood <lrg@slimlogic.co.uk>
cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
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 <dbrownell@users.sourceforge.net>
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>
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>
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 <randy.dunlap@oracle.com>
cc: Liam Girdwood <lrg@slimlogic.co.uk>
cc: 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>
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>
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>
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 <randy.dunlap@oracle.com>
cc: Liam Girdwood <lrg@slimlogic.co.uk>
cc: 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>
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 allows regulator drivers to register their regulators and provide
operations to the core. It also has a notifier call chain for propagating
regulator events to clients.
Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Mark Brown