]> git.baikalelectronics.ru Git - kernel.git/commit
regulator: core: Avoid propagating to supplies when possible
authorDouglas Anderson <dianders@chromium.org>
Tue, 20 Nov 2018 17:52:54 +0000 (09:52 -0800)
committerMark Brown <broonie@kernel.org>
Thu, 22 Nov 2018 14:38:12 +0000 (14:38 +0000)
commit8d6e1616ab219898c52f5cf5fc301e9031e1e09a
treeabb9f2f4614fa594d9134c3c9d1945a04bf12fc4
parentff86723511a20efa8b19f6f977b802bd66423c8a
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 206a0af25ab1 ("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>
drivers/regulator/core.c