This contains a bunch of cleanups and simplifications across the board,
as well as a number of small fixes.
Perhaps the most notable change here is the addition of an API that
allows PWMs to be used in atomic contexts, which is useful when time-
critical operations are involved, such as using a PWM to generate IR
signals.
Finally, I have decided to step down as PWM subsystem maintainer. Due to
other responsibilities I have lately not been able to find the time that
the subsystem deserves and Uwe, who has been helping out a lot for the
past few years and has many things planned for the future, has kindly
volunteered to take over. I have no doubt that he will be a suitable
replacement.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmWhYQAZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zobK8EACtzJX+AeoTkN2S671A7QoG
IGl9mrFhvrqN/6syigAIU8ZGOgb5uScZDH58PeTXH/oGEMn+bhQ9MK7JyWF5BUzF
I8p6CqaVjG66LsfWz1m8AEAl/0N2Sc2032fWQSJB0o8qgYH0ZRBKc1j371Zm2DgD
HT78pZJDSnyCnltPKjbDLShRfBwGINspmbihZKFa6yxrPbvADixCTo19b9Pk8XGa
S9k2R/9S/QKPxvB+3DiZAHFstwoTn2p+1IBsg+hp/jLniw8XidZp2Rq0RJuwTjqO
jVQDnOFOqNBa3VQccvNe23rDaKUkrmYwk+zzuFF27URam2Gp9wHZ8Y86WPSO5TA9
ftNsoeW++R25PBsOVZFGMU9r9aI9XI1tNyVuv2blNc0yr1fNSRzwjcELzLzG2myp
gHgdayJofnvlKM7JV5ZDY6BDPwTP9jfDRdZOqKKNUeB8e9IiQD9JtAV9P+EL/5Hl
C+7mh5Xb17bVlczWHqNkTd89Omp+Eu2z5BMfJyiQWQ2lzZpxOkBwB0nrlPshZpPi
hz5IhsGjREkEfNV2qz/YDEyaj+CAYO8toitFGt5HeAYTftuG4WD49rHE5VQ8nhwg
P9XpWNFHK2EtpU3/BRuupWHZRVd7MU4kMx4WQvWZGOFEqc9DYaC29ynk6sK0ryaC
ba8U4gpBS66d3wNvVpkN3A==
=pIh8
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This contains a bunch of cleanups and simplifications across the
board, as well as a number of small fixes.
Perhaps the most notable change here is the addition of an API that
allows PWMs to be used in atomic contexts, which is useful when time-
critical operations are involved, such as using a PWM to generate IR
signals.
Finally, I have decided to step down as PWM subsystem maintainer. Due
to other responsibilities I have lately not been able to find the time
that the subsystem deserves and Uwe, who has been helping out a lot
for the past few years and has many things planned for the future, has
kindly volunteered to take over. I have no doubt that he will be a
suitable replacement"
* tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
MAINTAINERS: pwm: Thierry steps down, Uwe takes over
pwm: linux/pwm.h: fix Excess kernel-doc description warning
pwm: Add pwm_apply_state() compatibility stub
pwm: cros-ec: Drop documentation for dropped struct member
pwm: Drop two unused API functions
pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputs
pwm: meson: Simplify using dev_err_probe()
pwm: stmpe: Silence duplicate error messages
pwm: Reduce number of pointer dereferences in pwm_device_request()
pwm: crc: Use consistent variable naming for driver data
pwm: omap-dmtimer: Drop locking
dt-bindings: pwm: ti,pwm-omap-dmtimer: Update binding for yaml
media: pwm-ir-tx: Trigger edges from hrtimer interrupt context
pwm: bcm2835: Allow PWM driver to be used in atomic context
pwm: Make it possible to apply PWM changes in atomic context
pwm: renesas: Remove unused include
pwm: Replace ENOTSUPP with EOPNOTSUPP
pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
pwm: Stop referencing pwm->chip
pwm: Update kernel doc for struct pwm_chip
...
Previously, the sequence number in the regulator event subsystem was
updated without atomic operations, potentially leading to race
conditions. This commit addresses the issue by making the sequence
number atomic.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Link: https://msgid.link/r/20240104141314.3337037-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:
int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
int pwm_apply_atomic(struct pwm *, struct pwm_state *);
This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Merge series from Fenglin Wu <quic_fenglinw@quicinc.com>:
There are 2 PM8010 PMICs present in sm8550-mtp/sm8550-qrd boards and
each of them exposes 7 LDOs. Add RPMH regulator support for them.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
Changes in v2:
- Updated subject prefix in the dt-binding commit and fixed the typo.
- Separate the DTS commit with board name prefixes.
- Link to v1: https://lore.kernel.org/r/20231211-pm8010-regulator-v1-0-571e05fb4ecc@quicinc.com
---
Fenglin Wu (5):
regulator: qcom-rpmh: extend to support multiple linear voltage ranges
regulator: dt-bindings: qcom,rpmh: add compatible for pm8010
regulator: qcom-rpmh: add support for pm8010 regulators
arm64: dts: qcom: sm8550-mtp: Add pm8010 regulators
arm64: dts: qcom: sm8550-qrd: add PM8010 regulators
.../bindings/regulator/qcom,rpmh-regulator.yaml | 14 ++
arch/arm64/boot/dts/qcom/sm8550-mtp.dts | 120 ++++++++++++++
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 120 ++++++++++++++
drivers/regulator/qcom-rpmh-regulator.c | 177 ++++++++++++++++++---
4 files changed, 405 insertions(+), 26 deletions(-)
---
base-commit: 753e4d5c43
change-id: 20231205-pm8010-regulator-0348cb19087a
Best regards,
--
Fenglin Wu <quic_fenglinw@quicinc.com>
Add RPMH regulators exposed by Qualcomm Technologies, Inc. PM8010
PMIC. It has 7 LDOs with 3 different types, LDO1 - LDO2 are L502
NMOS LDOs, LDO5 and LDO7 are L502 PMOS LDOs, LDO3/LDO4/LDO6 are
L502 PMOS LDO for low noise applications. Also, LDO3 - LDO7 don't
support LPM.
Suggested-by: David Collins <quic_collinsd@quicinc.com>
Reviewed-by: David Collins <quic_collinsd@quicinc.com>
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Link: https://msgid.link/r/20231214-pm8010-regulator-v2-3-82131df6b97b@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Update rpmh_vreg_hw_data to support multiple linear voltage ranges for
potential regulators which have discrete voltage program ranges.
Suggested-by: David Collins <quic_collinsd@quicinc.com>
Reviewed-by: David Collins <quic_collinsd@quicinc.com>
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Link: https://msgid.link/r/20231214-pm8010-regulator-v2-1-82131df6b97b@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/1f7bbc545829a1cc3df40be0424fe46d7449fb72.1701778038.git.u.kleine-koenig@pengutronix.de
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/d9954f02ae51b1b0b0077c710d16bfaeafa216ec.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/89c5f261707bf178e1508cf5dd55121f0da2dc3f.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/ced2a73a1aeca3f33d4b194e4dbe2672ad84a50a.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/2e96cf99c8d97b728d891a745e8f94ee39fbfee8.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/fcaa42d7dd707031ed8dd9e8c28483891b879965.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/639e796b36815a219ff1172cc758ba7378211d74.1701778038.git.u.kleine-koenig@pengutronix.de
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/76c7af01e2c8b3ab6585a04bc3f0d163fbb7fdf7.1701778038.git.u.kleine-koenig@pengutronix.de
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit introduces netlink event support to the regulator subsystem.
Changes:
- Introduce event.c and regnl.h for netlink event handling.
- Implement reg_generate_netlink_event to broadcast regulator events.
- Update Makefile to include the new event.c file.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Dang Huynh <danct12@riseup.net>:
PM8937 is a power management IC. It is used in various boards with
MSM8917, MSM8937, MSM8940 and APQ variants.
Pointer pdata is being initialized with a value that is never read. It is
being re-assigned later on with the return from a devm_kzalloc call.
Remove the redundant initialization, cleans up clang scan build warning:
drivers/regulator/palmas-regulator.c:1597:36: warning: Value stored
to 'pdata' during its initialization is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20231111195330.338324-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The use_count of a regulator should only be incremented when the
enable_count changes from 0 to 1. Similarly, the use_count should
only be decremented when the enable_count changes from 1 to 0.
In the previous implementation, use_count was sometimes decremented
to 0 when some consumer called unbalanced disable,
leading to unexpected disable even the regulator is enabled by
other consumers. With this change, the use_count accurately reflects
the number of users which the regulator is enabled.
This should make things more robust in the case where a consumer does
leak references.
Signed-off-by: Rui Zhang <zr.zhang@vivo.com>
Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This may be useful for debugging and develompent purposes, when there are
drivers that depend on regulators to be enabled but do not request them.
It is inspired from the clk_ignore_unused and pd_ignore_unused parameters,
that are used to keep firmware-enabled clocks and power domains on even if
these are not used by drivers.
The parameter is not expected to be used in normal cases and should not be
needed on a platform with proper driver support.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20231107190926.1185326-1-javierm@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add 'uv_survival_time' field to regulation_constraints for specifying
survival time post critical under-voltage event. Update the regulator
notifier call chain and Device Tree property parsing to use this new
field, allowing a configurable timeout before emergency shutdown.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Handle under-voltage events for crucial regulators to maintain system
stability and avoid issues during power drops.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-3-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM8937 is found on boards with MSM8917, MSM8937, MSM8940 SoCs and
APQ variants.
It provides 6 SMPS (two are controlled by SPMI) and 23 LDO regulators.
Signed-off-by: Dang Huynh <danct12@riseup.net>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231106-pm8937-v1-5-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>
Utilize the integrated 10-bit ADC in Max5970/Max5978 to enable voltage
and current monitoring. This feature is seamlessly integrated through
the hwmon subsystem.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20231027152830.1269895-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The type of the smps4 regulator from pm8550ve is actually FTSMPS525
medium voltage. So fix it accordingly.
Fixes: e6e3776d68 ("regulator: qcom-rpmh: Add support for PM8550 regulators")
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20231024134626.2364426-1-abel.vesa@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support from RPMH regulators found in PMC8380 for SC8380XP platform.
Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com>
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231025135550.13162-3-quic_sibis@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add interrupt support for under-voltage notification. This functionality
can be used on systems capable to detect under-voltage state and having
enough capacity to let the SoC do some emergency preparation.
This change enforce default policy to shutdown system as soon as
interrupt is triggered.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231025084614.3092295-6-o.rempel@pengutronix.de
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>
Use preferred i2c_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/20231017203429.2699039-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If probe is reached, we've already matched the device and in the case of
DT matching, the struct device_node pointer will be set. Therefore, there
is no need to call of_match_device() in probe.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203507.2699826-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct da9063_regulators.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175207.work.576-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct da9062_regulators.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175330.work.066-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The DT bindings for MT6366 regulator defines the supply names for the
PMIC.
Add support for them by adding .supply_name field settings for each
regulator. The buck regulators each have their own supply whose name
can be derived from the regulator name. The LDOs have shared supplies.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-12-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When support for the MT6366 PMIC regulators was added, it was assumed
that it had the same functionality as MT6358. In reality there are
differences. A few regulators have different ranges, or were renamed
and repurposed, or removed altogether.
Add the 3 regulators that were missing from the original submission.
These are added for completeness. VSRAM_CORE is not used in existing
projects. VM18 and VMDDR feed DRAM related consumers, and are not used
in-kernel.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230928085537.3246669-11-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The VCN18 regulator on the MT6366 (only) actually has a wide
configurable range of voltages, even though its name suggests a fixed
output voltage.
Convert it from a fixed LDO to a configurable LDO. Its range of settings
is the same as the VM18 regulator, which is missing and will be added in
a subsequent patch.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-10-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The new MT6366 binding does away with the type prefix ("buck_", "ldo_")
in the regulator node names. This better matches the PMIC pin names.
Remaining underscores in names are also replaced with hyphens.
Drop the type prefixes and replace remaining underscores to match the
MT6366 binding.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-9-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The DT bindings for MT6358 regulator now defines the supply names for the
PMIC.
Add support for them by adding .supply_name field settings for each
regulator.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-8-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The (undocumented) possible values for the buck operating modes on the
MT6358 are the same as those on the MT6397, both for the device tree
bindings and the actual hardware register values.
Reuse the macros for the MT6397 PMIC in the MT6358 regulator driver by
including the mt6397-regulator.h binding header and replacing the
existing macros. This aligns it with other PMIC.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-7-wenst@chromium.org
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>
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 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>
When fixing a memory leak in commit d3c731564e ("regulator: plug
of_node leak in regulator_register()'s error path") it moved the
device_initialize() call earlier, but did not move the `dev->class`
initialization. The bug was spotted and fixed by reverting part of
the commit (in commit 5f4b204b6b "regulator: core: fix kobject
release warning and memory leak in regulator_register()") but
introducing a different bug: now early error paths use `kfree(dev)`
instead of `put_device()` for an already initialized `struct device`.
Move the missing assignments to just after `device_initialize()`.
Fixes: d3c731564e ("regulator: plug of_node leak in regulator_register()'s error path")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/b5b19cb458c40c9d02f3d5a7bd1ba7d97ba17279.1695077303.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Chen-Yu Tsai <wenst@chromium.org>:
Hi,
This is v3 of the remainder of the MT6358 regulator driver cleanup
and improvement series. v1 can be found here [1]; v2 is here [2].
Changes since v2:
- Merged patches dropped
- Fixed up pickable linear ranges' selector values
- Collected tags
- Patch adding missing regulator definitions squashed into patch using
the definitions; recommended by Krzysztof on my MT6366 series.
- Remaining dts patch split out to be sent separately
Changes since v1:
- Merged patches dropped
- Added patch to move VCN33 regulator status sync after ID check
- Added patch to fix VCN33 sync fail error message
- Added patch to add missing register definitions
Various discrepancies were found while preparing to upstream MT8186
device trees, which utilize the MT6366 PMIC, that is also covered by
this driver.
Patches 1~3 should go through the regulator tree, and patch 4 through
the soc/mediatek tree.
** Note: patch 2 needs an ack from Lee for the mfd header change.
This v3 series can be seen as two parts. v1 had three parts, but one
part was fully merged, and then v2 gained another cleanup. v3 drops
the "fixing bogus regulators" part: driver changes are fully merged
and device tree change will be sent separately.
Part 1 - Robust chip ID checking (patch 1)
Angelo suggested making the driver fail to probe if an unexpected chip
ID was found. Patch 1 implements this.
Part 2 - Output voltage fine tuning support (patches 2, 3)
Many of the LDOs on these PMIC support an extra level of output voltage
fine tuning. Most default to no offset, but a couple have a non-zero
offset by default. Previously this was unaccounted for in the driver and
device tree constraints. On the outputs with non-zero offset, this ends
up becoming a discrepancy between the device tree and actual hardware.
These two patches adds support for this second level of tuning, modeled
as bunch of linear ranges. While it's unlikely we need this level of
control, it's nice to be able to read back the accurate hardware
settings.
Please have a look.
Thanks
ChenYu
[1] https://lore.kernel.org/linux-arm-kernel/20230609083009.2822259-1-wenst@chromium.org/
[2] https://lore.kernel.org/linux-mediatek/20230721082903.2038975-1-wenst@chromium.org/
Chen-Yu Tsai (3):
regulator: mt6358: Fail probe on unknown chip ID
regulator: mt6358: Add output voltage fine tuning to fixed regulators
regulator: mt6358: Add output voltage fine tuning to variable LDOs
drivers/regulator/mt6358-regulator.c | 304 ++++++++++++---------------
include/linux/mfd/mt6358/registers.h | 6 +
2 files changed, 144 insertions(+), 166 deletions(-)
--
2.42.0.283.g2d96d420d3-goog
