summaryrefslogtreecommitdiff
path: root/drivers/power/regulator
AgeCommit message (Collapse)Author
2025-03-19regulator: rzg2l-usbphy: Add new driverPaul Barker
Add a new regulator driver to control the USB VBUS supply on the Renesas RZ/G2L and related SoCs. Reviewed-by: Marek Vasut <[email protected]> Signed-off-by: Paul Barker <[email protected]>
2025-02-26power: regulator: add additional supported LDOs for pm8150lCaleb Connolly
Add the other LDOs that our rpmh driver can currently support. Some of these are used on the RB5 to power the sdcard. Reviewed-by: Neil Armstrong <[email protected]> Tested-by: Amit Pundir <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2025-02-18power: regulator: tps65941: Fix voltage calculation for ldoUdit Kumar
As per TRM[0] Section 8.7.1 "TPS6594-Q1 Registers", LDOx_Vout bit 6-1, define the NVM voltage settings. Along side table 8-4 of above TRM, shows voltage to value mapping. Driver wrongly using bits 5-1 to calculate voltage, and to convert voltage to value driver was using buck's calculation. So fix those calculation. [0]: https://www.ti.com/lit/ds/symlink/tps6594-q1.pdf Fixes: 5d7dbd22cf7d ("power: regulator: tps65941: use function callbacks for conversion ops") Signed-off-by: Udit Kumar <[email protected]> Reviewed-by: Neha Malcom Francis <[email protected]>
2025-01-22regulator: qcom-rpmh-regulator: add support for pmc8380 regulatorsNeil Armstrong
Add the PMC8380 regulator data found on the Snapdragon X Elite platforms. The tables are imported from the Linux driver. Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]> Link: https://lore.kernel.org/r/20241125-topic-hamoa-pmc8380-rpmh-regulators-v1-1-695c44ea8586@linaro.org Signed-off-by: Caleb Connolly <[email protected]>
2025-01-14power: replace magic numbers with macrosShree Ramamoorthy
Replace magic numbers in buckval2votl() & buckvolt2val() with macros to help with clarity and correlate what the numbers correspond to in the TPS65219 datasheet. Signed-off-by: Shree Ramamoorthy <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]>
2025-01-14power: regulator: replace printf() with pr_err()Shree Ramamoorthy
Replace printf() with pr_err() because pr_err() has a uniform print format and takes into consideration the log levels supported. Signed-off-by: Shree Ramamoorthy <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]>
2024-12-05power: regulator: replace dev_dbg() by dev_err() in regulator_post_bind()Patrice Chotard
To ease debugging, use dev_err() instead of dev_dbg() for alerting when regulator has nonunique value. Signed-off-by: Patrice Chotard <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]>
2024-12-05power: regulator: replace some debug() by dev_dbg()Patrice Chotard
Replace some debug() by dev_dbg() when dev variable is available/valid. Signed-off-by: Patrice Chotard <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]>
2024-10-11Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"Tom Rini
Simon Glass <[email protected]> says: When the SPL build-phase was first created it was designed to solve a particular problem (the need to init SDRAM so that U-Boot proper could be loaded). It has since expanded to become an important part of U-Boot, with three phases now present: TPL, VPL and SPL Due to this history, the term 'SPL' is used to mean both a particular phase (the one before U-Boot proper) and all the non-proper phases. This has become confusing. For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL' phases, not just SPL. So code which can only be compiled for actual SPL, for example, must use something like this: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) In Makefiles we have similar issues. SPL_ has been used as a variable which expands to either SPL_ or nothing, to chose between options like CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was updated to support 'VPL_' as well. This series starts a change in terminology and usage to resolve the above issues: - The word 'xPL' is used instead of 'SPL' to mean a non-proper build - A new CONFIG_XPL_BUILD define indicates that the current build is an 'xPL' build - The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now defined for TPL and VPL phases - The existing SPL_ Makefile variable is renamed to SPL_ - The existing SPL_TPL Makefile variable is renamed to PHASE_ It should be noted that xpl_phase() can generally be used instead of the above CONFIGs without a code-space or run-time penalty. This series does not attempt to convert all of U-Boot to use this new terminology but it makes a start. In particular, renaming spl.h and common/spl seems like a bridge too far at this point. The series is fully bisectable. It has also been checked to ensure there are no code-size changes on any commit.
2024-10-11global: Rename SPL_TPL_ to PHASE_Simon Glass
Use PHASE_ as the symbol to select a particular XPL build. This means that SPL_TPL_ is no-longer set. Update the comment in bootstage to refer to this symbol, instead of SPL_ Signed-off-by: Simon Glass <[email protected]>
2024-10-11global: Rename SPL_ to XPL_Simon Glass
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is no-longer set. Signed-off-by: Simon Glass <[email protected]>
2024-10-11drivers: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILDSimon Glass
Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass <[email protected]>
2024-10-10power: pmic/regulator: Support pca9452Joy Zou
Add PCA9452 PMIC/Regulator support. Signed-off-by: Joy Zou <[email protected]> Reviewed-by: Ye Li <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2024-10-10power: regulator: pca9450: Update the BUCK1 voltage rangeJoy Zou
The pmic could be trimed with updated BUCK1 range, so update the range for trimed pmic. The default value of Toff_Deb is used to distinguish the non-trimed and trimed pmic. Signed-off-by: Joy Zou <[email protected]> Reviewed-by: Ye Li <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2024-09-30power: regulator: Drop regulators_enable_boot_on/off()Marek Vasut
Both regulators_enable_boot_on/off() are unused and superseded by regulator uclass regulator_post_probe(). Remove both functions. Signed-off-by: Marek Vasut <[email protected]>
2024-09-30power: regulator: Drop regulator_unset()Marek Vasut
This function is never called, drop it. Signed-off-by: Marek Vasut <[email protected]>
2024-09-30power: regulator: Convert regulators_enable_boot_on/off() to ↵Marek Vasut
regulator_post_probe Turn regulators_enable_boot_on() and regulators_enable_boot_off() into empty functions. Implement matching functionality in regulator_post_probe() instead. The regulator_post_probe() is called for all regulators after they probe, and regulators that have regulator-always-on or regulator-boot-on DT properties now always probe due to DM_FLAG_PROBE_AFTER_BIND being set on such regulators in regulator_post_bind(). Finally, fold regulator_unset() functionality into regulator_autoset(). Signed-off-by: Marek Vasut <[email protected]>
2024-09-30power: regulator: Trigger probe of regulators which are always-on or boot-onMarek Vasut
In case a regulator DT node contains regulator-always-on or regulator-boot-on property, make sure the regulator gets correctly configured by U-Boot on start up. Unconditionally probe such regulator drivers. This is a preparatory patch for introduction of .regulator_post_probe() which would trigger the regulator configuration. Parsing of regulator-always-on and regulator-boot-on DT property has been moved to regulator_post_bind() as the information is required early, the rest of the DT parsing has been kept in regulator_pre_probe() to avoid slowing down the boot process. Signed-off-by: Marek Vasut <[email protected]>
2024-09-30Merge tag 'v2024.10-rc6' into nextTom Rini
Prepare v2024.10-rc6
2024-09-27regulator: rk8xx: Use buck variable consistentlyJonas Karlman
The buck variable is zero based, i.e. buck=0 match BUCK1 in datasheet. Remove any buck + 1 calculation to be more consistent in usage of the buck variable across the different RK8xx variants in the driver. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2024-09-27regulator: rk8xx: Fix buck get and set enabled state on RK806Jonas Karlman
Wrong POWER_EN reg is used to get and set enabled state for the RK806 buck 4 and 8 regulators, also wrong POWER_SLP_EN0 bit is used for suspend state for the RK806 buck 1-8 regulators. Fix this by not adding one to the zero based buck variable. Fixes: f172575d92cd ("power: rk8xx: add support for RK806") Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]> Reviewed-by: Quentin Schulz <[email protected]>
2024-09-25power: regulator: Consistently return -ENOSYS when ops is unimplementedJonas Karlman
dev_get_driver_ops() may return NULL when the udevice is invalid. Move the ops check to top of functions to consistently return -ENOSYS when ops is unimplemented and prevent trying to access uclass plat data, also add missing NULL checks to suspend ops. Signed-off-by: Jonas Karlman <[email protected]>
2024-09-25power: regulator: Do not call set_suspend_value with -ENODATAJonas Karlman
On some boards a PMIC regulator is flagged with regulator-on-in-suspend and does not define any suspend or max microvolt, e.g. on Radxa ROCK 3A: vcc_ddr: DCDC_REG3 { regulator-name = "vcc_ddr"; regulator-always-on; regulator-boot-on; regulator-initial-mode = <0x2>; regulator-state-mem { regulator-on-in-suspend; }; }; This result in suspend_uV having the value -ENODATA after probe. This negative voltage, -ENODATA, gets missinterpreted and result in an unexpected voltage being set by autoset. E.g. on Radxa ROCK 3A the vcc_ddr regulator by default have a normal and suspend voltage value of 0.5v. However, due to this missinterpretation the suspend voltage end up beind set to 0.5625v instead. Fix this by skip calling regulator_set_suspend_value() in autoset and also protect calling set value ops when input value is -ENODATA. Signed-off-by: Jonas Karlman <[email protected]>
2024-09-09Merge branch 'qcom-next' of ↵Tom Rini
https://gitlab.denx.de/u-boot/custodians/u-boot-snapdragon into next Various improvements to Snapdragon support: * Bumped up the pagetable size to handle newer SoCs with much more RAM * Made memory map parsing more robust, fixing chainloading on SM8550/SM8650 * Populate fdt_addr_r with U-Boot's FDT by default, and set $loadaddr to prevent crashes with some commands which expect it * Added initial support for SC7280/QCM6490 and the new RB3 Gen 2 board * Add debug config fragments to enable debug UART on some SoCs. * Enable RPMh regulators on SM8550/SM8650 * Map the cmd-db memory explicitly since it may not be in the memory map CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/pipelines/22255
2024-09-06regulator: qcom-rpmh-regulator: add support for PM8550 & related regulatorsNeil Armstrong
Add the PM8550 & related regulators found on the SM8550 and SM8650 platforms. The tables are imported from the Linux driver. Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Caleb Connolly <[email protected]>
2024-09-05regulator: fixed: fix regulator-fixed-clockJohn Keeping
For regulator-fixed-clock, the device's private data is never set so in fixed_clock_regulator_set_enable() is null and the function cannot complete successfully. Rename the _plat structure to _priv to better represent its role and set this as the private data. As shown by the set_enable() function and by using the same .of_to_plat hook as regulator-fixed, the platform data is regulator_common_plat so also set .plat_auto correctly. Finally, set up the private data by adding a .probe function to look up the clock and set the member variable. Fixes: f3b5100aff3 ("regulator: fixed: add possibility to enable by clock") Signed-off-by: John Keeping <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2024-09-05power: regulator: tps6287x: Add driver for TPS6287x step down convertorsKeerthy
Add driver for TPS6287x step down convertors Data sheet: https://www.ti.com/lit/ds/slvsgc5a/slvsgc5a.pdf Signed-off-by: Keerthy <[email protected]>
2024-07-26power: regulator: qcom-rpmh-regulator: add build infraCaleb Connolly
Add Kconfig and Makefile entries for this driver now that it can build for U-Boot. Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-07-26power: regulator: qcom-rpmh-regulator: adjust probe for U-BootCaleb Connolly
Refactor initialization to use U-Boot's driver model and API. Acked-by: Sumit Garg <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-07-26power: regulator: qcom-rpmh-regulator: port ops to U-BootCaleb Connolly
Port over the regulator ops to U-Boot's regulator API. Add back the pmic5 mode map using U-Boot dm_regulator_mode API and adjust the pmic5_pldo and pmic5_pldo_lv definitions. No functional changes. Acked-by: Sumit Garg <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-07-26power: regulator: qcom-rpmh-regulator: remove unused regulatorsCaleb Connolly
Initially just include the few regulators needed for the RB5 board. Others can be added back as-needed. Acked-by: Sumit Garg <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-07-26power: regulator: qcom-rpmh-regulator: adjust structs for U-BootCaleb Connolly
Switch to our linear_range helpers and remove unused/unsupported linux-isms. Acked-by: Sumit Garg <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-07-26power: regulator: qcom-rpmh-regulator: port over lineage_range helpersCaleb Connolly
Import struct linear_range() and builder macro from Linux regulator core. Acked-by: Sumit Garg <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-07-26power: regulator: qcom-rpmh-regulator: adjust headers for U-BootCaleb Connolly
Remove unused/unsupported Linux headers and add necessary U-Boot ones. Acked-by: Sumit Garg <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-07-26power: regulator: import qcom-rpmh-regulator from LinuxCaleb Connolly
Import the driver from Linux 6.10-rc6. Acked-by: Sumit Garg <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-07-22drivers: power: Remove duplicate newlinesMarek Vasut
Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <[email protected]>
2024-07-15power: regulator: add AXP717 supportAndre Przywara
The X-Powers AXP717 is a PMIC with four buck converters and a number of LDOs, one of which is actually fixed (so not modelled here). Add the compatible string and the respective regulator ranges to allow drivers to adjust voltages. Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Ryan Walklin <[email protected]>
2024-07-01Merge branch 'next'Tom Rini
2024-06-28power: regulator: Handle autoset in regulators_enable_boot_on()Simon Glass
With a recent change, regulators_enable_boot_on() returns an error if a regulator is already set. Check for and handle this situation. Fixes: d99fb64a98a power: regulator: Only run autoset once for each regulator Reviewed-by: Jonas Karlman <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Signed-off-by: Simon Glass <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Reviewed-by: Jonas Karlman <[email protected]>
2024-06-24Merge tag 'v2024.07-rc5' into nextTom Rini
Prepare v2024.07-rc5
2024-06-14regulator: rk8xx: clarify operator precedenceQuentin Schulz
My linter complains that the order isn't clear enough so let's put parentheses around the ternary condition to make it happy. Signed-off-by: Quentin Schulz <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]> Reviewed-by: Kever Yang <[email protected]> Reviewed-by: Simon Glass <[email protected]> Tested-by: Simon Glass <[email protected]> # chromebook-bob
2024-06-14regulator: rk8xx: pass pmic udevice instead of regulator to all internal ↵Quentin Schulz
functions For the sake of consistency, make all internal (starting with _) functions expect a pmic udevice instead of a regulator udevice. Signed-off-by: Quentin Schulz <[email protected]> Reviewed-by: Kever Yang <[email protected]> Reviewed-by: Simon Glass <[email protected]> Tested-by: Simon Glass <[email protected]> # chromebook-bob
2024-06-14regulator: rk8xx: fix incorrect device used for _ldo_[sg]et_suspend_valueQuentin Schulz
_ldo_get_suspend_value and _ldo_set_suspend_value get passed the parent of the regulator (so the pmic) as first argument, therefore this udevice should be used for pmic_* callbacks instead of using the parent of the pmic. To avoid further confusion, let's rename the argument to pmic instead of dev, highlighting which kind of device we expect as argument. Fixes: f047e4ab9762 ("regulator: rk8xx: add indirection level for some ldo callbacks") Reported-by: Simon Glass <[email protected]> Signed-off-by: Quentin Schulz <[email protected]> Reviewed-by: Kever Yang <[email protected]> Reviewed-by: Simon Glass <[email protected]> Tested-by: Simon Glass <[email protected]> # chromebook-bob
2024-05-20Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"Tom Rini
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2024-05-19Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2024-05-07power: Remove <common.h> and add needed includesTom Rini
Remove <common.h> from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini <[email protected]>
2024-04-29power: regulator: tps65941: Add TPS65224 PMIC regulator supportBhargav Raviprakash
Reuse TPS65941 regulator driver to adds support for TPS65224 PMIC's regulators. 4 BUCKs and 3 LDOs, where BUCK1 and BUCK2 can be configured in dual phase mode. Signed-off-by: Bhargav Raviprakash <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]>
2024-04-29power: regulator: tps65941: use function callbacks for conversion opsBhargav Raviprakash
Use function callbacks for volt2val, val2volt and slewrate lookups. This makes it easier to add support for TPS65224 PMIC regulators. Signed-off-by: Bhargav Raviprakash <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]>
2024-04-29power: regulator: tps65941: Added macros for BUCK IDBhargav Raviprakash
Adds macros for buck and ldo ids and switched to using switch case instead of if else in probe functions. Helps in adding support for TPS65224 PMIC. Signed-off-by: Bhargav Raviprakash <[email protected]> Reviewed-by: Dhruva Gole <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]>
2024-03-14power: rk8xx: add support for RK806Quentin Schulz
This adds support for RK806, only the SPI variant has been tested. The communication "protocol" over SPI is the following: - write three bytes: - 1 byte: [0:3] length of the payload, [6] Enable CRC, [7] Write - 1 byte: LSB register address - 1 byte: MSB register address - write/read length of payload The CRC is always disabled for now. The RK806 technically supports I2C as well, and this should be able to support it without any change, but it wasn't tested. The DT node name prefix for the buck converters has changed in the Device Tree and is now dcdc-reg. The logic for buck converters is however manageable within the current logic inside the rk8xx regulator driver. The same cannot be said for the NLDO and PLDO. Because pmic_bind_children() parses the DT nodes and extracts the LDO index from the DT node name, NLDO and PLDO will have overlapping indices. Therefore, we need a separate logic from the already-existing ldo callbacks. Let's reuse as much as possible though. Cc: Quentin Schulz <[email protected]> Reviewed-by: Kever Yang <[email protected]> Signed-off-by: Quentin Schulz <[email protected]>