Skip to content

L
linux
Switch branch/tag
  1. 11 Dec, 2018 3 commits
  3. 06 Dec, 2018 1 commit
    • Rob Herring's avatar
      regulator: Use of_node_name_eq for node name comparisons · c32569e3
      Rob Herring authored 
      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: default avatarRob Herring <robh@kernel.org>
Acked-by: default avatarAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c32569e3
  5. 04 Dec, 2018 2 commits
  7. 03 Dec, 2018 1 commit
  9. 26 Nov, 2018 1 commit
    • Douglas Anderson's avatar
      regulator: core: Apply system load even if no consumer loads · fa94e48e
      Douglas Anderson authored 
      Prior to commit 5451781d ("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: 5451781d ("regulator: core: Only count load for enabled consumers")
Reported-by: default avatarBrian Masney <masneyb@onstation.org>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Tested-by: default avatarBrian Masney <masneyb@onstation.org>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      fa94e48e
  11. 22 Nov, 2018 3 commits
    • Ryan Case's avatar
      spi: spi-qcom-qspi: Fix remaining driver nits · 478652f3
      Ryan Case authored 
      Address remaining comments from original driver patch series

* Move RD_FIFO_CFG to be ordered corretly
* Expand spinlock comment
Signed-off-by: default avatarRyan Case <ryandcase@chromium.org>
Reviewed-by: default avatarStephen Boyd <swboyd@chromium.org>
Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      478652f3
    • Douglas Anderson's avatar
      regulator: core: Avoid propagating to supplies when possible · 1fc12b05
      Douglas Anderson authored 
      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 f8702f9e ("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: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      1fc12b05
    • Douglas Anderson's avatar
      regulator: core: Only count load for enabled consumers · 5451781d
      Douglas Anderson authored 
      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: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      5451781d
  13. 21 Nov, 2018 1 commit
  15. 20 Nov, 2018 4 commits
  17. 19 Nov, 2018 5 commits
  19. 15 Nov, 2018 4 commits
  21. 14 Nov, 2018 3 commits
  23. 13 Nov, 2018 3 commits
  25. 08 Nov, 2018 9 commits
    • Dmitry Osipenko's avatar
      regulator: core: Decouple regulators on regulator_unregister() · 6303f3e7
      Dmitry Osipenko authored 
      Regulators shall be uncoupled if one of the couples disappear.
Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      6303f3e7
    • Dmitry Osipenko's avatar
      regulator: core: Add new max_uV_step constraint · 85254bcf
      Dmitry Osipenko authored 
      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: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      85254bcf
    • Dmitry Osipenko's avatar
      regulator: Document new regulator-max-step-microvolt property · a2dfe7c7
      Dmitry Osipenko authored 
      Certain hardware may require supply voltage to be changed in steps. Define
new property that allow to describe such hardware.
Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
Reviewed-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      a2dfe7c7
    • Dmitry Osipenko's avatar
      regulator: core: Limit regulators coupling to a single couple · 40c223ef
      Dmitry Osipenko authored 
      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: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      40c223ef
    • Dmitry Osipenko's avatar
      regulator: Change regulator-coupled-max-spread property · d3b687c5
      Dmitry Osipenko authored 
      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 = <&regB &regC>;
	regulator-coupled-max-spread = <100000 300000>;
};

regB: regulatorB {
	regulator-coupled-with = <&regA &regC>;
	regulator-coupled-max-spread = <100000 200000>;
};

regC: regulatorC {
	regulator-coupled-with = <&regA &regB>;
	regulator-coupled-max-spread = <300000 200000>;
};
Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d3b687c5
    • Dmitry Osipenko's avatar
      regulator: core: Don't allow to get regulator until all couples resolved · 79d6f049
      Dmitry Osipenko authored 
      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: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      79d6f049
    • Dmitry Osipenko's avatar
      regulator: core: Mutually resolve regulators coupling · f9503385
      Dmitry Osipenko authored 
      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: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      f9503385
    • Maciej Purski's avatar
      regulator: core: Change voltage setting path · 9243a195
      Maciej Purski authored 
      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: default avatarMaciej Purski <m.purski@samsung.com>
Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      9243a195
    • Maciej Purski's avatar
      regulator: core: Add voltage balancing mechanism · c054c6c7
      Maciej Purski authored 
      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: default avatarMaciej Purski <m.purski@samsung.com>
Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c054c6c7
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7