Commit Graph

3401 Commits

Author SHA1 Message Date
Mark Brown c3b5725965
Merge remote-tracking branch 'regulator/topic/coupled' into regulator-next 2018-12-21 13:43:35 +00:00
Kangjie Lu cd07e3701f
regulator: tps65910: fix a missing check of return value
tps65910_reg_set_bits() may fail. The fix checks if it fails, and if so,
returns with its error code.

Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-21 11:04:59 +00:00
Axel Lin 77ea906082
regulator: mcp16502: Select REGMAP_I2C to fix build error
Fix build error when CONFIG_REGMAP_I2C=m && CONFIG_REGULATOR_MCP16502=y.

drivers/regulator/mcp16502.o: In function `mcp16502_probe':
mcp16502.c:(.text+0xca): undefined reference to `__devm_regmap_init_i2c'

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-21 11:02:24 +00:00
Yangtao Li 3e60b4fc86
regulator: convert to DEFINE_SHOW_ATTRIBUTE
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-20 14:38:42 +00:00
Axel Lin f4c8f98028
regulator: mcp16502: Fix missing n_voltages setting
The n_voltages setting is not set, fix it.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-20 14:38:27 +00:00
Axel Lin 4906d09164
regulator: mcp16502: Use #ifdef CONFIG_PM_SLEEP around mcp16502_suspend/resume_noirq
mcp16502_suspend/resume_noirq is only used by SET_NOIRQ_SYSTEM_SLEEP_PM_OPS
when CONFIG_PM_SLEEP is defined.
So use #ifdef CONFIG_PM_SLEEP instead CONFIG_SUSPEND guard.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-20 14:36:04 +00:00
Andrei.Stefanescu@microchip.com 308144ce8e
regulator: mcp16502: code cleanup
This patch does the following:
- align parameter with parenthesis
- fix compile error

If CONFIG_SUSPEND is not set the dummy pm_ops
callbacks are named mcp16502_suspend and mcp16502_resume
instead of mcp16502_suspend_noirq and mcp16502_resume_noirq.

Excerpt from compile log (kbuild test robot):

In file included from include/linux/device.h:23:0,
from include/linux/gpio/driver.h:5,
from include/asm-generic/gpio.h:13,
from include/linux/gpio.h:62,
from drivers/regulator/mcp16502.c:11:

>> drivers/regulator/mcp16502.c:527:32: error: 'mcp16502_suspend_noirq'
undeclared here (not in a function); did you mean 'mcp16502_suspend'?
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mcp16502_suspend_noirq,

>> drivers/regulator/mcp16502.c:528:10: error: 'mcp16502_resume_noirq'
undeclared here (not in a function); did you mean 'mcp16502_suspend_noirq'?
mcp16502_resume_noirq)

vim +527 drivers/regulator/mcp16502.c

524
525	#ifdef CONFIG_PM
526	static const struct dev_pm_ops mcp16502_pm_ops = {
> 527		SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mcp16502_suspend_noirq,
> 528					     mcp16502_resume_noirq)
529	};
530	#endif
531	static const struct i2c_device_id mcp16502_i2c_id[] = {
532		{ "mcp16502", 0 },
533		{ }
534	};
535	MODULE_DEVICE_TABLE(i2c, mcp16502_i2c_id);
536

Signed-off-by: Andrei Stefanescu <andrei.stefanescu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-19 18:40:39 +00:00
Wei Yongjun 78e6fbf321
regulator: act8945a-regulator: make symbol act8945a_pm static
Fixes the following sparse warning:

drivers/regulator/act8945a-regulator.c:340:1: warning:
 symbol 'act8945a_pm' was not declared. Should it be static?

Fixes: 7482d6ecc6 ("regulator: act8945a-regulator: Implement PM functionalities")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-19 18:09:37 +00:00
Kangjie Lu 966e927bf8
drivers/regulator: fix a missing check of return value
If palmas_smps_read() fails, we should not use the read data in "reg"
which may contain random value. The fix inserts a check for the return
value of palmas_smps_read(): If it fails, we return the error code
upstream and stop using "reg".

Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-19 12:37:52 +00:00
Claudiu Beznea 22a5a4a44c
regulator: act8945a-regulator: fix 'defined but not used' compiler warning
Fix 'defined but not used' compiler warning for act8945a_suspend()
function in case CONFIG_PM_SLEEP is not defined.

