summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2020-12-01regulator: da9121: Add device variant regmapsAdam Ward
Add ability to probe device and validate configuration, then apply a regmap configuration for a single or dual buck device accordingly. Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/068c6b8d5e1b4e221e899e4c914c429429a2ec7d.1606755367.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-01regulator: da9121: Add device variantsAdam Ward
Add basic support for configuration to reference variants of this device, and track the selected variant within the driver. Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/aaabd3063593e5172fa6b605884d475df64e6d65.1606755367.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-01regulator: da9121: Add header fileAdam Ward
Add header file for Dialog Semiconductor DA9121 regulator and related devices, mostly autogenerated from the chip design databases, and update driver to replace local defines with those from header. Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/3527d84448d1e6ddc0fcb883ae564880f75a6cb0.1606755367.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-30regulator: Add NXP PF8X00 regulator driverJagan Teki
Add NXP PF8100/PF8121A/PF8200 regulator driver. PF8100/PF8121A/PF8200 is PMIC designed for highperformance consumer applications. It features seven high efficiency buck, four linear and one vsnvs regulators. Tested in Engicam i.Core MX8M Mini SOM platform boards. Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Link: https://lore.kernel.org/r/20201130112329.104614-2-jagan@amarulasolutions.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-26regulator: qcom-rpmh: Add support for SDX55Vinod Koul
Add support from RPMH regulators found in SDX55 platform Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201126093018.1085594-2-vkoul@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-26regulator: core: return zero for selectors lower than linear_min_selClaudiu Beznea
Selectors lower than linear_min_sel should not be considered invalid. Thus return zero in case _regulator_list_voltage(), regulator_list_hardware_vsel() or regulator_list_voltage_table() receives such selectors as argument. Fixes: bdcd1177578c ("regulator: core: validate selector against linear_min_sel") Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1606325147-606-1-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-24regulator: Kconfig: Fix REGULATOR_QCOM_RPMH dependencies to avoid build errorJohn Stultz
The kernel test robot reported the following build error: All errors (new ones prefixed by >>): xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_vrm_get_voltage_sel': qcom-rpmh-regulator.c:(.text+0x270): undefined reference to `rpmh_write' xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_send_request': qcom-rpmh-regulator.c:(.text+0x2f2): undefined reference to `rpmh_write' xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_vrm_get_voltage_sel': >> qcom-rpmh-regulator.c:(.text+0x274): undefined reference to `rpmh_write_async' xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_send_request': qcom-rpmh-regulator.c:(.text+0x2fc): undefined reference to `rpmh_write_async' Which is due to REGULATOR_QCOM_RPMH depending on QCOM_RPMH || COMPILE_TEST. The problem is that QOM_RPMH can now be a module, which in that case requires REGULATOR_QCOM_RPMH=m to build. However, if COMPILE_TEST is enabled, REGULATOR_QCOM_RPMH can be set to =y while QCOM_RPMH=m which will cause build failures. The fix here is to add (QCOM_RPMH=n && COMPILE_TEST) to the dependency. Feedback would be appreciated! Cc: Todd Kjos <tkjos@google.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rajendra Nayak <rnayak@codeaurora.org> Cc: Maulik Shah <mkshah@codeaurora.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-arm-msm@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20201123222359.103822-1-john.stultz@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-23regulator: add SCMI driverCristian Marussi
Add a simple regulator based on SCMI Voltage Domain Protocol. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> ---- v6 --> v7 - add proper blank lines between semantic blocks - fix return value on error path of scmi_reg_is_enabled() - use generic Failure message on err path of info_get() - fix comment containing apostrophe v3 --> v4 - using of_match_full_name core regulator flag - avoid coccinelle falde complaints about pointer-sized allocations v2 --> v3 - remove multiple linear mappings support - removed duplicated voltage name printout - added a few comments - simplified return path in scmi_reg_set_voltage_sel() v1 --> v2 - removed duplicate regulator naming - removed redundant .get/set_voltage ops: only _sel variants implemented - removed condexpr on fail path to increase readability v0 --> v1 - fixed init_data constraint parsing - fixes for v5.8 (linear_range.h) - fixed commit message content and subject line format - factored out SCMI core specific changes to distinct patch - reworked Kconfig and Makefile to keep proper alphabetic order - fixed SPDX comment style - removed unneeded inline functions - reworked conditionals for legibility - fixed some return paths to properly report SCMI original errors codes - added some more descriptive error messages when fw returns invalid ranges - removed unneeded explicit devm_regulator_unregister from .remove() Link: https://lore.kernel.org/r/20201123202336.46701-4-cristian.marussi@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-23Merge series "Add support for SCMIv3.0 Voltage Domain Protocol and ↵Mark Brown
SCMI-Regulator" from Cristian Marussi <cristian.marussi@arm.com>: Hi, this series introduces the support for the new SCMI Voltage Domain Protocol defined by the upcoming SCMIv3.0 specification, whose BETA release is available at [1]. Afterwards, a new generic SCMI Regulator driver is developed on top of the new SCMI VD Protocol. In V4 Patch 3/5 introduced a needed fix in Regulator framework to cope with generic named nodes. The series is currently based on for-next/scmi [2] on top of: commit b141fca08207 ("firmware: arm_scmi: Fix missing destroy_workqueue()") Any feedback welcome, Thanks, Cristian --- v5 --> v6 - reordered dt bindings patch - removed single field struct - reviewed args to scmi_init_voltage_levels() - allocating scmi_voltage_info_array contiguously v4 --> v5 - rebased - VD Protocol - removed inline - moved segmented intervals defines - fixed some macros complaints by checkpatch v3 --> v4 - DT bindings - using generic node names - listing explicitly subset of supported regulators bindings - SCMI Regulator - using of_match_full_name core regulator flag - avoid coccinelle false flag complaints - VD Protocol - avoid coccinelle false flag complaints - avoiding fixed size typing v2 --> v3 - DT bindings - avoid awkard examples based on _cpu/_gpu regulators - SCMI Regulator - remove multiple linear mappings support - removed duplicated voltage name printout - added a few comments - simplified return path in scmi_reg_set_voltage_sel() - VD Protocol - restrict segmented voltage domain descriptors to one triplet - removed unneeded inline - free allocated resources for invalid voltage domain - added __must_check to info_get voltage operations - added a few comments - removed fixed size typing from struct voltage_info v1 --> v2 - rebased on for-next/scmi v5.10 - DT bindings - removed any reference to negative voltages - SCMI Regulator - removed duplicate regulator naming - removed redundant .get/set_voltage ops: only _sel variants implemented - removed condexpr on fail path to increase readability - VD Protocol - fix voltage levels query loop to reload full cmd description between iterations as reported by Etienne Carriere - ensure transport rx buffer is properly sized calli scmi_reset_rx_to_maxsz between transfers [1]:https://developer.arm.com/documentation/den0056/c/ [2]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi Cristian Marussi (5): firmware: arm_scmi: Add Voltage Domain Support firmware: arm_scmi: add SCMI Voltage Domain devname regulator: core: add of_match_full_name boolean flag dt-bindings: arm: add support for SCMI Regulators regulator: add SCMI driver .../devicetree/bindings/arm/arm,scmi.txt | 43 ++ drivers/firmware/arm_scmi/Makefile | 2 +- drivers/firmware/arm_scmi/common.h | 1 + drivers/firmware/arm_scmi/driver.c | 3 + drivers/firmware/arm_scmi/voltage.c | 380 ++++++++++++++++ drivers/regulator/Kconfig | 9 + drivers/regulator/Makefile | 1 + drivers/regulator/of_regulator.c | 8 +- drivers/regulator/scmi-regulator.c | 409 ++++++++++++++++++ include/linux/regulator/driver.h | 3 + include/linux/scmi_protocol.h | 64 +++ 11 files changed, 920 insertions(+), 3 deletions(-) create mode 100644 drivers/firmware/arm_scmi/voltage.c create mode 100644 drivers/regulator/scmi-regulator.c -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2020-11-23regulator: as3722: Fix fall-through warnings for ClangGustavo A. R. Silva
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a fallthrough pseudo-keyword instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/c0efb81064f71837f19408f65b52d155103ee514.1605896059.git.gustavoars@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-23regulator: core: add of_match_full_name boolean flagCristian Marussi
During regulators registration, if .of_match and .regulators_node are defined as non-null strings in struct regulator_desc the core searches the DT subtree rooted at .regulators_node trying to match, at first, .of_match against the 'regulator-compatible' property and, then, falling back to use the name of the node itself to determine a good match. Property 'regulator-compatible', though, is now deprecated and falling back to match against the node name, works fine only as long as the involved nodes are named in an unique way across the searched subtree; if that's not the case, like when using <common-name>@<unit> style naming for properties indexed via 'reg' property (as advised by the standard), the above matching mechanism based on the simple common name will lead to multiple matches and the only viable alternative would be to properly define the now deprecated 'regulator-compatible' as the node full name, i.e. <common-name>@<unit>. In order to address this case without using such deprecated binding, define a new boolean flag .of_match_full_name in struct regulator_desc to force the core to match against the node full-name instead of the plain name. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20201119191051.46363-4-cristian.marussi@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-18regulator: ti-abb: Fix array out of bound read access on the first transitionNishanth Menon
At the start of driver initialization, we do not know what bias setting the bootloader has configured the system for and we only know for certain the very first time we do a transition. However, since the initial value of the comparison index is -EINVAL, this negative value results in an array out of bound access on the very first transition. Since we don't know what the setting is, we just set the bias configuration as there is nothing to compare against. This prevents the array out of bound access. NOTE: Even though we could use a more relaxed check of "< 0" the only valid values(ignoring cosmic ray induced bitflips) are -EINVAL, 0+. Fixes: 40b1936efebd ("regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver") Link: https://lore.kernel.org/linux-mm/CA+G9fYuk4imvhyCN7D7T6PMDH6oNp6HDCRiTUKMQ6QXXjBa4ag@mail.gmail.com/ Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20201118145009.10492-1-nm@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: core: do not continue if selector matchClaudiu Beznea
Do not continue if selector has already been located. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1605290164-11556-1-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13Merge series "regulator: mcp16502: add support for ramp delay" from Claudiu ↵Mark Brown
Beznea <claudiu.beznea@microchip.com>: Hi, This series adds support for ramp delay on mcp16502. It also adds some cleanup on mcp16502. Apart from that patches 1/6 fixes the selector validation in case the regulator::desc::linear_min_sel is not zero. Thank you, Claudiu Beznea Changes in v3: - fix compilation error in patch 5/6 Reported-by: kernel test robot <lkp@intel.com> Changes in v2: - rebase on top of regulator/for-next - checked 1/6 and 3/6 applies on top of regulator/for-5.10 Claudiu Beznea (6): regulator: core: validate selector against linear_min_sel regulator: core: do not continue if selector match regulator: mcp16502: add linear_min_sel regulator: mcp16502: adapt for get/set on other registers regulator: mcp16502: add support for ramp delay regulator: mcp16502: remove void documentation of struct mcp16502 drivers/regulator/core.c | 12 +++- drivers/regulator/helpers.c | 3 +- drivers/regulator/mcp16502.c | 135 ++++++++++++++++++++++++++++++++++++------- 3 files changed, 127 insertions(+), 23 deletions(-) -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2020-11-13regulator: core: validate selector against linear_min_selClaudiu Beznea
There are regulators who's min selector is not zero. Selectors loops (looping b/w zero and regulator::desc::n_voltages) might throw errors because invalid selectors are used (lower than regulator::desc::linear_min_sel). For this situations validate selectors against regulator::desc::linear_min_sel. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1605280870-32432-2-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: mcp16502: remove void documentation of struct mcp16502Claudiu Beznea
struct mcp16502 has no members called rdev or rmap. Remove the documentation. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1605280870-32432-7-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: mcp16502: add support for ramp delayClaudiu Beznea
MCP16502 have configurable ramp delay support (via DVSR bits in regulators' CFG register). Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1605280870-32432-6-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: mcp16502: adapt for get/set on other registersClaudiu Beznea
MCP16502 have multiple registers for each regulator (as described in enum mcp16502_reg). Adapt the code to be able to get/set all these registers. This is necessary for the following commits. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1605280870-32432-5-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: mcp16502: add linear_min_selClaudiu Beznea
Selectors b/w zero and VDD_LOW_SEL are not valid. Use linear_min_sel. Fixes: 919261c03e7ca ("regulator: mcp16502: add regulator driver for MCP16502") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1605280870-32432-4-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: debug early supply resolvingMichał Mirosław
Help debugging the case when set_machine_constraints() needs to be repeated. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/f9cba575580369e46661a9278ee6c6a8d8564c2a.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: workaround self-referent regulatorsMichał Mirosław
Workaround regulators whose supply name happens to be the same as its own name. This fixes boards that used to work before the early supply resolving was removed. The error message is left in place so that offending drivers can be detected. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/d703acde2a93100c3c7a81059d716c50ad1b1f52.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: avoid resolve_supply() infinite recursionMichał Mirosław
When a regulator's name equals its supply's name the regulator_resolve_supply() recurses indefinitely. Add a check so that debugging the problem is easier. The "fixed" commit just exposed the problem. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/c6171057cfc0896f950c4d8cb82df0f9f1b89ad9.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: fix memory leak with repeated set_machine_constraints()Michał Mirosław
Fixed commit introduced a possible second call to set_machine_constraints() and that allocates memory for rdev->constraints. Move the allocation to the caller so it's easier to manage and done once. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/78c3d4016cebc08d441aad18cb924b4e4d9cf9df.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-11Merge branch 'for-5.10' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-5.11
2020-11-11regulator: pfuze100: limit pfuze-support-disable-sw to pfuze{100,200}Sean Nyekjaer
Limit the fsl,pfuze-support-disable-sw to the pfuze100 and pfuze200 variants. When enabling fsl,pfuze-support-disable-sw and using a pfuze3000 or pfuze3001, the driver would choose pfuze100_sw_disable_regulator_ops instead of the newly introduced and correct pfuze3000_sw_regulator_ops. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Fixes: 6f1cf5257acc ("regualtor: pfuze100: correct sw1a/sw2 on pfuze3000") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201110174113.2066534-1-sean@geanix.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-10Merge series "regulator: bd718x7: support voltage scaling" from Matti ↵Mark Brown
Vaittinen <matti.vaittinen@fi.rohmeurope.com>: RFC for adding a support for typical voltage scaling connection In few occasions there has been a need to scale the voltage output from bucks on BD71837. Usually this is done when buck8 is used to power specific GPU which can utilize voltages down to 0.7V. As lowest the buck8 on BD71837 can go is 0.8V, and external connection is used to scale the voltages. The BD71837, BD71847 and BD71850 bucks can be adjusted by pulling up the feedback pin using suitable voltage/resistors. |---------------| | buck 8 |-------+----->Vout | | | |---------------| | | | | | +-------+--R2----+ | R1 | V FB-pull-up This will scale the voltage as follows: - Vout_o = Vo - (Vpu - Vo)*R2/R1 - Linear_step = step_orig*(R1+R2)/R1 where: Vout_o is adjusted voltage output at vsel reg value 0 Vo is original voltage output at vsel reg value 0 Vpu is the pull-up voltage V FB-pull-up in the picture R1 and R2 are resistor values. >From HW point of view this does not need to be limited to buck 8. This connection can be used to adjust output from any of the bucks on BD71837/47/50. As this seems to be a 'de-facto' way to scale the voltages on BD71837 it might be a good idea to support computing the new voltage ranges for bucks based on the V-pull-up and resistor R1/R2 values given from device-tree. This allows describing the external HW connection using DT to correctly scale the voltages. This RFC uses "rohm,feedback-pull-up-r1-ohms" and "rohm,feedback-pull-up-r2-ohms" to provide the resistor values - but these names (without the picture) might not be too descriptive. I am grateful for all suggestions as better and more descriptive names. This patch series is an RFC because this connection feels somewhat "hacky". OTOH - when hack becomes widely used, it is less of an hack and more of a standard - and occasionally supporting HW hacks using SW may benefit us all, right? :) The other thing some projects do is allowing the change of BD71837 buck8 voltages when buck8 is enabled. This however will introduce voltage spikes as buck8 was not originally designed for this. The specific HW platform must be evaluated to be able to tolerate these spikes. Thus this patch series does not support buck8 voltage changes when buck8 is enabled. I wonder if this should be allowed per some config option(?) I don't want to help people frying their boards... Opinions? Is there suggested way of allowing this type of features at own risk? Config or even Some #ifdef which is not listed in Kconfig? Device-tree property? If you have (good) suggestions I could add the optional (non default) DVS support for non DVS bucks on BD71837. Matti Vaittinen (3): dt-bindings: regulator: BD71837 support commonly used feedback connection dt-bindings: regulator: BD71847 support commonly used feedback connection regulator: bd718x7: Support external connection to scale voltages .../regulator/rohm,bd71837-regulator.yaml | 48 +++++ .../regulator/rohm,bd71847-regulator.yaml | 49 ++++++ drivers/regulator/bd718x7-regulator.c | 164 +++++++++++++++++- 3 files changed, 254 insertions(+), 7 deletions(-) base-commit: 3cea11cd5e3b00d91caf0b4730194039b45c5891 -- 2.21.3 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
2020-11-10regulator: bd718x7: Support external connection to scale voltagesMatti Vaittinen
Setups where regulator (especially the buck8) output voltage is scaled by adding external connection where some other regulator output is connected to feedback-pin (over suitable resistors) is getting popular amongst users of BD71837. This allows for example scaling down the buck8 voltages to suit lover GPU voltages for projects where buck8 is (ab)used to supply power for GPU. As a note - some setups do allow DVS for buck8. This do produce voltage spikes and the HW must be evaluated to be able to survive them. Thus this commit still keep the DVS disabled for non DVS bucks by default. Let's not help you burn your proto board. Allow describing this external connection from DT and scale the voltages accordingly. This is what the connection should look like: |------------| | buck 8 |-------+----->Vout | | | |------------| | | FB pin | | | +-------+--R2---+ | R1 | V FB-pull-up Here the buck output is sifted according to formula: Vout_o = Vo - (Vpu - Vo)*R2/R1 Linear_step = step_orig*(R1+R2)/R1 where: Vout_o is adjusted voltage output at vsel reg value 0 Vo is original voltage output at vsel reg value 0 Vpu is the pull-up voltage V FB-pull-up in the picture R1 and R2 are resistor values. Bring support for specifying the Vpu, R1 and R2 from device tree and scale voltages if they are given. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/89b2be87074f307a8823f15f34e1f662023cbf36.1604994184.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-10regulator: core: don't disable regulator if is_enabled return error.Pi-Hsun Shih
In regulator_late_cleanup when is_enabled failed, don't try to disable the regulator since it would likely to fail too and causing confusing error messages. Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Link: https://lore.kernel.org/r/20201106064817.3290927-1-pihsun@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-03regulator: Add support for DA9121 regulatorVincent Whitchurch
Add support for the Dialog Semiconductor DA9121, a single-channel dual-phase buck converter controlled via I2C. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20201103100021.19603-3-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-03regulator: defer probe when trying to get voltage from unresolved supplyMichał Mirosław
regulator_get_voltage_rdev() is called in regulator probe() when applying machine constraints. The "fixed" commit exposed the problem that non-bypassed regulators can forward the request to its parent (like bypassed ones) supply. Return -EPROBE_DEFER when the supply is expected but not resolved yet. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reported-by: Ondřej Jirman <megous@megous.com> Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com> Tested-by: Ondřej Jirman <megous@megous.com> Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-28regulator: fix a kernel-doc markupMauro Carvalho Chehab
It seems that the function was renamed. kernel-doc markup should follow it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/dffad16d4d6427d7d0fc89797e4126fe7c69d5de.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-26Merge series " [PATCH v2 0/5]" from Dmitry Baryshkov ↵Mark Brown
<dmitry.baryshkov@linaro.org>: On SM8250 MDSS_GDSC (and the rest of display clock controller) is supplied power by MMCX power domain. Handle this link in GDSC code by binding the power domain in dts file. This patchset depends on [1] Changes since v1: - Define fixed-regulator-domain regulator using power domain performance state for enabling/disabling. - Rework to use new fixed regulator type (fixed-regulator-domain) instead of controlling power domain directly from gdsc code. Changes since RFC: - Fix naming of gdsc_supply_on/gdsc_supply_off functions - Fix detaching of solo gdsc's power domain in error handling code - Drop the dts patch, as respective display nodes are still not submitted to the mailing list. [1] https://lore.kernel.org/linux-arm-msm/20200927190653.13876-1-jonathan@marek.ca/
2020-10-26regulator: lp872x: make a const array static, makes object smallerColin Ian King
Don't populate const array lp872x_num_regulators on the stack but instead make it static. Makes the object code smaller by 29 bytes. Before: text data bss dec hex filename 18441 4624 64 23129 5a59 drivers/regulator/lp872x.o After: text data bss dec hex filename 18316 4720 64 23100 5a3c drivers/regulator/lp872x.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201016222235.686981-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-26regulator: fixed: support using power domain for enable/disableDmitry Baryshkov
Adds possibility to choose the compatible "fixed-regulator-domain" for regulators which use power domain for enabling/disabling corresponding regulator. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201023131925.334864-3-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-05Merge remote-tracking branch 'regulator/for-5.10' into regulator-nextMark Brown
2020-10-05regulator: bd9576: Fix printMatti Vaittinen
The print in probe is done using pr_info. Correct print call would be dev_dbg because: - Severity should really be dbg - The dev pointer is given as first argument Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/c4f55add237455555df0597c72052022f7a669f6.1601885841.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-05regulator: qcom_smd: add pm8953 regulatorsVladimir Lypak
The PM8953 is commonly used on board with MSM8953 SoCs or its variants: APQ8053, SDM(SDA)450 and SDM(SDA)632. It provides 7 SMPS and 23 LDO regulators. Signed-off-by: Vladimir Lypak <junak.pub@gmail.com> Link: https://lore.kernel.org/r/20201004083413.324351-1-junak.pub@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-05regulator: Make constraint debug processing conditional on DEBUGGeert Uytterhoeven
If debugging is disabled, print_constraints() does not print the actual constraints, but still performs some processing and string formatting, only to throw away the result later. Fix this by moving all constraint debug processing to a separate function, and replacing it by a dummy when debugging is disabled. This reduces kernel size by almost 800 bytes (on arm/arm64). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201005131546.22448-1-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01Merge series "Support for PM660/PM660L SPMI and SMD regulators" from ↵Mark Brown
kholk11@gmail.com AngeloGioacchino Del Regno <kholk11@gmail.com>: From: AngeloGioacchino Del Regno <kholk11@gmail.com> This patch series enables support for the regulators as found in the PM660 and PM660L PMICs. While at it, and to make them work, along with other regulators for other qcom PMICs, enlarge the maximum property name length in the regulator core, so that we're able to correctly parse the supply parents, which have got very long names (details in patch 1/5). This patch series has been tested against the following devices: - Sony Xperia XA2 Ultra (SDM630 Nile Discovery) - Sony Xperia 10 (SDM630 Ganges Kirin) - Sony Xperia 10 Plus (SDM636 Ganges Mermaid) AngeloGioacchino Del Regno (7): regulator: core: Enlarge max OF property name length to 64 chars regulator: qcom_spmi: Add support for new regulator types regulator: qcom_spmi: Add PM660/PM660L regulators regulator: dt-bindings: Document the PM660/660L SPMI PMIC entries regulator: qcom_smd: Add PM660/PM660L regulator support mfd: qcom-spmi-pmic: Add support for PM660/PM660L regulator: dt-bindings: Document the PM660/PM660L PMICs entries .../regulator/qcom,smd-rpm-regulator.yaml | 7 ++ .../regulator/qcom,spmi-regulator.txt | 31 +++++ drivers/mfd/qcom-spmi-pmic.c | 4 + drivers/regulator/core.c | 4 +- drivers/regulator/qcom_smd-regulator.c | 113 ++++++++++++++++++ drivers/regulator/qcom_spmi-regulator.c | 107 +++++++++++++++++ include/linux/soc/qcom/smd-rpm.h | 4 + 7 files changed, 268 insertions(+), 2 deletions(-) -- 2.28.0
2020-10-01regulator: qcom: labibb: Constify static structsRikard Falkeborn
The only usage of qcom_labibb_ops is to assign it to the ops field in the regulator_desc struct, which is a const pointer. The only usage of pmi8998_lab_desc and pmi8998_ibb_desc is to assign their address to the desc field in the labibb_regulator_data struct which can be made const, since it is only copied into the desc field in the labbibb_regulator_data struct. This struct is modified, but that's a copy of the static one. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200930162602.18583-1-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_smd: Add PM660/PM660L regulator supportAngeloGioacchino Del Regno
The PM660 and PM660L are a very very common PMIC combo, found on boards using the SDM630, SDM636, SDM660 (and SDA variants) SoC. PM660 provides 6 SMPS and 19 LDOs (of which one is unaccesible), while PM660L provides 5 SMPS (of which S3 and S4 are combined), 10 LDOs and a Buck-or-Boost (BoB) regulator. The PM660L IC also provides other regulators that are very specialized (for example, for the display) and will be managed in the other appropriate drivers (for example, labibb). Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-6-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_spmi: Add PM660/PM660L regulatorsAngeloGioacchino Del Regno
The PM660 PMIC is very often paired with the PM660L option on SDM630/663/660 (and SDA variants) boards. The PM660 has 11 "660" LDOs (2 NMOS, 9 PMOS) and 7 HT LDOs (4 NMOS, 3 PMOS) and a quirk: the L4 regulator is unaccessible or does not exist on the PMIC. The PM660L has 8 "660" LDOs (1 NMOS, 7 PMOS) and 2 HT NMOS LDOs. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-4-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_spmi: Add support for new regulator typesAngeloGioacchino Del Regno
This commit adds the support for some regulator types that are missing in this driver, such as the ht nmos-ldo, ht-lv nmos-ldo and new gen n/pmos-ldo, all belonging to the FTSMPS426 register layout. This is done in preparation for adding support for the PM660 and PM660L PMICs. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-3-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: core: Enlarge max OF property name length to 64 charsAngeloGioacchino Del Regno
Some regulator drivers may be defining very long names: this is the case with the qcom_smd and qcom_spmi regulators, where we need to parse the regulator parents from DT. For clarity, this is an example: { "l13a", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo, "vdd_l8_l9_l10_l11_l12_l13_l14" }, pm660-regulators { ... vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04> ... }; Now, with a 32 characters limit, the function is trying to parse, exactly, "vdd_l8_l9_l10_l11_l12_l13_l14-s" (32 chars) instead of the right one, which is 37 chars long in this specific case. ... And this is not only the case with PM660/PM660L, but also with PMA8084, PM8916, PM8950 and others that are not implemented yet. The length of 64 chars was chosen based on the longest parsed property name that I could find, which is in PM8916, and would be 53 characters long. At that point, rounding that to 64 looked like being the best idea. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-2-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: tps65910: use regmap accessorsMichał Mirosław
Use regmap accessors directly for register manipulation - removing one layer of abstraction. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/e82886d0f8f5131c9fccf2a17e3a15acce507d6f.1601164493.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-30regulator: rtmv20: Add missing regcache cache only before marked as dirtyChiYuan Huang
Add missing regcache cache only before masked as dirty. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1601461132-15251-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-30regulator: rtmv20: Update DT binding document and property name parsingChiYuan Huang
1. Add vendor suffix to all proprietary properties. 2. Fix typo. 3. Change lsw to normal property, not pattern property. 4. Due to item 1, modify source code for property parsing. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1601460480-4259-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-28Merge series "regulator: debugging aids" from Michał Mirosław ↵Mark Brown
<mirq-linux@rere.qmqm.pl>: Three simple patches to aid in debugging regulators. Michał Mirosław (3): regulator: print state at boot regulator: print symbolic errors in kernel messages regulator: resolve supply after creating regulator drivers/regulator/core.c | 124 ++++++++++++++++++++++----------------- 1 file changed, 69 insertions(+), 55 deletions(-) -- 2.20.1
2020-09-28regulator: rtmv20: Adds support for Richtek RTMV20 load switch regulatorChiYuan Huang
Add support for Richtek RTMV20 load switch regulator. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1601277584-5526-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-28regulator: resolve supply after creating regulatorMichał Mirosław
When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead. DCDC_REG1: supplied by VSYS VSYS: could not add device link regulator.3 err -2 Note: It doesn't fix the problem for bypassed regulators, though. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-12 19:42:10 +0000