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)
commit1fc12b05895ea50386f0e666f84053f0c8307943
treeabb9f2f4614fa594d9134c3c9d1945a04bf12fc4
parent5451781dadf85000665e0e2c3288e9e0f34b860a
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>
drivers/regulator/core.c