Fixes: b5ebba46e6 ("regulator: act8945a-regulator: add shutdown function")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reported-by: Andrei Stefanescu <andrei.stefanescu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-17 12:30:57 +00:00
Priit Laes 918446c965
regulator: axp20x: fix set_ramp_delay for AXP209/dcdc2
Initial commit of set_ramp_delay feature was missing an assignment which
should have populated slew_rate table for dcdc2 regulator. Add it.

Fixes: d29f54df8b ("regulator: axp20x: add support for set_ramp_delay for AXP209")

Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-17 12:26:34 +00:00
Andrei.Stefanescu@microchip.com fc401cb98a
regulator: mcp16502: add support for suspend
This patch adds support for entering/resuming suspend states.
It does this by setting the LPM pin of the PMIC.

When suspending the PMIC will enter the Low-power mode
when the LPM pin will be set to high. If the suspend target state
is suspend-to-mem, the PMIC will transition to Hibernate mode,
otherwise, if it is standby, it will remain in Low-power mode.

Signed-off-by: Andrei Stefanescu <andrei.stefanescu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-14 11:39:58 +00:00
Olliver Schinagl 77e3e3b165
regulator: axp20x: add software based soft_start for AXP209 LDO3
In the past, there have been words on various lists that if LDO3 is
disabled in u-boot, but enabled in the DTS, the axp209 driver would
fail to continue/hang. Several enable/disable patches have been
issues to devicetree's in both the kernel and u-boot to address
this issue.

What really happened however, was that the AXP209 shuts down without
a notice and without setting an interrupt. This is caused when LDO3
gets overloaded, for example with large capacitors on the LDO3 output.

Normally, we would expect that AXP209 would source 200 mA as per
datasheet and set and trigger an interrupt when being overloaded.
For some reason however, this does not happen.

As a work-around, we use the soft-start constraint of the regulator
node to first bring up the LDO3 to the lowest possible voltage and
then enable the LDO. After that, we can set the requested voltage
as usual.

Combining this setting with the regulator-ramp-delay allows LDO3 to
enable voltage slowly and staggered, potentially reducing overall
inrush current.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-13 16:39:55 +00:00
Olliver Schinagl d29f54df8b
regulator: axp20x: add support for set_ramp_delay for AXP209
The AXP209 supports ramping up voltages on several regulators such as
DCDC2 and LDO3.

This patch adds preliminary support for the regulator-ramp-delay property
for these 2 regulators. Note that the voltage ramp only works when
regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V.

When turning on the regulator, no voltage ramp is performed in hardware.

What this means, is that if the bootloader brings up the voltage at 0.7 V,
the ramp delay property is properly applied. If however, the bootloader
leaves the power off, no ramp delay is applied when the power is
enabled by the regulator framework.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-13 16:39:53 +00:00
Mark Brown c33c83354c
Merge branch 'topic/axp20x' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.21 2018-12-13 16:37:11 +00:00
Andrei.Stefanescu@microchip.com 919261c03e
regulator: mcp16502: add regulator driver for MCP16502
This patch adds a regulator driver for the MCP16502 PMIC.
This drivers supports basic operations through the
regulator interface such as:
- setting/reading voltage
- setting/reading operating mode
- reading current status

Signed-off-by: Andrei Stefanescu <andrei.stefanescu@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-13 12:19:04 +00:00
Claudiu Beznea b5ebba46e6
regulator: act8945a-regulator: add shutdown function
Implement shutdown method to make sure the PMIC will not enter the suspend
state when the system is shutdown.

This work is based on work done by Borris Brezillon on [1].

