linux-toradex.git/drivers/regulator/qcom_spmi-regulator.c, branch v6.11 Linux kernel for Apalis and Colibri modules regulator: qcom_spmi: Add PM8937 SPMI regulator 2023-11-13T01:26:20+00:00 Dang Huynh danct12@riseup.net 2023-11-06T12:08:31+00:00 c0d6b2acf78e3195a6b100a236210f2e6e42b0c0 The PM8937 has 4 HFSMPS, 2 FTSMPS2.5 (for controlling APC voltage) and 23 LDO regulators. Add the configuration for this chip. Signed-off-by: Dang Huynh <danct12@riseup.net> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20231106-pm8937-v1-3-ec51d9eeec53@riseup.net Signed-off-by: Mark Brown <broonie@kernel.org> 
The PM8937 has 4 HFSMPS, 2 FTSMPS2.5 (for controlling APC voltage)
and 23 LDO regulators.
Add the configuration for this chip.

Signed-off-by: Dang Huynh <danct12@riseup.net>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231106-pm8937-v1-3-ec51d9eeec53@riseup.net
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: Use device_get_match_data() 2023-10-17T20:38:48+00:00 Rob Herring robh@kernel.org 2023-10-17T20:34:41+00:00 8f7e17d847edf6bc02d0813b123b9d78ba504098 Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231017203442.2699322-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> 
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.

Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203442.2699322-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: qcom_spmi: Add PMA8084 regulators 2023-09-26T15:42:35+00:00 Stephan Gerhold stephan@gerhold.net 2023-09-12T07:49:54+00:00 317aa3c4fe708fcbee5b9fe5fc25e1b9e92b83f5 Add the necessary definitions for the PMA8084 PMIC to the qcom_spmi-regulator driver to allow reading the actual voltages applied to the hardware at runtime. This is mainly intended for debugging since the regulators are usually controlled through the RPM firmware (via qcom_smd-regulator). Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-6-ba4b3bfaf87d@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org> 
Add the necessary definitions for the PMA8084 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-6-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: qcom_spmi: Add PM8019 regulators 2023-09-26T15:42:33+00:00 Stephan Gerhold stephan@gerhold.net 2023-09-12T07:49:52+00:00 5b30cb2a317a8e2636f724e8ebf5cbe3849e786e Add the necessary definitions for the PM8019 PMIC to the qcom_spmi-regulator driver to allow reading the actual voltages applied to the hardware at runtime. This is mainly intended for debugging since the regulators are usually controlled through the RPM firmware (via qcom_smd-regulator). Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-4-ba4b3bfaf87d@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org> 
Add the necessary definitions for the PM8019 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-4-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: qcom_spmi: Add PM8909 regulators 2023-09-26T15:42:32+00:00 Stephan Gerhold stephan.gerhold@kernkonzept.com 2023-09-12T07:49:50+00:00 813d01a40ae7c0c67681c82edce8463fbbd84b08 Add the necessary definitions for the PM8909 PMIC to the qcom_spmi-regulator driver to allow reading the actual voltages applied to the hardware at runtime. This is mainly intended for debugging since the regulators are usually controlled through the RPM firmware (via qcom_smd-regulator). Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-2-ba4b3bfaf87d@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org> 
Add the necessary definitions for the PM8909 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).

Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-2-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14 2023-03-20T13:11:25+00:00 Douglas Anderson dianders@chromium.org 2023-03-16T19:54:38+00:00 259b93b21a9ffe5117af4dfb5505437e463c6a5a 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 <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown <broonie@kernel.org> 
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 <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: qcom_spmi: Add PM6125 PMIC support 2022-08-23T17:07:56+00:00 Iskren Chernev iskren.chernev@gmail.com 2022-08-02T22:11:08+00:00 e62ef4a9f936326e702ef08ea3f65b62bd7d108b Add support for PM6125 PMIC which is found on SM4250/6115 SoCs. S1, S2, S3, S4, S8 are FTS+FTSMPS_510, rev 2 - range is 0.3-1.372V by 4mV increments S5, S6, s7 are BUCK+HFSMPS_510, rev 4 - range is 0.32-2.04V by 8mV increment L1, L3, L7 are LDO+N600_510, rev 2 L2, L4, L8, L17, L18 are LDO+N300_510, rev 2 L6 is LDO+N1200_510, rev 2 - range is 0.32-1.304V by 8mV increment L5 is LDO+MV_P50_510, rev 2 L15, L19, L20 are LDO+MV_P150_510, rev 2 L21, L22, L23, L24 are LDO+MV_P600_510, rev 2 - range is 1.504-3.544V by 8mV increment L9, L11, L14 are LDO+LV_P600_510, rev 2 L10, L16 are LDO+LV_P150_510, rev 2 L12, L13 are LDO+LV_P300_510, rev 2 - range 1.504-2V by 8mV increment Signed-off-by: Adam Skladowski <a39.skl@gmail.com> Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220802221112.2280686-10-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Add support for PM6125 PMIC which is found on SM4250/6115 SoCs.

