summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
2023-07-24regulator: Merge up fixes from mainlineMark Brown1-0/+3
There's several things here that will really help my CI.
2023-07-21Add regulators support for PMX75Mark Brown1-0/+38
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 Agarwal1-0/+38
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önig1-2/+2
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 Bergmann1-3/+3
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önig1-1/+1
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 Li1-1/+0
./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 Sahin3-0/+470
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 Fuzzey1-0/+3
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 Herring36-38/+28
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 Niedermaier1-6/+5
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 Brown1-7/+29
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 Brown3-0/+166
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-10regulator: raa215300: Switch back to use struct i2c_driver::probeUwe Kleine-König1-1/+1
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-10regulator: raa215300: Change the scope of the variables {clkin_name, xin_name}Biju Das1-7/+9
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-10regulator: rt5739: Add DID check and compatible for rt5733ChiYuan Huang1-7/+29
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-10regulator: Introduce Qualcomm REFGEN regulator driverKonrad Dybcio3-0/+166
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-07Merge tag 'regulator-fix-v6.5-merge-window' of ↵Linus Torvalds1-0/+1
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 Torvalds3-0/+165
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 Das1-0/+1
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 Sahin3-0/+165
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 Brown4-15/+213
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 Das3-0/+198
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 Brown1-1/+1
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 Brown1-1/+1
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 Huang1-0/+1
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 Tsai1-81/+40
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 Tsai1-10/+11
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 Tsai1-14/+0
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 Tsai1-15/+50
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önig2-2/+2
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 Vesa1-15/+15
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 Brown3-0/+629
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 Neanne3-0/+629
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 Brown1-8/+282
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 Qu1-9/+223
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 Botka1-0/+60
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 Brown1-17/+13
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 Vasut1-1/+1
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 Uytterhoeven1-17/+13
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 Uytterhoeven1-1/+1
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 Brown3-6/+9
So we can base some new debugfs work on it.
2023-05-24mfd/pinctrl/regulator: Add RK806 SupportMark Brown3-12/+411
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 Reichel1-0/+385
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 Reichel1-1/+1
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>
2023-05-23regulator: rk808: cleanup parent device usageSebastian Reichel1-7/+6
By overridering the device's of_node a bit earlier we can get the GPIOs and any other DT properties from our own device instead of relying on the parent device. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20230504173618.142075-13-sebastian.reichel@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-23regulator: rk808: fix asynchronous probingSebastian Reichel1-0/+1
If the probe routine fails with -EPROBE_DEFER after taking over the OF node from its parent driver, reprobing triggers pinctrl_bind_pins() and that will fail. Fix this by setting of_node_reused, so that the device does not try to setup pin muxing. For me this always happens once the driver is marked to prefer async probing and never happens without that flag. Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20230504173618.142075-12-sebastian.reichel@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-23regulator: expose regulator_find_closest_biggerSebastian Reichel1-4/+18
Expose and document the table lookup logic used by regulator_set_ramp_delay_regmap, so that it can be reused for devices that cannot be configured via regulator_set_ramp_delay_regmap. 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-11-sebastian.reichel@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-18regulator: mt6359: add read check for PMIC MT6359Sen Chu1-2/+5
Add hardware version read check for PMIC MT6359 Signed-off-by: Sen Chu <sen.chu@mediatek.com Fixes: 4cfc96547512 ("regulator: mt6359: Add support for MT6359P regulator") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com Link: https://lore.kernel.org/r/20230518040646.8730-1-sen.chu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-17regulator: tps6287x: Fix missing .n_voltages settingAxel Lin1-0/+1
Otherwise, regulator_list_voltage() will return -EINVAL. Signed-off-by: Axel Lin <axel.lin@ingics.com Link: https://lore.kernel.org/r/20230516082333.466429-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-07 13:26:43 +0300