[1] https://www.spinics.net/lists/kernel/msg2942960.html

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-12 16:59:35 +00:00
Claudiu Beznea 03ffbf9c08
regulator: act8945a-regulator: fix line over 80 chars warning
Fix line over 80 chars checkpatch.pl warning.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-12 16:59:19 +00:00
Boris Brezillon 7482d6ecc6
regulator: act8945a-regulator: Implement PM functionalities
The regulator supports a dedicated suspend mode.
Implement the appropriate ->set_suspend_xx() hooks, add support for
->set_mode(), and provide basic PM ops functionalities to setup the
regulator in a suspend state when the system is entering suspend.

Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
[claudiu.beznea@microchip.com: remove shutdown function, use dev_pm_ops,
 fix checkpatch warning, adapt commit message, add LDO modes support,
 move modes constants to active-semi,8945a-regulator.h, remove rdevs from
 struct act8945a_pmic, add op_mode to act8945a_pmic]
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-12 16:59:04 +00:00
Claudiu Beznea 90bc8ac220
regulator: act8945a-regulator: unlock expert registers
Unlock expert registers for act8945a.
This is based on orginal work of Boris Brezillon at [1].

[1] https://www.spinics.net/lists/kernel/msg2942960.html

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-12 16:57:44 +00:00
Linus Walleij f306d76082
regulator: arizona-ldo1: Rely on core to handle GPIO descriptor
After making sure that the regulator core always take over
handling of the GPIO descriptors, the gpiod_put()
on the errorpath of the Arizona LDO1 driver becomes
redundant.

Reported-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-12 16:49:36 +00:00
Linus Walleij daa531db8a
regulator: wm8994: Rely on core to handle GPIO descriptor
After making sure that the regulator core always take over
handling of the GPIO descriptors, the gpiod_put()
on the errorpath of the wm8994 driver becomes redundant.

Reported-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-12 16:47:10 +00:00
Douglas Anderson 05f224ca66
regulator: core: Clean enabling always-on regulators + their supplies
At the end of regulator_resolve_supply() we have historically turned
on our supply in some cases.  This could be for one of two reasons:

1. If resolving supplies was happening before the call to
   set_machine_constraints() we needed to predict if
   set_machine_constraints() was going to turn the regulator on and we
   needed to preemptively turn the supply on.
2. Maybe set_machine_constraints() happened before we could resolve
   supplies (because we failed the first time to resolve) and thus we
   might need to propagate an enable that already happened up to our
   supply.

Historically regulator_resolve_supply() used _regulator_is_enabled()
to decide whether to turn on the supply.

Let's change things a little bit.  Specifically:

1. Let's try to enable the supply and the regulator in the same place,
   both in set_machine_constraints().  This means that we have exactly
   the same logic for enabling the supply and the regulator.
