diff options
author | Douglas Anderson <dianders@chromium.org> | 2018-11-20 20:52:54 +0300 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2018-11-22 17:38:12 +0300 |
commit | 1fc12b05895ea50386f0e666f84053f0c8307943 (patch) | |
tree | abb9f2f4614fa594d9134c3c9d1945a04bf12fc4 /drivers/spi | |
parent | 5451781dadf85000665e0e2c3288e9e0f34b860a (diff) | |
download | linux-1fc12b05895ea50386f0e666f84053f0c8307943.tar.xz |
regulator: core: Avoid propagating to supplies when possible
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>
Diffstat (limited to 'drivers/spi')
0 files changed, 0 insertions, 0 deletions