linux-toradex.git/drivers/regulator/s2mps11.c, branch v6.16

regulator: s2mps11: Add support for S2MPU05 regulators

2025-03-13T12:38:52+00:00

S2MPU05 is a PMIC by manufactured by Samsung, particularly used in
Exynos7870 based devices. Add driver support for controlling its 21 LDO
and 5 BUCK regulators.

Signed-off-by: Kaustabh Chakraborty 
Acked-by: Mark Brown 
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20250301-exynos7870-pmic-regulators-v3-3-808d0b47a564@disroot.org
Signed-off-by: Lee Jones

regulator: s2mps11: use scoped memory allocation to simplify probe

2024-08-22T16:52:31+00:00

Allocate the memory with scoped/cleanup.h to reduce error handling (less
error paths) and make the code a bit simpler.

Signed-off-by: Krzysztof Kozlowski 
Link: https://patch.msgid.link/20240822161231.106744-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14

2023-03-20T13:11:25+00:00

Probing of regulators can be a slow operation and can contribute to
slower boot times. This is especially true if a regulator is turned on
at probe time (with regulator-boot-on or regulator-always-on) and the
regulator requires delays (off-on-time, ramp time, etc).

While the overall kernel is not ready to switch to async probe by
default, as per the discussion on the mailing lists [1] it is believed
that the regulator subsystem is in good shape and we can move
regulator drivers over wholesale. There is no way to just magically
opt in all regulators (regulators are just normal drivers like
platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all
regulators found in 'drivers/regulator' individually.

Given the number of drivers touched and the impossibility to test this
ahead of time, it wouldn't be shocking at all if this caused a
regression for someone. If there is a regression caused by this patch,
it's likely to be one of the cases talked about in [1]. As a "quick
fix", drivers involved in the regression could be fixed by changing
them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix
would be to directly fix the problem that caused the issue with async
probe.

The approach here follows a similar approach that was used for the mmc
subsystem several years ago [2]. In fact, I ran nearly the same python
script to auto-generate the changes. The only thing I changed was to
search for "i2c_driver", "spmi_driver", and "spi_driver" in addition
to "platform_driver".

[1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk
[2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/

Signed-off-by: Douglas Anderson
Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid
Signed-off-by: Mark Brown

regulator: s2mps11: Drop initialization via platform data

2021-04-21T14:51:43+00:00

None of the platforms with S2MPS11 use board files, so any
initialization via platform data can be safely removed.

Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20210420170244.13467-5-krzysztof.kozlowski@canonical.com
Signed-off-by: Mark Brown

regulator: use linear_ranges helper

2020-05-08T17:18:13+00:00

Change the regulator helpers to use common linear_ranges code.

Signed-off-by: Matti Vaittinen 
Reviewed-by: Mark Brown 
Acked-by: Charles Keepax 
Acked-by: Adam Thomson 
Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown

regulator: samsung: Rename Samsung to lowercase

2020-01-06T20:47:42+00:00

Fix up inconsistent usage of upper and lowercase letters in "Samsung"
name.

"SAMSUNG" is not an abbreviation but a regular trademarked name.
Therefore it should be written with lowercase letters starting with
capital letter.

Although advertisement materials usually use uppercase "SAMSUNG", the
lowercase version is used in all legal aspects (e.g. on Wikipedia and in
privacy/legal statements on
https://www.samsung.com/semiconductor/privacy-global/).

Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200103171131.9900-20-krzk@kernel.org
Signed-off-by: Mark Brown

regulator: s2mps11: switch to using devm_fwnode_gpiod_get

2019-10-07T13:02:06+00:00

devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.

Let's switch this driver over.

Signed-off-by: Dmitry Torokhov 
Link: https://lore.kernel.org/r/20191004231017.130290-5-dmitry.torokhov@gmail.com
Reviewed-by: Linus Walleij 
Signed-off-by: Mark Brown

regulator: s2mps11: Consistently use local variable

2019-09-10T10:03:30+00:00

The value under 's2mps11->ext_control_gpiod[i]' is assigned to local
variable and used in probe in one place before.  Use it consistently
later so code will be easier to read.

Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20190909155723.24734-1-krzk@kernel.org
Signed-off-by: Mark Brown

Merge branch 'regulator-5.3' into regulator-next

2019-07-04T16:34:32+00:00

regulator: s2mps11: Adjust supported buck voltages to real values

2019-07-02T11:43:25+00:00

The driver was registering buck regulators with unsupported range of
voltages for S2MPS11 devices.  Basically it assumed that all 256 values
are possible for a single 8-bit I2C register controlling buck's voltage.
This is not true, as datasheet describes subset of these which can be
used.

For example for buck[12346] the minimum voltage is 650 mV which
corresponds to register value of 0x8.  The driver was however
registering regulator starting at 600 mV, so for a step of 6.25 mV this
gave the same result.  However this allowed to try to configure
regulators to unsupported values.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Mark Brown