2. Let's properly set use_count when we enable always-on or boot-on
   regulators even for those that don't have supplies.  The previous
   commit 1fc12b0589 ("regulator: core: Avoid propagating to
   supplies when possible") only did this right for regulators with
   supplies.
3. Let's make it clear that the only time we need to enable the supply
   in regulator_resolve_supply() is if the main regulator is currently
   in use.  By using use_count (like the rest of the code) to decide
   if we're going to enable our supply we keep everything consistent.

Overall the new scheme should be cleaner and easier to reason about.
In addition to fixing regulator_summary to be more correct (because of
the more correct use_count), this change also has the effect of no
longer using _regulator_is_enabled() in this code path.
_regulator_is_enabled() could return an error code for some regulators
at bootup (like RPMh) that can't read their initial state.  While one
can argue that the design of those regulators is sub-optimal, the new
logic sidesteps this brokenness.  This fix in particular fixes
observed problems on Qualcomm sdm845 boards which use the
above-mentioned RPMh regulator.  Those problems were made worse by
commit 1fc12b0589 ("regulator: core: Avoid propagating to supplies
when possible") because now we'd think at bootup that the SD
regulators were already enabled and we'd never try them again.

Fixes: 1fc12b0589 ("regulator: core: Avoid propagating to supplies when possible")
Reported-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 20:45:00 +00:00
Mark Brown e6202e8249
Merge branch 'for-linus' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.21 2018-12-11 20:44:49 +00:00
Mark Brown d407c81ada
Merge branch 'regulator-4.20' into regulator-linus 2018-12-11 01:17:23 +00:00
Linus Walleij 2b96edb570
regulator: s2mps11: Hand over GPIO to regulator core
The GPIO descriptors used by the S2MPS11 driver are retrieved
during probe() and it is really helpful to have those under
devres management because of all the errorpaths in the
intialization.

Using the new dev_gpiod_unhinge() call we can remove the
devres management of the descriptor right before handing
it over to the regulators core.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:05:00 +00:00
Linus Walleij 870311e52b
regulator: tps65090: Hand over GPIO to regulator core
The GPIO descriptors used by the TPS65090 driver are retrieved
during probe() and it is really helpful to have those under
devres management because of all the errorpaths in the
intialization.

Using the new dev_gpiod_unhinge() call we can remove the
devres management of the descriptor right before handing
it over to the regulators core.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:04:56 +00:00
Linus Walleij 1f5163fcf1
regulator: s5m8767: Hand over GPIO to regulator core
The GPIO descriptors used by the S5M8767 driver are retrieved
during probe() and it is really helpful to have those under
devres management because of all the errorpaths in the
intialization.

Using the new dev_gpiod_unhinge() call we can remove the
devres management of the descriptor right before handing
it over to the regulators core.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:04:43 +00:00
Linus Walleij b23328d76d
regulator: da9211: Hand over GPIO to regulator core
The GPIO descriptors used by the DA9211 driver are retrieved
during probe() and it is really helpful to have those under
devres management because of all the errorpaths in the
intialization.

Using the new dev_gpiod_unhinge() call we can remove the
devres management of the descriptor right before handing
it over to the regulators core.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:04:37 +00:00
Linus Walleij 48bd226f0a
regulator: max8973: Let core handle GPIO descriptor
The probe path of this driver is a bit complex: sometimes the
GPIO descriptor is passed to the regulator core, sometimes
it is not.

To handle it in a simple way: stick with the devm_* resource
management and unhinge the GPIO descriptor devres handling
right before passing it to the regulator core, if we pass it
to the regulator core.

Fixes: e7d2be696f ("regulator: max8973: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:04:31 +00:00
Linus Walleij d03c63dbca
regulator: max77686: Let core handle GPIO descriptor
Use the gpiod_get_from_of_node() rather than the devm_*
version so that the regulator core can handle the lifecycle
of these descriptors.

Fix up the errorpath so that we free this descriptor if
an error occurs in the callback. Rely on the regulator
core to deal with it after this point: a previous patch
fixed up the regulator core to properly dispose any
GPIO descriptors once you call regulator_register().

Fixes: 96392c3d8c ("regulator: max77686: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:04:08 +00:00
Linus Walleij 894077d5c8
regulator: max8952: Let core handle GPIO descriptor
Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.

Fixes: d7a261c2d1 ("regulator: max8952: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:03:59 +00:00
Linus Walleij 2bb8ede0b1
regulator: lp8788-ldo: Let core handle GPIO descriptor
Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.

Fixes: 2468f0d515 ("regulator: lp8788-ldo: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:03:54 +00:00
Linus Walleij e8a33aa0e3
regulator: lm363x: Let core handle GPIO descriptor
Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.

Fixes: b2d751b7f6 ("regulator: lm363x: Pass descriptor instead of GPIO number")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:03:49 +00:00
Linus Walleij 5e6f3ae5c1
regulator: fixed: Let core handle GPIO descriptor
Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.

Fixes: efdfeb079c ("regulator: fixed: Convert to use GPIO descriptor only")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:03:40 +00:00
Linus Walleij 0edb040d41
regulator: core: Track dangling GPIO descriptors
If a GPIO descriptor is passed to the regulator_register()
function inside the config->ena_gpiod callers must be
sure that once they call this API the regulator core
owns that descriptor and will make sure to issue
gpiod_put() on it, no matter whether the call is
successful or not.

For device tree regulators, the regulator core will
automatically set up regulator init data from the device
tree when registering a regulator by calling
regulator_of_get_init_data() which in turn calls down to
the regulator driver's .of_parse_cb() callback.
This callback (in drivers such as for max77686) may also
choose to fill in the config->ena_gpiod field with a GPIO
descriptor.

Harden the errorpath of regulator_register() to
properly gpiod_put() any passed in cfg->ena_gpiod
or any gpiod coming from the device tree on any type
of error.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-11 01:02:57 +00:00
Rob Herring c32569e358
regulator: Use of_node_name_eq for node name comparisons
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: Rob Herring <robh@kernel.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-06 19:56:51 +00:00
Charles Keepax eba9473f67
regulator: Allow regulator nodes to contain their own init data
Currently it is expected that regulator init data will be defined as a
series of sub-nodes from the node that bound in the driver. Add support
for a node to both bind in a driver and contain init data for that
regulator.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-04 16:41:38 +00:00
Charles Keepax 925c85e21e
regulator: Factor out location of init data OF node
To support future additions factor out the location of the OF node
containing the init data for the regulator from the code that parses the
init data.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-04 16:40:41 +00:00
Pascal PAILLET-LME db6e6244cb
regulator: stpmic1: fix regulator_lock usage
fix a compilation issue due to regulator_lock usage.

Signed-off-by: Pascal Paillet <p.paillet@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-03 11:39:24 +00:00
Olliver Schinagl db4a555f7c
regulator: axp20x: use defines for masks
The AXP20X driver currently has several masks defined throughout the
code. Use nice defines to make them clean and more descriptive.

Additionally include bitops.h, which was missing before, and sort
headers.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-28 09:55:16 +00:00
Douglas Anderson fa94e48e13
regulator: core: Apply system load even if no consumer loads
Prior to commit 5451781dad ("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: 5451781dad ("regulator: core: Only count load for enabled consumers")
Reported-by: Brian Masney <masneyb@onstation.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Brian Masney <masneyb@onstation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-26 17:09:40 +00:00
Olliver Schinagl 2bb1666369
regulator: core: enable power when setting up constraints
When a regulator is marked as always on, it is enabled early on, when
checking and setting up constraints. It makes the assumption that the
bootloader properly initialized the regulator, and just in case enables
the regulator anyway.

Some constraints however currently get missed, such as the soft-start
and ramp-delay. This causes the regulator to be enabled, without the
soft-start and ramp-delay being applied, which in turn can cause
high-currents or other start-up problems.

By moving the always-enabled constraints later in the constraints check,
we can at least ensure all constraints for the regulator are followed.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-26 16:39:24 +00:00
Douglas Anderson 1fc12b0589
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 f8702f9e4a ("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>
2018-11-22 14:38:12 +00:00
Douglas Anderson 5451781dad
regulator: core: Only count load for enabled consumers
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: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-22 14:38:00 +00:00
Charles Keepax 466affa067
regulator: wm8994: Don't use devres for enable GPIOs
The regulator core takes over managing the lifetime of the enable GPIO
once the regulator is registered. As such we shouldn't register the
enable GPIO using devm, or it will be freed twice.

Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-21 12:43:37 +00:00
Douglas Anderson 8ff00ba792
regulator: core: Don't double-disable supplies in regulator_disable_deferred()
In the commit f8702f9e4a ("regulator: core: Use ww_mutex for
regulators locking") disabling of the supply was moved into
_regulator_disable().  That means regulator_disable_work() shouldn't
be disabling since that double-disables the supply.

Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-20 17:07:50 +00:00
Douglas Anderson 7b51a82121
regulator: core: Properly expose requested_microamps in sysfs
The "requested_microamps" sysfs attribute was only being exposed for
"current" regulators.  This didn't make sense.  Allow it to be exposed
always.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-20 16:00:43 +00:00
Charles Keepax d90acbc4e3
regulator: lochnagar: Move driver to binding from DT
Based on review comments on the MFD driver, move the child drivers for
the Lochnagar MFD over to binding through device tree.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-20 15:45:09 +00:00
Marek Szyprowski d7c7fc442f
regulator: s2mps11: Fix GPIO descriptor initialization
GPIO descriptor array must be zero initialized to ensure that core will
properly handle also the case when no external GPIO pin is defined.

Fixes: 1c984942f0 ("regulator: s2mps11: Pass descriptor instead of GPIO number")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-20 15:25:40 +00:00