linux.git/drivers/regulator/core.c, branch v5.19

Merge remote-tracking branch 'regulator/for-5.19' into regulator-next

2022-05-17T15:59:05+00:00

regulator: core: Fix enable_count imbalance with EXCLUSIVE_GET

2022-05-05T14:13:06+00:00

Since the introduction of regulator->enable_count, a driver that did
an exclusive get on an already-enabled regulator would end up with
enable_count initialized to 0 but rdev->use_count initialized to 1.
With that starting point the regulator is effectively stuck enabled,
because if the driver attempted to disable it it would fail the
enable_count underflow check in _regulator_handle_consumer_disable().

The EXCLUSIVE_GET path in _regulator_get() now initializes
enable_count along with rdev->use_count so that the regulator can be
disabled without underflowing the former.

Signed-off-by: Zev Weiss 
Fixes: 5451781dadf85 ("regulator: core: Only count load for enabled consumers")
Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net
Signed-off-by: Mark Brown

regulator: core: Add error flags to sysfs attributes

2022-05-04T14:31:26+00:00

If a regulator provides a get_error_flags() operation, its sysfs
attributes will now include an entry for each defined
REGULATOR_ERROR_* flag.

Signed-off-by: Zev Weiss 
Link: https://lore.kernel.org/r/20220504065252.6955-3-zev@bewilderbeest.net
Signed-off-by: Mark Brown

regulator: core: Sleep (not delay) in set_voltage()

2022-04-21T13:18:06+00:00

These delays can be relatively large (e.g., hundreds of microseconds to
several milliseconds on RK3399 Gru systems). Per
Documentation/timers/timers-howto.rst, that should usually use a
sleeping delay. Let's use the existing regulator delay helper to handle
both large and small delays appropriately. This avoids burning a bunch
of CPU time and hurting scheduling latencies when hitting regulators a
lot (e.g., during cpufreq).

The sleep vs. delay issue choice has been made differently over time --
early versions of RK3399 Gru PWM-regulator support used usleep_range()
in pwm-regulator.c. More of this got moved into the regulator core,
in commits like:

73e705bf81ce regulator: core: Add set_voltage_time op

At the same time, the sleep turned into a delay.

It's OK to sleep in _regulator_do_set_voltage(), as we aren't in an
atomic context. (All our callers grab various mutexes already.)

I avoid using fsleep() because it uses a usleep_range() of [N to N*2],
and usleep_range() very commonly biases to the high end of the range. We
don't want to double the expected delay, especially for long delays.

Signed-off-by: Brian Norris 
Reviewed-by: Matthias Kaehlcke 
Link: https://lore.kernel.org/r/20220420141511.v2.2.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid
Signed-off-by: Mark Brown

regulator: core: Rename _regulator_enable_delay()

2022-04-21T13:18:05+00:00

I want to use it in other contexts besides _regulator_do_enable().

Signed-off-by: Brian Norris 
Link: https://lore.kernel.org/r/20220420141511.v2.1.I31ef0014c9597d53722ab513890f839f357fdfb3@changeid
Signed-off-by: Mark Brown

regulator: Flag uncontrollable regulators as always_on

2022-04-04T07:51:07+00:00

While we currently assume that regulators with no control available are
just uncontionally enabled this isn't always as clearly displayed to
users as is desirable, for example the code for disabling unused
regulators will log that it is about to disable them. Clean this up a
bit by setting always_on during constraint evaluation if we have no
available mechanism for controlling the regualtor so things that check
the constraint will do the right thing.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20220325144637.1543496-1-broonie@kernel.org
Signed-off-by: Mark Brown

regulator: core: fix false positive in regulator_late_cleanup()

2022-02-08T13:37:48+00:00

The check done by regulator_late_cleanup() to detect whether a regulator
is on was inconsistent with the check done by _regulator_is_enabled().
While _regulator_is_enabled() takes the enable GPIO into account,
regulator_late_cleanup() was not doing that.

This resulted in a false positive, e.g. when a GPIO-controlled fixed
regulator was used, which was not enabled at boot time, e.g.

reg_disp_1v2: reg_disp_1v2 {
	compatible = "regulator-fixed";
	regulator-name = "display_1v2";
	regulator-min-microvolt = <1200000>;
	regulator-max-microvolt = <1200000>;
	gpio = <&tlmm 148 0>;
	enable-active-high;
};

Such regulator doesn't have an is_enabled() operation. Nevertheless
it's state can be determined based on the enable GPIO. The check in
regulator_late_cleanup() wrongly assumed that the regulator is on and
tried to disable it.

Signed-off-by: Oliver Barta 
Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.com
Signed-off-by: Mark Brown

Merge tag 'regulator-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2021-11-02T02:04:47+00:00

Pull regulator updates from Mark Brown:
 "Thanks to the removal of the unused TPS80021 driver the regulator
  updates for this cycle actually have a negative diffstat.

  Otherwise it's been quite a quiet release, lots of fixes and small
  improvements with the biggest individual changes being several
  conversions of DT bindings to YAML format"

* tag 'regulator-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (34 commits)
  regulator: Don't error out fixed regulator in regulator_sync_voltage()
  regulator: tps80031: Remove driver
  regulator: Fix SY7636A breakage
  regulator: uniphier: Add binding for NX1 SoC
  regulator: uniphier: Add USB-VBUS compatible string for NX1 SoC
  regulator: qcom,rpmh: Add compatible for PM6350
  regulator: qcom-rpmh: Add PM6350 regulators
  regulator: sy7636a: Remove requirement on sy7636a mfd
  regulator: tps62360: replacing legacy gpio interface for gpiod
  regulator: lp872x: Remove lp872x_dvs_state
  regulator: lp872x: replacing legacy gpio interface for gpiod
  regulator: dt-bindings: samsung,s5m8767: convert to dtschema
  regulator: dt-bindings: samsung,s2mpa01: convert to dtschema
  regulator: dt-bindings: samsung,s2m: convert to dtschema
  dt-bindings: clock: samsung,s2mps11: convert to dtschema
  regulator: dt-bindings: samsung,s5m8767: correct s5m8767,pmic-buck-default-dvs-idx property
  regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is disabled
  regulator: dt-bindings: maxim,max8973: convert to dtschema
  regulator: dt-bindings: maxim,max8997: convert to dtschema
  regulator: dt-bindings: maxim,max8952: convert to dtschema
  ...

regulator: Don't error out fixed regulator in regulator_sync_voltage()

2021-10-23T13:21:11+00:00

Fixed regulator can't change voltage and regulator_sync_voltage()
returns -EINVAL in this case. Make regulator_sync_voltage() to succeed
for regulators that are incapable to change voltage.

On NVIDIA Tegra power management driver needs to sync voltage and we have
one device (Trimslice) that uses fixed regulator which is getting synced.
The syncing error isn't treated as fatal, but produces a noisy error
message. This patch silences that error.

Signed-off-by: Dmitry Osipenko 
Link: https://lore.kernel.org/r/20211021183308.27786-1-digetx@gmail.com
Signed-off-by: Mark Brown

regulator: Lower priority of logging when setting supply

2021-09-30T12:26:07+00:00

We lowered all the other constraint related log messages to debug level so
lower the logging of what supplies we're configuring to debug level too.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20210929140717.3769-1-broonie@kernel.org
Signed-off-by: Mark Brown