S1, S2, S3, S4, S8 are FTS+FTSMPS_510, rev 2
- range is 0.3-1.372V by 4mV increments
S5, S6, s7 are BUCK+HFSMPS_510, rev 4
- range is 0.32-2.04V by 8mV increment
L1, L3, L7 are LDO+N600_510, rev 2
L2, L4, L8, L17, L18 are LDO+N300_510, rev 2
L6 is LDO+N1200_510, rev 2
- range is 0.32-1.304V by 8mV increment
L5 is LDO+MV_P50_510, rev 2
L15, L19, L20 are LDO+MV_P150_510, rev 2
L21, L22, L23, L24 are LDO+MV_P600_510, rev 2
- range is 1.504-3.544V by 8mV increment
L9, L11, L14 are LDO+LV_P600_510, rev 2
L10, L16 are LDO+LV_P150_510, rev 2
L12, L13 are LDO+LV_P300_510, rev 2
- range 1.504-2V by 8mV increment

Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220802221112.2280686-10-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: qcom_spmi: Sort pmics alphabetically (part 2) 2022-08-23T17:07:55+00:00 Iskren Chernev iskren.chernev@gmail.com 2022-08-02T22:11:07+00:00 9a2da0749ce37d4a74f7becf3b09bf2e0169145a The sorting is split in multiple commits for easier reviewing. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-9-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The sorting is split in multiple commits for easier reviewing.

Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-9-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: qcom_spmi: Sort pmics alphabetically (part 1) 2022-08-23T17:07:54+00:00 Iskren Chernev iskren.chernev@gmail.com 2022-08-02T22:11:06+00:00 046d7e3246ac028bfe583b4c3bed9530a80004c4 The sorting is split in multiple commits for easier reviewing. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-8-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The sorting is split in multiple commits for easier reviewing.

Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-8-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: qcom_spmi: Add support for LDO_510 and FTSMPS 2022-08-23T17:07:53+00:00 Iskren Chernev iskren.chernev@gmail.com 2022-08-02T22:11:05+00:00 0d1cf568b4e0c65cb533fef2c116fb2883803c53 Add support for LDO_510 and FTSMPS3 regulators, all belonging to register layout HFSMPS. This is done in preparation for adding support for the PM6125 PMIC. For FTSMPS3 and LDO_510, only IDLE and NORMAL modes are selectable (no FAST). The inspiration for the magic constants was taken from [1] [1]: https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5 Signed-off-by: Adam Skladowski <a39.skl@gmail.com> Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-7-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Add support for LDO_510 and FTSMPS3 regulators, all belonging to register
layout HFSMPS. This is done in preparation for adding support for the
PM6125 PMIC.

For FTSMPS3 and LDO_510, only IDLE and NORMAL modes are selectable (no
FAST).

The inspiration for the magic constants was taken from [1]

[1]: https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5

Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-7-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>