| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The probe path of this driver is a bit complex: sometimes the
GPIO descriptor is passed to the regulator core, sometimes
it is not.
To handle it in a simple way: stick with the devm_* resource
management and unhinge the GPIO descriptor devres handling
right before passing it to the regulator core, if we pass it
to the regulator core.
Fixes: e7d2be696faa ("regulator: max8973: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This adds a function named devm_gpiod_unhinge() that removes
the resource management from a GPIO descriptor.
I am not sure if this is the best anglosaxon name for the
function, no other managed resources have an equivalent
currently, but I chose "unhinge" as the closest intuitive
thing I could imagine that fits Rusty Russell's API design
criterions "the obvious use is the correct one" and
"the name tells you how to use it".
The idea came out of a remark from Mark Brown that it should
be possible to handle over management of a resource from
devres to the regulator core, and indeed we can do that.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When we get a nonexeclusive GPIO descriptor using managed
resources, we should only add it to the list of managed
resources once: on the first user. Augment the
devm_gpiod_get_index() and devm_gpiod_get_from_of_node()
calls to account for this by checking if the descriptor
is already resource managed before we proceed to allocate
a new resource management struct.
Fixes: b0ce7b29bfcd ("regulator/gpio: Allow nonexclusive GPIO access")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This makes gpiod_get_from_of_node() respect the
GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which is especially
nice when getting regulator GPIOs right out of device
tree nodes.
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: b0ce7b29bfcd ("regulator/gpio: Allow nonexclusive GPIO access")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use the gpiod_get_from_of_node() rather than the devm_*
version so that the regulator core can handle the lifecycle
of these descriptors.
Fix up the errorpath so that we free this descriptor if
an error occurs in the callback. Rely on the regulator
core to deal with it after this point: a previous patch
fixed up the regulator core to properly dispose any
GPIO descriptors once you call regulator_register().
Fixes: 96392c3d8ca4 ("regulator: max77686: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This function already exist inside gpiolib, we were just
reluctant to make it available to the kernel at large as
the devm_* seemed to be enough for anyone.
However we found out that regulators need to do their own
lifecycle/refcounting on GPIO descriptors and explicitly
call gpiod_put() when done with a descriptor, so export
this function so we can hand the refcounting over to the
regulator core for these descriptors after retrieveal.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.
Fixes: d7a261c2d1f2 ("regulator: max8952: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.
Fixes: 2468f0d51548 ("regulator: lp8788-ldo: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.
Fixes: b2d751b7f69b ("regulator: lm363x: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.
Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If a GPIO descriptor is passed to the regulator_register()
function inside the config->ena_gpiod callers must be
sure that once they call this API the regulator core
owns that descriptor and will make sure to issue
gpiod_put() on it, no matter whether the call is
successful or not.
For device tree regulators, the regulator core will
automatically set up regulator init data from the device
tree when registering a regulator by calling
regulator_of_get_init_data() which in turn calls down to
the regulator driver's .of_parse_cb() callback.
This callback (in drivers such as for max77686) may also
choose to fill in the config->ena_gpiod field with a GPIO
descriptor.
Harden the errorpath of regulator_register() to
properly gpiod_put() any passed in cfg->ena_gpiod
or any gpiod coming from the device tree on any type
of error.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.
For instances using of_node_cmp, this has the side effect of now using
case sensitive comparisons. This should not matter for any FDT based
system which all of these are.
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently it is expected that regulator init data will be defined as a
series of sub-nodes from the node that bound in the driver. Add support
for a node to both bind in a driver and contain init data for that
regulator.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
To support future additions factor out the location of the OF node
containing the init data for the regulator from the code that parses the
init data.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
fix a compilation issue due to regulator_lock usage.
Signed-off-by: Pascal Paillet <p.paillet@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Prior to commit 5451781dadf8 ("regulator: core: Only count load for
enabled consumers") we used to always add up the total load on every
enable in _regulator_enable(). After that commit we only updated the
total load when enabling / disabling a regulator where a consumer
specified a load or when changing the consumer load on an enabled
regulator.
The problem with the new scheme is that if there is a system load
specified for a regulator but no consumers specify a load then we
never account for it.
Let's account for the system load in set_machine_constraints().
NOTE: with the new scheme we end up with a bit of a quandry. What if
someone specifies _both_ an initial mode and a system load? If we
take the system load into account right at init time then it will
effectively clobber the initial mode. We'll resolve this by saying
that if both are specified then the initial mode will win. The system
load will then only take effect if/when a consumer specifies a load.
If no consumers ever specify a load then the initial mode will persist
and the system load will have no effect.
Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers")
Reported-by: Brian Masney <masneyb@onstation.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Brian Masney <masneyb@onstation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Address remaining comments from original driver patch series
* Move RD_FIFO_CFG to be ordered corretly
* Expand spinlock comment
Signed-off-by: Ryan Case <ryandcase@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When we called regulator_enable() on a regulator we'd end up
propagating that call all the way up the chain every time. This is a
bit of a waste of time. A child regulator already refcounts its own
enables so it should avoid passing on to its parent unless the
refcount transitioned between 0 and 1.
Historically this hasn't been a huge problem since we skipped dealing
with enable for always-on regulators. In a previous patch, however,
we removed the always-on optimization. On one system, the debugfs
regulator_summary was now showing a "use_count" of 33 for a top-level
regulator.
Let's implement this optimization. This turns out to be fairly
trivial with the recent reorganization of the regulator core.
NOTE: as part of this patch I'll make "always-on" regulators start
with a use count of 1. This keeps the counts clean when recursively
resolving regulators.
ALSO NOTE: this commit also contains somewhat of a bug fix to
regulator_force_disable(). It was incorrectly looping over
"rdev->open_count" when it should have been looping over use_count.
We have to touch that code anyway (since we should no longer loop at
all), so we'll fix it together in one patch. Also: since this comes
after commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
regulators locking") we can now move to use _regulator_disable() for
our supply and keep it in the lock.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In general when the consumer of a regulator requests that the
regulator be disabled it no longer will be drawing much load from the
regulator--it should just be the leakage current and that should be
very close to 0.
Up to this point the regulator framework has continued to count a
consumer's load request for disabled regulators. This has led to code
patterns that look like this:
enable_my_thing():
regular_set_load(reg, load_uA)
regulator_enable(reg)
disable_my_thing():
regulator_disable(reg)
regulator_set_load(reg, 0)
Sometimes disable_my_thing() sets a nominal (<= 100 uA) load instead
of setting a 0 uA load. I will make the assertion that nearly all (if
not all) places where we set a nominal load of 100 uA or less we end
up with a result that is the same as if we had set a load of 0 uA.
Specifically:
- The whole point of setting the load is to help set the operating
mode of the regulator. Higher loads may need less efficient
operating modes.
- The only time this matters at all is if there is another consumer of
the regulator that wants the regulator on. If there are no other
consumers of the regulator then the regulator will turn off and we
don't care about the operating mode.
- If there's another consumer that actually wants the regulator on
then presumably it is requesting a load that makes our nominal
<= 100 uA load insignificant.
A quick survey of the existing callers to regulator_set_load() to see
how everyone uses it:
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The regulator core takes over managing the lifetime of the enable GPIO
once the regulator is registered. As such we shouldn't register the
enable GPIO using devm, or it will be freed twice.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The "requested_microamps" sysfs attribute was only being exposed for
"current" regulators. This didn't make sense. Allow it to be exposed
always.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Lochnagar is an evaluation and development board for Cirrus
Logic Smart CODEC and Amp devices. It allows the connection of
most Cirrus Logic devices on mini-cards, as well as allowing
connection of various application processor systems to provide a
full evaluation platform. This driver supports the board
controller chip on the Lochnagar board.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Based on review comments on the MFD driver, move the child drivers for
the Lochnagar MFD over to binding through device tree.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
GPIO descriptor array must be zero initialized to ensure that core will
properly handle also the case when no external GPIO pin is defined.
Fixes: 1c984942f0a4 ("regulator: s2mps11: Pass descriptor instead of GPIO number")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.21 for trivial conflict
|
|
Redefine binding for regulator-coupled-max-spread property in a way that
max-spread values are defined per regulator couple instead of defining
single max-spread for the whole group of coupled regulators.
With that change the following regulators coupling configuration will be
possible:
regA: regulatorA {
regulator-coupled-with = <®B ®C>;
regulator-coupled-max-spread = <100000 300000>;
};
regB: regulatorB {
regulator-coupled-with = <®A ®C>;
regulator-coupled-max-spread = <100000 200000>;
};
regC: regulatorC {
regulator-coupled-with = <®A ®B>;
regulator-coupled-max-spread = <300000 200000>;
};
Note that the regulator-coupled-max-spread property does not have any
users yet, hence it's okay to change the binding.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
It's unlikely that regulators may disappear/appear while regulators
debug-summary is being prepared, but let's be consistent and avoid that
situation.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Check whether supply regulator is the couple to avoid infinite recursion
during of locking.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Wait/wound mutex shall be used in order to avoid lockups on locking of
coupled regulators.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Suggested-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
when the VIR_LDO1 regulator supplier is it's brother,
we can't find the supplier.
example code :
&vir_regulator {
ldo0_vir: ldo0-virtual {
regulator-compatible = "VIR_LDO0";
regulator-name= "VIR_LDO0";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <2000000>;
};
ldo1_vir: ldo1-virtual {
regulator-compatible = "VIR_LDO1";
regulator-name= "VIR_LDO1";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3000000>;
ldo1-supply = <&ldo0_vir>;
};
...
}
so we add the child ptah to find the suppier.
Signed-off-by: zoro <long17.cool@163.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Instead of passing a global GPIO number, pass a descriptor looked
up from the device tree configuration node.
Tested on Odroid U3 (with max77686 although not using any GPIOs
for regulators, so at least default paths are not broken).
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Instead of passing a global GPIO number for the enable GPIO, pass
a descriptor looked up from the device tree node or the board file
decriptor table for the regulator.
There is a single board file passing the GPIOs for LDO1 and LDO2
through platform data, so augment this to pass descriptors
associated with the i2c device as well.
The special GPIO enable DT property for the enable GPIO is
nonstandard but this was accomodated in
commit 6a537d48461deacc57c07ed86d9915e5aa4b3539
"gpio: of: Support regulator nonstandard GPIO properties".
Cc: patches@opensource.cirrus.com
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Instead of passing a global GPIO number for the enable GPIO, pass
a descriptor looked up with the standard devm_gpiod_get_optional()
call.
This regulator supports passing platform data, but enable/sleep
regulators are looked up from the device tree exclusively, so
we can need not touch other files.
Tested on Odroid XU3 (with s2mps11 although not using any GPIOs
for regulators, so at least default paths are not broken).
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
BD71837 and BD71847 have a HW functionality which leave power
rails OFF after powerof state:
- if they have been controlled by SW.
- if state transition from poweroff is done to SNVS
BD71837 can after reset transition from power-off to SNVS or
READY state depending on reset reason. By default only wathcdog
reset changes state from poweroff to ready. Change PMIC
configuration to always transition to READY in order to avoid
crucial power rails being OFF after reset.
If SNVS is required the crucial power rails should not be
controlled by SW - eg corresponding regulator control register
should have SEL bit kept zero. Currently the driver assumes all
regulators to be controlled by SW so it sets all SEL bits to 1.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch updates license to use SPDX-License-Identifier
instead of verbose license text.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch updates license to use SPDX-License-Identifier
instead of verbose license text.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The voltages in bd718xx_3rd_nodvs_buck_volts are in ascendant order, so use
regulator_map_voltage_ascend.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Set the according constraints for PM_SUSPEND_STANDBY case.
Previously, only suspend to mem/disk were taken into
consideration.
Signed-off-by: Andrei Stefanescu <andrei.stefanescu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For state-mem and state-disk regulators can have
various parameters applied such as enabled/disabled,
current mode, voltage etc.
This patch adds documentation on how to set these parameters
in the device tree for the standby state.
Signed-off-by: Andrei Stefanescu <andrei.stefanescu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Regulators shall be uncoupled if one of the couples disappear.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On NVIDIA Tegra30 there is a requirement for regulator "A" to have voltage
higher than voltage of regulator "B" by N microvolts, the N value changes
depending on the voltage of regulator "B". This is similar to min-spread
between voltages of regulators, the difference is that the spread value
isn't fixed. This means that extra carefulness is required for regulator
"A" to drop its voltage without violating the requirement, hence its
voltage should be changed in steps so that its couple "B" could follow
(there is also max-spread requirement).
Add new "max_uV_step" constraint that breaks voltage change into several
steps, each step is limited by the max_uV_step value.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Certain hardware may require supply voltage to be changed in steps. Define
new property that allow to describe such hardware.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Device tree binding was changed in a way that now max-spread values must
be defied per regulator pair. Limit number of pairs in order to adapt to
the new binding without changing regulators code.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Redefine binding for regulator-coupled-max-spread property in a way that
max-spread values are defined per regulator couple instead of defining
single max-spread for the whole group of coupled regulators.
With that change the following regulators coupling configuration will be
possible:
regA: regulatorA {
regulator-coupled-with = <®B ®C>;
regulator-coupled-max-spread = <100000 300000>;
};
regB: regulatorB {
regulator-coupled-with = <®A ®C>;
regulator-coupled-max-spread = <100000 200000>;
};
regC: regulatorC {
regulator-coupled-with = <®A ®B>;
regulator-coupled-max-spread = <300000 200000>;
};
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Don't allow to get regulator until all of its couples resolved because
consumer will get EPERM and coupling shall be transparent for the drivers.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If registered regulator found a couple, then the couple can find the
registered regulator too and hence coupling can be mutually resolved
at the registration time.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread between
two devices' voltages is so high, that there is a risk of changing
'high' and 'low' states on the interconnection between devices powered
by those regulators.
Uncoupled regulators should be a special case of coupled regulators, so
they should share a common voltage setting path. When enabling,
disabling or setting voltage of a coupled regulator, all coupled
regulators should be locked. Regulator's supplies should be locked, when
setting voltage of a single regulator. Enabling a coupled regulator or
setting its voltage should not be possible if some of its coupled
regulators, has not been registered.
Add function for locking coupled regulators and supplies. Extract
a new function regulator_set_voltage_rdev() from
regulator_set_voltage_unlocked(), which is called when setting
voltage of a single regulator.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread between
two devices' voltages is so high, that there is a risk of changing
'high' and 'low' states on the interconnection between devices powered
by those regulators.
Introduce new function regulator_balance_voltage(), which
keeps max_spread constraint fulfilled between a group of coupled
regulators. It should be called if a regulator changes its
voltage or after disabling or enabling. Disabled regulators should
follow changes of the enabled ones, but their consumers' demands
shouldn't be taken into account while calculating voltage of other
coupled regulators.
Find voltages, which are closest to suiting all the consumers' demands,
while fulfilling max_spread constraint, keeping the following rules:
- if one regulator is about to rise its voltage, rise others
voltages in order to keep the max_spread
- if a regulator, which has caused rising other regulators, is
lowered, lower other regulators if possible
- if one regulator is about to lower its voltage, but it hasn't caused
rising other regulators, change its voltage so that it doesn't break the
max_spread
Change regulators' voltages step by step, keeping max_spread constraint
fulfilled all the time. Function regulator_get_optimal_voltage()
should find the best possible change for the regulator, which doesn't
break max_spread constraint. In function regulator_balance_voltage()
optimize number of steps by finding highest voltage difference on
each iteration.
If a regulator, which is about to change its voltage, is not coupled,
method regulator_get_optimal_voltage() should simply return the lowest
voltage fulfilling consumers' demands.
Coupling should be checked only if the system is in PM_SUSPEND_ON state.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Review of the MFD component has stated we should not include the
register headers through lochnagar.h and thus removed them from that
header. Explicitly include them in the end drivers manually.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
With gcc 4.1:
drivers/regulator/bd718x7-regulator.c: In function ‘bd718xx_probe’:
drivers/regulator/bd718x7-regulator.c:1020: warning: initialization from incompatible pointer type
drivers/regulator/bd718x7-regulator.c:1024: warning: initialization from incompatible pointer type
Apparently this old compiler can't handle the obscure double
indirection.
However, there is no need for a double indirection. Just store a
pointer to the array instead, like other drivers tend to do.
Fixes: 494edd266b945f36 ("regulator/mfd: Support ROHM BD71847 power management IC")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
