summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2023-07-30regulator: Merge up fixes from Linus' treeMark Brown
Gets us pine64plus back if nothing else.
2023-07-25regulator: REGULATOR_QCOM_REFGEN should depend on ARCH_QCOMGeert Uytterhoeven
The Qualcomm MMIO-mapped reference voltage regulator is only present on Qualcomm SoCs. Hence add a dependency on ARCH_QCOM, to prevent asking the user about this driver when configuring a kernel without Qualcomm SoC support. Fixes: 7cbfbe23796086fd ("regulator: Introduce Qualcomm REFGEN regulator driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/60938ed138c9331ba3d2891fbd3b3d6644d3fbdc.1690300012.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-25regulator: Use bitfield values for range selectorsChen-Yu Tsai
Right now the regulator helpers expect raw register values for the range selectors. This is different from the voltage selectors, which are normalized as bitfield values. This leads to a bit of confusion. Also, raw values are harder to copy from datasheets or match up with them, as datasheets will typically have bitfield values. Make the helpers expect bitfield values, and convert existing users. The field in regulator_desc is renamed to |linear_range_selectors_bitfield|. This is intended to cause drivers added in the same merge window and out-of-tree drivers using the incorrect variable and values to break, preventing incorrect values being used on actual hardware and potentially producing magic smoke. Also include bitops.h explicitly for ffs(), and reorder the header include statements. While at it, also replace module.h with export.h, since the only use is EXPORT_SYMBOL_GPL. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230714081408.274567-1-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-23regulator: mt6358: Fix incorrect VCN33 sync error messageChen-Yu Tsai
After syncing the enable status of VCN33_WIFI to VCN33_BT, the driver will disable VCN33_WIFI. If it fails it will error out with a message. However the error message incorrectly refers to VCN33_BT. Fix the error message so that it correctly refers to VCN33_WIFI. Suggested-by: Fei Shao <fshao@chromium.org> Fixes: 65bae54e08c1 ("regulator: mt6358: Merge VCN33_* regulators") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230721082903.2038975-4-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-23regulator: mt6358: Sync VCN33_* enable status after checking IDChen-Yu Tsai
Syncing VCN33_* enable status should be done after checking the PMIC's ID, to avoid setting random bits on other PMICs. Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: 65bae54e08c1 ("regulator: mt6358: Merge VCN33_* regulators") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230721082903.2038975-3-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-23regulator: Merge up fixes from mainlineMark Brown
There's several things here that will really help my CI.
2023-07-21Add regulators support for PMX75Mark Brown
Merge series from Rohit Agarwal <quic_rohiagar@quicinc.com>: This series adds regulators supports in PMX75 found on SDX75 platform.
2023-07-21regulator: qcom-rpmh: Add regulators support for PMX75Rohit Agarwal
Add support from RPMH regulators found in PMX75 for SDX75 platform. Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> Link: https://lore.kernel.org/r/1689062414-3654-4-git-send-email-quic_rohiagar@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-21regulator: max8893: Drop "_new" from probe callbackUwe Kleine-König
The driver was introduced when .probe_new was the right probe callback to use for i2c drivers. Today .probe is the right one (again) and the driver was already switched in commit 964e186547b2 ("regulator: Switch i2c drivers back to use .probe()") but the name continued to include "_new". To prevent code readers wondering about what might be new here, drop that part of the name. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230721073303.112597-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-19regulator: max77857: mark more functions staticArnd Bergmann
A few functions in the new driver are global but only used in this file: drivers/regulator/max77857-regulator.c:209:5: error: no previous prototype for 'max77859_get_voltage_sel' [-Werror=missing-prototypes] drivers/regulator/max77857-regulator.c:221:5: error: no previous prototype for 'max77859_set_current_limit' [-Werror=missing-prototypes] drivers/regulator/max77857-regulator.c:235:5: error: no previous prototype for 'max77859_get_current_limit' [-Werror=missing-prototypes] Mark them static, which produces potentially better code and avoids the warning. Fixes: af71cccadeced ("regulator: max77857: Add ADI MAX77857/59/MAX77831 Regulator Support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230718193938.3593118-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-19regulator: max77857: Switch back to use struct i2c_driver's .probe()Uwe Kleine-König
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230718201453.3953602-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-18regulator: Remove duplicated include in mt6359-regulator.cYang Li
./drivers/regulator/mt6359-regulator.c: linux/platform_device.h is included more than once. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5901 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20230718003255.124594-1-yang.lee@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17regulator: max77857: Add ADI MAX77857/59/MAX77831 Regulator SupportOkan Sahin
Regulator driver for MAX77857/59 and MAX77831. The MAX77857 is a high-efficiency, high-performance buck-boost converter targeted for systems requiring a wide input voltage range (2.5V to 16V). The MAX77859 is high-Efficiency Buck-Boost Converter for USB-PD/PPS Applications. It has wide input range (2.5V to 22V) The MAX77831 is a high-efficiency, high-performance buck-boost converter targeted for systems requiring wide input voltage range (2.5V to 16V). Signed-off-by: Okan Sahin <okan.sahin@analog.com> Link: https://lore.kernel.org/r/20230717050736.10075-3-okan.sahin@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17regulator: da9063: fix null pointer deref with partial DT configMartin Fuzzey
When some of the da9063 regulators do not have corresponding DT nodes a null pointer dereference occurs on boot because such regulators have no init_data causing the pointers calculated in da9063_check_xvp_constraints() to be invalid. Do not dereference them in this case. Fixes: b8717a80e6ee ("regulator: da9063: implement setter for voltage monitoring") Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Link: https://lore.kernel.org/r/20230616143736.2946173-1-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-14regulator: Explicitly include correct DT includesRob Herring
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230714174930.4063320-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-13regulator: da9062: Make the use of IRQ optionalChristoph Niedermaier
This patch makes the use of IRQ optional to make the DA9061/62 usable for designs that don't have the IRQ pin connected, because the regulator is usable without IRQ. Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com> Reviewed-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230713090328.3879-1-cniedermaier@dh-electronics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-12Add compatible support for RT5733Mark Brown
Merge series from cy_huang@richtek.com: This series is to add the compatible support for rt5733 based on rt5739.
2023-07-12Qualcomm REFGEN regulatorMark Brown
Merge series from Konrad Dybcio <konrad.dybcio@linaro.org>: Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator responsible for providing a reference voltage to some on-SoC IPs (like DSI or PHYs). It can be turned off when unused to save power. This series introduces the driver for it.
2023-07-09regulator: raa215300: Switch back to use struct i2c_driver::probeUwe Kleine-König
struct i2c_driver::probe_new is about to go away. Switch the driver to use the probe callback with the same prototype. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230626091544.557403-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-09regulator: raa215300: Change the scope of the variables {clkin_name, xin_name}Biju Das
Change the scope of the variables {clkin_name, xin_name} from global->local to fix the below warning. drivers/regulator/raa215300.c:42:12: sparse: sparse: symbol 'xin_name' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306250552.Fan9WTiN-lkp@intel.com/ Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230629104200.102663-1-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-09regulator: rt5739: Add DID check and compatible for rt5733ChiYuan Huang
Add compatible and use DID to check rt5733. The only difference bwtween rt5733 and rt5739 is the output range and voltage step. These two chips can be distinguished from the DIE id. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1688048996-25606-3-git-send-email-cy_huang@richtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-09regulator: Introduce Qualcomm REFGEN regulator driverKonrad Dybcio
Modern Qualcomm SoCs have a REFGEN (reference voltage generator) regulator, providing reference voltage to on-chip IP, like PHYs. Add a driver to support toggling that regulator. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230628-topic-refgen-v3-2-9fbf0e605d23@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-06Merge tag 'regulator-fix-v6.5-merge-window' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fix from Mark Brown: "A simple dependency fix for a newly added driver" * tag 'regulator-fix-v6.5-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: raa215300: Add build dependency with COMMON_CLK
2023-07-03Merge tag 'mfd-next-6.5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "New Drivers: - Add support for TI TPS6594/TPS6593/LP8764 PMICs - Add support for Samsung RT5033 Battery Charger - Add support for Analog Devices MAX77540 and MAX77541 PMICs New Device Support: - Add support for SPI to Rockchip RK808 (and friends) - Add support for AXP192 PMIC to X-Powers AXP20X - Add support for AXP313a PMIC to X-Powers AXP20X - Add support for RK806 to Rockchip RK8XX Removed Device Support: - Removed MFD support for Richtek RT5033 Battery Fix-ups: - Remove superfluous code - Switch I2C drivers from .probe_new() to .probe() - Convert over to managed resources (devm_*(), etc) - Use dev_err_probe() for returning errors from .probe() - Add lots of Device Tree bindings / support - Improve cache efficiency by switching to Maple - Use own exported namespaces (NS) - Include missing and remove superfluous headers - Start using / convert to the new shutdown sys-off API - Trivial: variable / define renaming - Make use of of_property_read_reg() when requesting DT 'reg's Bug Fixes: - Fix chip revision readout due to incorrect data masking - Amend incorrect register and mask values used for charger state - Hide unused functionality at compile time - Fix resource leaks following error handling routines - Return correct error values and fix error handling in general - Repair incorrect device names - used for device matching - Remedy broken module auto-loading" * tag 'mfd-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (51 commits) dt-bindings: mfd: max77541: Add ADI MAX77541/MAX77540 iio: adc: max77541: Add ADI MAX77541 ADC Support regulator: max77541: Add ADI MAX77541/MAX77540 Regulator Support dt-bindings: regulator: max77541: Add ADI MAX77541/MAX77540 Regulator mfd: Switch two more drivers back to use struct i2c_driver::probe dt-bindings: mfd: samsung,s5m8767: Simplify excluding properties mfd: stmpe: Only disable the regulators if they are enabled mfd: max77541: Add ADI MAX77541/MAX77540 PMIC Support dt-bindings: mfd: gateworks-gsc: Remove unnecessary fan-controller nodes mfd: core: Use of_property_read_reg() to parse "reg" mfd: stmfx: Nullify stmfx->vdd in case of error mfd: stmfx: Fix error path in stmfx_chip_init mfd: intel-lpss: Add missing check for platform_get_resource mfd: stpmic1: Add PMIC poweroff via sys-off handler mfd: stpmic1: Fixup main control register and bits naming dt-bindings: mfd: qcom,tcsr: Add the compatible for IPQ8074 mfd: tps65219: Add support for soft shutdown via sys-off API mfd: pm8008: Drop bogus i2c module alias mfd: pm8008: Fix module autoloading mfd: tps65219: Add GPIO cell instance ...
2023-06-28regulator: raa215300: Add build dependency with COMMON_CLKBiju Das
The COMMON_CLK config is not enabled in some of the architectures. This causes build issues. Fix these issues by adding build dependency. ERROR: modpost: "clk_unregister_fixed_rate" [drivers/regulator/raa215300.ko] undefined! ERROR: modpost: "clk_register_fixed_rate" [drivers/regulator/raa215300.ko] undefined! Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306282012.sPQAuAN7-lkp@intel.com/ Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230628174004.63984-1-biju.das.jz@bp.renesas.com Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-28regulator: max77541: Add ADI MAX77541/MAX77540 Regulator SupportOkan Sahin
Regulator driver for both MAX77541 and MAX77540. The MAX77541 is a high-efficiency step-down converter with two 3A switching phases for single-cell Li+ battery and 5VDC systems. The MAX77540 is a high-efficiency step-down converter with two 3A switching phases. Signed-off-by: Okan Sahin <okan.sahin@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230412111256.40013-3-okan.sahin@analog.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-06-24Add Renesas PMIC RAA215300 and built-in RTCMark Brown
Merge series from Biju Das <biju.das.jz@bp.renesas.com>: This patch series aims to add support for Renesas PMIC RAA215300 and built-in RTC found on this PMIC device. The details of PMIC can be found here[1]. Renesas PMIC RAA215300 exposes two separate i2c devices, one for the main device and another for rtc device.
2023-06-23regulator: Add Renesas PMIC RAA215300 driverBiju Das
The RAA215300 is a 9-channel PMIC that consists of * Internally compensated regulators * built-in Real Time Clock (RTC) * 32kHz crystal oscillator * coin cell battery charger The RTC on RAA215300 is similar to the IP found in the ISL1208. The existing driver for the ISL1208 works for this PMIC too, however the RAA215300 exposes two devices via I2C, one for the RTC IP, and one for everything else. The RTC IP has to be enabled by the other I2C device, therefore this driver is necessary to get the RTC to work. The external oscillator bit is inverted on PMIC version 0x11. Add PMIC RAA215300 driver for enabling RTC block and instantiating RTC device based on PMIC version. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/Message-Id: <20230623140948.384762-3-biju.das.jz@bp.renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-19regulator: ltc3676: Use maple tree register cacheMark Brown
The ltc3676 can only support single register read and write operations so does not benefit from block writes. This means it gets no benefit from using the rbtree register cache over the maple tree register cache so convert it to use maple trees instead, it is more modern. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230609-regulator-ltc-maple-v1-2-08c15181f8b2@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-19regulator: ltc3589: Use maple tree register cacheMark Brown
The ltc3589 can only support single register read and write operations so does not benefit from block writes. This means it gets no benefit from using the rbtree register cache over the maple tree register cache so convert it to use maple trees instead, it is more modern. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230609-regulator-ltc-maple-v1-1-08c15181f8b2@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-16regulator: helper: Document ramp_delay parameter of ↵ChiYuan Huang
regulator_set_ramp_delay_regmap() With W=1: drivers/regulator/helpers.c:947: warning: Function parameter or member 'ramp_delay' not described in 'regulator_set_ramp_delay_regmap' Fix it by documenting the parameter. Fixes: fb8fee9efdcf ("regulator: Add regmap helper for ramp-delay setting") Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1686881298-28333-1-git-send-email-cy_huang@richtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14regulator: mt6358: Use linear voltage helpers for single range regulatorsChen-Yu Tsai
Some of the regulators on the MT6358/MT6366 PMICs have just one linear voltage range. These are the bulk regulators and VSRAM_* LDOs. Currently they are modeled with one linear range, but also have their minimum, maximum, and step voltage described. Convert them to the linear voltage helpers. These helpers are a bit simpler, and we can also drop the linear range definitions. Also reflow the touched lines now that they are shorter. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230609083009.2822259-7-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14regulator: mt6358: Const-ify mt6358_regulator_info data structuresChen-Yu Tsai
In the MT6358 regulator driver, each regulator is described by a |struct regulator_desc| wrapped by a |struct mt6358_regulator_info|. The latter was tied to the regulator device using the config's driver_data field, which meant that the variables could not be constant. Since each regulator device has a pointer to its regulator_desc, and mt6358_regulator_info wraps that, the driver could use container_of() to retrieve it instead. Switch to using container_of(), drop tha driver_data setting, and const-ify all the regulator descriptions. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230609083009.2822259-6-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14regulator: mt6358: Drop *_SSHUB regulatorsChen-Yu Tsai
The *_SSHUB regulators are actually alternate configuration interfaces for their non *_SSHUB counterparts. They are not separate regulator outputs. These registers are intended for the companion processor to use to configure the power rails while the main processor is sleeping. They are not intended for the main operating system to use. Since they are not real outputs they shouldn't be modeled separately. Remove them. Luckily no device tree actually uses them. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20230609083009.2822259-5-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14regulator: mt6358: Merge VCN33_* regulatorsChen-Yu Tsai
The VCN33_BT and VCN33_WIFI regulators are actually the same regulator, having the same voltage setting and output pin. There are simply two enable bits that are ORed together to enable the regulator. Having two regulators representing the same output pin is misleading from a design matching standpoint, and also error-prone in driver implementations. If consumers try to set different voltages on either regulator, the one set later would override the one set before. There are ways around this, such as chaining them together and having the downstream one act as a switch. But given there's only one output pin, such a workaround doesn't match reality. Remove the VCN33_WIFI regulator. During the probe phase, have the driver sync the enable status of VCN33_WIFI to VCN33_BT. Also drop the suffix so that the regulator name matches the pin name in the datasheet. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230609083009.2822259-4-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-12regulator: Switch two more i2c drivers back to use .probe()Uwe Kleine-König
The previous conversion back to .probe done in commit 964e186547b2 ("regulator: Switch i2c drivers back to use .probe()") was done based on v6.3. Since then two more drivers were added which need to be convert back in the same way before eventually .probe_new() can be dropped from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230611203559.827168-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-07regulator: qcom-rpmh: Fix regulators for PM8550Abel Vesa
The PM8550 uses only NLDOs 515 and the LDO 6 through 8 are low voltage type, so fix accordingly. Fixes: e6e3776d682d ("regulator: qcom-rpmh: Add support for PM8550 regulators") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20230605115607.921308-1-abel.vesa@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-07TI TPS6594 PMIC support (RTC, pinctrl, regulators)Mark Brown
Merge series from Esteban Blanc <eblanc@baylibre.com>: TPS6594 is a Power Management IC which provides regulators and others features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can communicate through the I2C or SPI interfaces. TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives. This series adds support to TI TPS6594 PMIC and its derivatives.
2023-06-06regulator: tps6594-regulator: Add driver for TI TPS6594 regulatorsJerome Neanne
This patch adds support for TPS6594 regulators (bucks and LDOs). The output voltages are configurable and are meant to supply power to the main processor and other components. Bucks can be used in single or multiphase mode, depending on PMIC part number. Signed-off-by: Jerome Neanne <jneanne@baylibre.com> Signed-off-by: Esteban Blanc <eblanc@baylibre.com> Link: https://lore.kernel.org/r/20230522163115.2592883-4-eblanc@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-06regulator: Add X-Powers AXP15060/AXP313a PMICMark Brown
Merge series from Andre Przywara <andre.przywara@arm.com>: This patch series adds support for the X-Powers AXP15060 and AXP313a PMIC, which are general purpose PMICs as seen on different boards with different SOCs, mostly from Allwinner. This is mostly a repost of the previous patches, combining both the AXP313a and AXP15060 series, rebased on top of v6.4-rc3, and omitting the patches that already got merged. The first two patches are the successors of the AXP313a v10 post, the third patch is based on Shengyu's AXP15060 v3 post. There were no code changes, just some tiny context differences due to the rebase, plus I added the newly gained tags. As the DT bindings and the AXP15060 MFD part are already in the tree, this is just completing support with the MFD part for the AXP313a, and the regulator support for both PMICs.
2023-06-02regulator: axp20x: Add AXP15060 supportShengyu Qu
The AXP15060 is a typical I2C-controlled PMIC, seen on multiple boards with different default register value. Current driver is tested on Starfive Visionfive 2. The RTCLDO is fixed, and cannot even be turned on or off. On top of that, its voltage is customisable (either 1.8V or 3.3V). We pretend it's a fixed 1.8V regulator since other AXP driver also do like this. Also, BSP code ignores this regulator and it's not used according to VF2 schematic. Describe the AXP15060's voltage settings and switch registers, how the voltages are encoded, and connect this to the MFD device via its regulator ID. Signed-off-by: Shengyu Qu <wiagn233@outlook.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Tested-by: Shengyu Qu <wiagn233@outlook.com> Link: https://lore.kernel.org/r/20230524000012.15028-4-andre.przywara@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-02regulator: axp20x: Add support for AXP313a variantMartin Botka
The AXP313a is your typical I2C controlled PMIC, although in a lighter fashion compared to the other X-Powers PMICs: it has only three DCDC rails, three LDOs, and no battery charging support. The AXP313a datasheet does not describe a register to change the DCDC switching frequency, and talks of it being fixed at 3 MHz. Check that the property allowing to change that frequency is absent from the DT, and bail out otherwise. The third LDO, RTCLDO, is fixed, and cannot even be turned on or off, programmatically. On top of that, its voltage is customisable (either 1.8V or 3.3V), which we cannot describe easily using the existing regulator wrapper functions. This should be fixed properly, using regulator-{min,max}-microvolt in the DT, but this requires more changes to the code. As some other PMICs (AXP2xx, AXP803) seem to paper over the same problem as well, we follow suit here and pretend it's a fixed 1.8V regulator. A proper fix can follow later. The BSP code seems to ignore this regulator altogether. Describe the AXP313A's voltage settings and switch registers, how the voltages are encoded, and connect this to the MFD device via its regulator ID. Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Mark Brown <broonie@kernel.org> Tested-by: Shengyu Qu <wiagn233@outlook.com> Link: https://lore.kernel.org/r/20230524000012.15028-3-andre.przywara@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-30regulator: core: Fix error checking and messagesMark Brown
Merge series from Geert Uytterhoeven <geert+renesas@glider.be>: This patch series corrects an error check, fixes error messages when debugfs is not enabled, and improves debugfs error handling in the regulator core.
2023-05-30regulator: stm32-pwr: Fix regulator disablingMarek Vasut
The following shows up in the kernel log on systems using the STM32MP15xx USBPHYC: " regulator regulator.19: regulator disable timed out! reg18: failed to disable: -ETIMEDOUT " This 'regulator.19' is 'pwr@50001000' 'reg18' in stm32mp151.dts DT, or "Power control (PWR)" register "PWR_CR3" bits "REG18" on STM32MP15xx reference manual. The reason for the timeout seems to be the poll which this patch changes. When turning this regulator OFF, PWR_CR3 reads 0xf0000000 , then REG18_EN bit is cleared, and then this poll waits until REG18_RDY bit is cleared as well, but that never happens, the PWR_CR3 keeps reading 0xe0000000 . I am not sure whether this should happen, I suspect the 1V8 supply is always READY when the 1V8 input is present, and the regulator can only ever be enabled/disabled using the REG18_EN bit, but the REG18_READY bit is never cleared again. This patch adjusts the poll to check whether REG18_EN has been cleared on regulator disable, but retains the check for REG18_READY in regulator enable as there it makes sense to verify the regulator is really READY. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230518023946.530381-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-25regulator: core: Streamline debugfs operationsGeert Uytterhoeven
If CONFIG_DEBUG_FS is not set: regulator: Failed to create debugfs directory ... regulator-dummy: Failed to create debugfs directory As per the comments for debugfs_create_dir(), errors returned by this function should be expected, and ignored: * If debugfs is not enabled in the kernel, the value -%ENODEV will be * returned. * * NOTE: it's expected that most callers should _ignore_ the errors returned * by this function. Other debugfs functions handle the fact that the "dentry" * passed to them could be an error and they don't crash in that case. * Drivers should generally work fine even if debugfs fails to init anyway. Adhere to the debugfs spirit, and streamline all operations by: 1. Demoting the importance of the printed error messages to debug level, like is already done in create_regulator(), 2. Further ignoring any returned errors, as by design, all debugfs functions are no-ops when passed an error pointer. Fixes: 2bf1c45be3b8f3a3 ("regulator: Fix error checking for debugfs_create_dir") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/2f8bb6e113359ddfab7b59e4d4274bd4c06d6d0a.1685013051.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-25regulator: core: Fix more error checking for debugfs_create_dir()Geert Uytterhoeven
In case of failure, debugfs_create_dir() does not return NULL, but an error pointer. Most incorrect error checks were fixed, but the one in create_regulator() was forgotten. Fix the remaining error check. Fixes: 2bf1c45be3b8f3a3 ("regulator: Fix error checking for debugfs_create_dir") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/ee980a108b5854dd8ce3630f8f673e784e057d17.1685013051.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-25regulator: Merge up fixesMark Brown
So we can base some new debugfs work on it.
2023-05-23mfd/pinctrl/regulator: Add RK806 SupportMark Brown
Merge series from Sebastian Reichel <sebastian.reichel@collabora.com>: All existing boards using RK3588/RK3588s use RK806 PMICs. This series is now the main blocker for full upstream support of those boards and it would be good to have it merged for 6.5 :) The patches have been tested on multiple different platforms and are mainly missing an Ack from Mark or Liam for the rk808-regulator changes. Merging must happen through a single tree, since the pinctrl and regulator drivers rely on the register definitions from the include file added by the MFD patch. My suggested merge strategy is that Lee creates an immutable branch for the regulator/pinctrl tree once all Acks have been collected.
2023-05-23regulator: rk808: add rk806 supportSebastian Reichel
Add rk806 support to the existing rk808 regulator driver. This has been implemented using shengfei Xu's rk806 specific driver from the vendor tree as reference. Co-developed-by: shengfei Xu <xsf@rock-chips.com> Signed-off-by: shengfei Xu <xsf@rock-chips.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, Quartz64 Model A + B Tested-by: Vincent Legoll <vincent.legoll@gmail.com> # Pine64 QuartzPro64 Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20230504173618.142075-15-sebastian.reichel@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-23regulator: rk808: revert to synchronous probingSebastian Reichel
The rk808 driver registers a bunch of regulator devices in a loop. If one of the later regulators fails to register (usually because its input supply is not yet available) everything will be unrolled (i.e. previously registered regulators will be unregistered). With asynchronous registration there might already be consumers, though. We do not have the necessary infrastructure to properly unregister the consumer device, so this scenario should be avoided. First checking all input supplies or disallowing usage of the regulators until all are registered does not work, since there can be self-references (e.g. DCDC channels providing the supply of LDOs). The only sensible solution I found is registering the regulator devices asynchronously, so that we do not have to unroll. Since this is a major rework let's revert back to synchronous probing for now to fix the issue at hand. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20230504173618.142075-14-sebastian.reichel@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-11 23:48:52 +0000