| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Wenyou Yang <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
These patches add the ability to create an alternative device on which
a lookup for a certain supply should be conducted.
A common use-case for this would be devices that are logically
represented as a collection of drivers within Linux but are are
presented as a single device from device tree. It this case it is
necessary for each sub device to locate their supply data on the main
device.
Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Add REGULATOR_LINEAR_RANGE macro and convert regulator drivers to use it.
Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
linear ranges means each range has linear voltage settings.
So we can calculate max_uV for each linear range in regulator core rather than
set the max_uV field in drivers.
Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
The turn-on time of the regulator depends on the regulator device's
electrical characteristics. Sometimes regulator turn-on time also
depends on the capacitive load on the given platform and it can be
more than the datasheet value.
The driver provides the enable-time as per datasheet.
Add support for configure the enable ramp time through regulator
constraints so that regulator core can take this value for enable
time for that regulator.
Signed-off-by: Laxman Dewangan <[email protected]>
Acked-by: Stephen Warren <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Fix fatal kernel-doc error in <linux/regulator/driver.h>:
Error(include/linux/regulator/driver.h:52): cannot understand prototype: 'struct regulator_linear_range '
Signed-off-by: Randy Dunlap <[email protected]>
[Rewrote first line -- broonie]
Signed-off-by: Mark Brown <[email protected]>
|
|
No boards have used this functionality and the new default of providing
dummy regulators by default provides a better solution to the problem it
was trying to solve.
Signed-off-by: Mark Brown <[email protected]>
|
|
Many regulator drivers have a remove function that consists solely of
calling regulator_unregister() so provide a devm_regulator_register()
in order to allow this repeated code to be removed and help eliminate
error handling code.
Signed-off-by: Mark Brown <[email protected]>
|
|
If given rail has the single voltage (n_voltages = 1) then provide the
rail voltage through regulator descriptor so that core can use this
value for finding voltage.
This will avoid the implementation of the callback for get_voltage() or
list_voltage() callback on regulator driver.
Signed-off-by: Laxman Dewangan <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add a resource managed regulator_get_exclusive()
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Add define for __FAN53555_H__ to prevent multiple include of the header file.
Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
This patch adds devicetree bindings for max8660, along with some
documentation.
Signed-off-by: Daniel Mack <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
While the majority of supplies on devices are mandatory and can't be
physically omitted for electrical reasons some devices do have optional
supplies and need to know if they are missing, MMC being the most common
of these.
Currently the core accurately reports all errors when regulators are
requested since it does not know if the supply is one that must be provided
even if by a regulator software does not know about or if it is one that
may genuinely be disconnected. In order to allow this behaviour to be
changed and stub regulators to be provided in the former case add a new
regulator request function regulator_get_optional() which provides a hint
to the core that the regulator may genuinely not be connected.
Currently the implementation is identical to the current behaviour, future
patches will add support in the core for returning stub regulators in the
case where normal regulator_get() fails and the board has requested it.
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Chris Ball <[email protected]>
|
|
Signed-off-by: Mark Brown <[email protected]>
|
|
Add pfuze100 regulator driver.
Signed-off-by: Robin Gong <[email protected]>
Tested-by: Steffen Trumtrar <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Some hardwares support disabling ramp delay, so adding ramp_disable flag to
constraints. It will be used to figure out whether ramp_delay in constraints
is explicitly set to zero or its unintialized (zero by default).
And we don't need to call set_voltage_time_sel() for regulators for whom ramp
delay is disabled in constraints.
Signed-off-by: Yadwinder Singh Brar <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Many regulators have several linear ranges of selector with different
step sizes, for example offering better resolution at lower voltages.
Provide regulator_{map,list}_voltage_linear_range() allowing these
regulators to use generic code. To do so a table of regulator_linear_range
structs needs to be pointed to from the descriptor.
This was inspired by similar code included in a driver submission from
Chao Xie and Yi Zhang at Marvell.
Signed-off-by: Mark Brown <[email protected]>
|
|
The expected semantic for something expressed as a tolerance is that it
should deliver the specified value with some deviation allowed but this
is not what set_voltage_tol() currently does. Instead it just passes
the maximum possible range to set_voltage() which will typically result
in a voltage aimed at lower than the target voltage.
Instead first try to set a voltage between the target voltage and the
upper limit, then fall back on the full range. This will be much more
robust against physical variation in systems and makes the API behave
more like users would expect.
Signed-off-by: Mark Brown <[email protected]>
|
|
|
|
Some platforms don't support the AB8500 external regulators, so instead
of having a list of is_<platform>() calls prior to calling
ab8500_ext_regulator_init() from ab8500_regulator_probe(), we can only
register as a platform device on platforms which require them. It means
we also have more control over them when booting with Device Tree.
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <broonielinaro.org>
|
|
Add regulator_get_linear_step(), which returns the voltage step size
between VSEL values for linear regulators. This is intended for use
by regulator consumers which build their own voltage-to-VSEL tables.
Signed-off-by: Paul Walmsley <[email protected]>
Reviewed-by: Andrew Chew <[email protected]>
Cc: Matthew Longnecker <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
A lot of regulator hardware has ascendant voltage list.
This patch adds regulator_map_voltage_ascend() and export it.
Drivers that have ascendant voltage list can use this as their map_voltage()
operation, this is more efficient than default regulator_map_voltage_iterate()
function.
Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
ab8500_ext_regulator_exit() never fails.
Signed-off-by: Axel Lin <[email protected]>
Acked-by: Bengt Jonsson <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
This patch adds Device Tree support to max8952 regulator driver.
Signed-off-by: Tomasz Figa <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
This patch modifies platform data structure of max8952 driver to
use pointer to regulator_init_data struct instead of embedding it.
This is a prerequisite for adding Device Tree support for the driver.
Signed-off-by: Tomasz Figa <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Introduce aux5, aux6 into ab8540 regulator framework.
Signed-off-by: Zhenhua HUANG <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Reviewed-by: Maxime COQUELIN <[email protected]>
Reviewed-by: David PARIS <[email protected]>
Reviewed-by: Philippe LANGLAIS <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Before the AB8500 External Regulator driver was Mainlined, it used
to be conditionally compiled in using the CONFIG_REGULATOR_AB8500_EXT
flag. During the review process that capability was removed, but the
guard controlling prototyping slipped though the net. This patch
cleans it up.
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
To obtain full AB8540 regulator support, the AB8500 regulator driver
first needs to know its register layout and their initialisation values
for each. That information is provided via a couple of large data
structures which we provide here.
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
To obtain full AB8505 regulator support, the AB8500 regulator driver
first needs to know its register layout and their initialisation values
for each. That information is provided via a couple of large data
structures which we provide here.
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
The purpose of this patch is to guarantee that ab8500-debug will
record the regulator registers before they are modified by the
ab8500 regulator driver.
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
The USB regulator is controlled by hardware. The software support
was only needed for early hardware (ED) which is no longer supported.
Signed-off-by: Bengt Jonsson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Support for HW request is added in the external regulator
driver. A flag in the board configuration can be set to
let HW control the regulator when there is no SW request.
This means that the regulator will be put in high power
mode when there is a SW request and in HW-request mode
otherwise.
Signed-off-by: Bengt Jonsson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Reviewed-by: Mattias NILSSON <[email protected]>
Reviewed-by: Jonas ABERG <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
The ABx500 is capable of controlling three external regulator supplies.
Most commonly on and off are supported, but if an external regulator
chipset or power supply supports high-power and low-power mode settings,
we can control those too.
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
Clean out initialisation that is handled by SoC. Regulator
settings for Vpll (partly), Vsmps1, Vsmps2, Vsmps3 (partly),
Vrf1, Varm, Vape, Vbb, Vmod are cleaned out. They should not
be touched by the kernel.
We also update many of the initialisation values to be more
in-line with the current development efforts of ST-Ericsson
internal engineers.
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|