summaryrefslogtreecommitdiff
path: root/drivers/power
AgeCommit message (Collapse)Author
8 dayspower: pmic: mtk-pwrap: add MT8195 supportJulien Stephan
Add mt8195 support. Support comes directly from commit e88edc977b00 ("soc: mediatek: pwrap: add pwrap driver for MT8195 SoC") from the Linux Kernel. Signed-off-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-8-73e83aa6345b@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
8 dayspower: pmic: mtk-pwrap: use tabs for alignmentJulien Stephan
Fix mt8188_regs definition to use tabs instead of spaces for alignment to be consistent with other definitions. Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-7-73e83aa6345b@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
8 dayspower: pmic: mtk-pwrap: use pmic compatible to select child infoDavid Lechner
Change the logic for selecting pmic_children_info to use the compatible string from the devicetree instead of expecting the pwrap (part of the MCU) to correspond to the separate PMIC chip. In addition to being more correct, it also saves a few lines of code for each MCU type that is added by dropping the enum and type field. Reviewed-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-6-73e83aa6345b@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
8 dayspower: pmic: mtk-pwrap: remove interrupt related codeDavid Lechner
Remove the interrupt related code in mtk-pwrap driver. This was just enabling interrupts without any handler. Even if we did have a handler, the only thing we could do is log a message. Since U-Boot isn't long running, this likely wouldn't be very useful. Reviewed-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-5-73e83aa6345b@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
8 dayspower: pmic: mtk-pwrap: drop PWRAP_SLV_CAP_DUALIO on mt6359David Lechner
Drop the PWRAP_SLV_CAP_DUALIO flag from the mt6359 PMIC definition. The mt6359p variant of the PMIC does support dual I/O. Prior to this change, the driver would attempt to write to the PWRAP_DEW_DIO_EN register, which was not defined, so would write register 0 (DONE2). Reviewed-by: Julien Stephan <jstephan@baylibre.com> Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com> Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-4-73e83aa6345b@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
8 dayspower: pmic: mtk-pwrap: add init capability flagDavid Lechner
Add a PWRAP_CAP_INIT capability flag to specify if it is safe to call pwrap_init() or not. Not all targets define the registers accessed by pwrap_init(). In that case, it is expected that an earlier bootloader has already initialized the PMIC. If not, we now return an error instead of trying to access undefined registers. Reviewed-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-3-73e83aa6345b@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
8 dayspower: pmic: mtk-pwrap: add PWRAP_CAP_WDT_SRC flagDavid Lechner
Add a PWRAP_CAP_WDT_SRC flag to indicate if a PMIC wrapper has a WDT_SRC or not. Then use this to conditionally enable the watchdog timer. Prior to this change, since the register was not defined, it defaulted to 0, so the wrong register (DONE2) was being written to. Reviewed-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-2-73e83aa6345b@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
8 dayspower: pmic: mtk-pwrap: fix file descriptionDavid Lechner
Fix the comment at the start of the file to accurately describe what this file does. The old description was likely copied from the related regulator driver. Reviewed-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-1-73e83aa6345b@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
10 daysregulator: qcom-rpmh-regulator: add support for PM7550 regulatorsLuca Weiss
Add the PM7550 regulator data found on Qualcomm Milos devices. The tables are imported from the Linux driver (tag v7.0-rc4). The SMPS regulators were not added now. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://patch.msgid.link/20260318-milos-bringup-v2-4-650b91dd75d8@fairphone.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
10 dayspower-domain: Add warning when power-domain driver is missingAswin Murugan
Update dev_power_domain_ctrl() to log a warning if the power-domain driver is not found (-ENODEV). Return 0 in this case to allow continued execution, while preserving error handling for other failures. Reviewed-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://patch.msgid.link/20260213111009.1254360-3-aswin.murugan@oss.qualcomm.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
10 dayspower-domain: Add QCOM RPMH Power Domain Driver SupportBalaji Selvanathan
Added support for Qualcomm RPMH power domain driver, responsible for managing power domains on Qualcomm SoCs. This is a port of the Linux RPMHPD driver [1] and sa8775p related changes. The power domain driver currently has support to power on and off MMCX power domain of sa8775p; support for other soc entries power domains are stubbed, in future, the required soc support can be added. [1]: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pmdomain/qcom/rpmhpd.c?id=3d25d46a255a83f94d7d4d4216f38aafc8e116b Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com> Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://patch.msgid.link/20260213111009.1254360-2-aswin.murugan@oss.qualcomm.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-04-06Merge branch 'next'Tom Rini
2026-03-30sysreset: Rework tests around SYSRESET_CMD_POWEROFFTom Rini
As exposed by "make randconfig", we have an issue around how SYSRESET_CMD_POWEROFF is typically selected. We cannot rely only on CMD_POWEROFF as SYSRESET_CMD_POWEROFF must also be tested for its own dependency of SYSRESET. Signed-off-by: Tom Rini <trini@konsulko.com>
2026-03-25Merge branch 'staging' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-tegra into next
2026-03-24power: regulator: qcom: Correct dependenecies for DM_REGULATOR_QCOM_USB_VBUSTom Rini
The DM_REGULATOR_QCOM_USB_VBUS functionality can only work with DM_PMIC enabled as well, so express this dependency in Kconfig. Signed-off-by: Tom Rini <trini@konsulko.com> Link: https://patch.msgid.link/20260323195302.2363577-1-trini@konsulko.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-03-23dm: regulator: fix missing quote in error messageDavid Lechner
Fix a missing closing quote in the error message when a regulator name is not unique. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-03-22power: pmic: enable sysreset function with device tree propertySvyatoslav Ryhel
Add a condition to enable the PMIC sysreset function via the system-power-controller device tree property in addition to the existing Kconfig dependency, provided the PMIC supports it. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> # RK8xx
2026-03-22power: cpcap: make regulator node names case independentSvyatoslav Ryhel
The Linux kernel CPCAP driver uses uppercase regulator node names, while this driver uses lowercase. Since regulator names can be case-insensitive, update the driver to support both uppercase and lowercase node names. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
2026-03-22power: pmic: cpcap: add Mapphone and Mot compatiblesSvyatoslav Ryhel
Add Mapphone and Mot compatibles supported by Linux kernel. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
2026-03-22power: regulator: cpcap: remove bit_offset_from_cpcap_lowest_voltageSvyatoslav Ryhel
The bit_offset_from_cpcap_lowest_voltage value was inherited from the downstream kernel as a quirk. With the correct voltage table, it is no longer needed. An additional benefit is that SW1, SW2, and SW4 now share the same voltage table. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
2026-03-09Merge tag 'v2026.04-rc4' into nextTom Rini
Prepare v2026.04-rc4
2026-02-26power: domain: Validate device tree node in dev_power_domain_ctrlPeng Fan
Similar to pinctrl_select_state(), add dev_has_ofnode() check before doing the real work. Device(scmi_base.0) does not have a real device node, ofnode_null() is assigned as the device tree node for scmi base protocol device: 'commit 7eb4eb541c14 ("firmware: scmi: install base protocol to SCMI agent")' However with recent update in 'commit 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c")', SPL panic in fdt_check_node_offset_()->fdt_next_tag(), because offset is -1 and SPL_OF_LIBFDT_ASSUME_MASK is 0xFF. So need to validate device tree node. Reported-by: Ye Li <ye.li@nxp.com> Closes: https://lore.kernel.org/u-boot/939a9696-27fa-45a1-b428-feffe21ac6d5@oss.nxp.com/ Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-25power: regulator: Kconfig: add SPL_DM_REGULATOR_FAN53555Heinrich Schuchardt
Symbol CONFIG_SPL_DM_REGULATOR_FAN53555 is selected by SPL_DM_PMIC_FAN53555 and used in a Makefile. But the symbol definition is missing. Add the missing configuration symbol. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-25power: pmic: mtk-pwrap: add MediaTek PMIC Wrapper driverJulien Masson
Add support for the PMIC wrapper (pwrap) IP block found on MediaTek MT8365 and similar SoCs. On these SoCs the PMIC is connected via SPI. The SPI controller is not directly visible to the CPU, but only through the PMIC wrapper inside the SoC. Signed-off-by: Julien Masson <jmasson@baylibre.com> Co-developed-by: Macpaul Lin <macpaul.lin@mediatek.com> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Co-developed-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-25power: regulator: mt6359: add driver for MT6359PBo-Chen Chen
Add a new regulator driver for MT6359P and similar PMIC chips. The MT6359P is a eco version for MT6359 regulator. For the MT8391 platform, we use the MT6359P (MT6365) as the main PMIC. The MT6359 and MT6359P have different register maps. Therefore, on the MT8391 platform, we only provide support for the MT6359P. If support for the MT6359 PMIC it can be added later. Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-25power: regulator: add MediaTek MT6357 driverJulien Masson
Add a driver for the power regulators of the MediaTek MT6357 PMIC chip. Signed-off-by: Julien Masson <jmasson@baylibre.com> Co-developed-by: Macpaul Lin <macpaul.lin@mediatek.com> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-17Merge patch series "treewide: Clean up usage of DECLARE_GLOBAL_DATA_PTR"Tom Rini
Peng Fan (OSS) <peng.fan@oss.nxp.com> says: This patch set primarily removes unused DECLARE_GLOBAL_DATA_PTR instances. Many files declare DECLARE_GLOBAL_DATA_PTR and include asm/global_data.h even though gd is never used. In these cases, asm/global_data.h is effectively treated as a proxy header, which is not a good practice. Following the Include What You Use principle, files should include only the headers they actually depend on, rather than relying on global_data.h indirectly. This approach is also adopted in Linux kernel [1]. The first few patches are prepartion to avoid building break after remove the including of global_data.h. A script is for filtering the files: list=`find . -name "*.[ch]"` for source in ${list} do result=`sed -n '/DECLARE_GLOBAL_DATA_PTR/p' ${source}` if [ "${result}" == "DECLARE_GLOBAL_DATA_PTR;" ]; then echo "Found in ${source}" result=`sed -n '/\<gd\>/p' ${source}` result2=`sed -n '/\<gd_/p' ${source}` result3=`sed -n '/\<gd->/p' ${source}` if [ "${result}" == "" ] && [ "${result2}" == "" ] && [ "${result3}" == "" ];then echo "Cleanup ${source}" sed -i '/DECLARE_GLOBAL_DATA_PTR/{N;/\n[[:space:]]*$/d;s/.*\n//;}' ${source} sed -i '/DECLARE_GLOBAL_DATA_PTR/d' ${source} sed -i '/global_data.h/d' ${source} git add ${source} fi fi done [1] https://lpc.events/event/17/contributions/1620/attachments/1228/2520/Linux%20Kernel%20Header%20Optimization.pdf CI: https://github.com/u-boot/u-boot/pull/865 Link: https://lore.kernel.org/r/20260209-cleanup-v2-0-73a3a84ddbdb@nxp.com
2026-02-17treewide: Clean up DECLARE_GLOBAL_DATA_PTR usagePeng Fan
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and drop the unnecessary inclusion of asm/global_data.h. Headers should be included directly by the files that need them, rather than indirectly via global_data.h. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards Acked-by: Yao Zi <me@ziyao.cc> #TH1520 Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-14Replace TARGET namespace and cleanup properlyTien Fong Chee
TARGET namespace is for machines / boards / what-have-you that building U-Boot for. Simply replace from TARGET to ARCH make things more clear and proper for ALL SoCFPGA. Signed-off-by: Brian Sune <briansune@gmail.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com> # Conflicts: # drivers/ddr/altera/Makefile
2026-01-25power: regulator: enable AWP318W SPL supportYixun Lan
Add the descriptions for the DC/DC regulators of the AXP318W, and enable it when CONFIG_AXP318W_POWER is enabled. Signed-off-by: Yixun Lan <dlan@gentoo.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2026-01-25power: regulator: add AXP318W supportYixun Lan
The PMIC is also known as AXP819 in vendor pmu code For DCDC6, 8, 9, the underlying hardware support more than two levels voltage step tuning, but for now only first two levels are implemented in this driver, hence highest voltage will be limited at seccond level. It actual meets board requirement in current design, and we've verified it in Radxa Cubie A7A board. Following are detail explanation of voltage tuning stpes for those DCDCs: DCDC | voltage range | units | steps | implemented 6 | 0.5 - 1.2 | 10 mV | 71 | Y . | 1.22 - 1.54 | 20 mV | 17 | Y . | 1.8 - 2.4 | 20 mV | 31 | N . | 2.44 - 2.76 | 40 mV | 9 | N -------------------------------------------------- 8/9 | 0.5 - 1.2 | 10 mV | 71 | Y . | 1.22 - 1.84 | 20 mV | 32 | Y . | 1.9 - 3.4 | 100mV | 16 | N Signed-off-by: Yixun Lan <dlan@gentoo.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2026-01-22power: regulator: common: fix compilation issueJulien Stephan
If CONFIG_DM_GPIO is not enabled, compilation fails with the following errors: aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_of_to_plat': <...>/u-boot/drivers/power/regulator/regulator_common.c:30: undefined reference to `gpio_request_by_name' aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_get_enable': <...>/u-boot/drivers/power/regulator/regulator_common.c:57: undefined reference to `dm_gpio_get_value' aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_set_enable': <...>/u-boot/drivers/power/regulator/regulator_common.c:92: undefined reference to `dm_gpio_set_value' make: *** [Makefile:2029: u-boot] Error 139 Since the enable gpio is optional we can conditionally skip these calls. Reviewed-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-01-22power: regulator: common: use dm_gpio_is_valid helperJulien Stephan
Use dm_gpio_is_valid() helper function instead of manually checking the gpio. Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-01-22power: regulator: common: remove unnecessary debug traceJulien Stephan
Drop the ftrace like debug() that checkpatch --strict complains about: WARNING: Unnecessary ftrace-like logging - prefer using ftrace Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-01-14power: regulator: qcom-rpmh: correctly map pmic modeCasey Connolly
Currently we don't properly map between the regulator mode ID enum and the appropriate register values in the mode map, as a result we always unintentionally vote for retention mode if we actually attempt to set it. In the set_mode path we did find the appropriate entry in the mode map but we wrote the id instead of the register values. Clean this up and properly map id -> mode and vice versa. Link: https://patch.msgid.link/20260108-rpmh-regulator-fixes-v1-6-d1b5b300b665@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-01-14power: regulator: qcom-rpmh: read votes from rpmhCasey Connolly
Make use of the new RPMh read support to fetch regulator values that may have been voted on by a previous bootloader stage. This allows commands like "regulator status" to report the actual votes programmed into hardware (though not necessarily the actual states of the regulators once the votes have been aggregated). Link: https://patch.msgid.link/20260108-rpmh-regulator-fixes-v1-5-d1b5b300b665@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-01-14regulator: qcom-rpmh-regulator: add support for PM8150 PM8350 PM7325Aswin Murugan
Add the PM8150, PM8350, and PM7325 regulator data found on Qualcomm platforms. These regulator tables are imported from the Linux driver to enable support for these PMICs in U-Boot. Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251112164204.1557934-1-aswin.murugan@oss.qualcomm.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-01-09dm: core: Default to using DEVRES outside of xPLTom Rini
The devm alloc functions that we have may follow the Linux kernel model where allocations are (almost always) automatically free()'d. However, quite often we don't enable, in full U-Boot, the tracking and free()'ing functionality. This in turn leads to memory leaks because the driver author expects that since the functions have the same name as in the Linux Kernel they have the same behavior. In turn we then get functionally correct commits such as commit 00e1fed93c8c ("firmware: ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually add these calls. Rather than manually tracking allocations and implementing free()s, rework things so that we follow expectations by enabling the DEVRES functionality (outside of xPL phases). This turns DEVRES from a prompted symbol to a symbol that must be select'd, and we now remove our non-managed alloc/free functions from outside of xPL builds. Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2025-12-24power: regulator: Fix dependency of SPL_DM_REGULATOR_GPIOPeng Fan
gpio-regulator uses dm gpio API, so it depends on SPL_DM_GPIO, not SPL_GPIO. Reported-by: Tom Rini <trini@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-12-24power: regulator: remove SPL_REGULATOR_PWM due to unmeetable SPL_DM_PWM ↵Quentin Schulz
dependency SPL_DM_PWM option simply doesn't exist. Moreover, drivers/pwm is only included by drivers/Makefile for non-xPL stages so making SPL_REGULATOR_PWM properly build for SPL/xPL is more involved than just adding an SPL_DM_PWM option. Reading the original commit (ddc824f89aa8 ("power: regulator: Allow PWM regulator to be omitted from SPL."), the intent seemingly wasn't to allow building support in XPL but rather to allow removing it which is done by using $(PHASE_) ($(SPL_) at that time) in the Makefile. If anyone needs that, let them figure out what they need to do without misleading potential users of this symbol by simply removing it. Fixes: 2a846e04c622 ("power: regulator: Correct dependencies on SPL_REGULATOR_PWM") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Anshul Dalal <anshuld@ti.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-12-24power: regulator: fix dependency for REGULATOR_PWMQuentin Schulz
The PWM regulator driver is a uclass driver, thus requiring DM_PWM to be enabled to be actually usable (and with the appropriate PWM controller driver enabled as well, but that we cannot enforce easily), so let's add this missing dependency. Fixes: 1a01695615f9 ("power: regulator: add pwm regulator") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Udit Kumar <u-kumar1@ti.com> Reviewed-by: Anshul Dalal <anshuld@ti.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-12-12power: domain: Add ti-omap-prm stubMarkus Schneider-Pargmann (TI.com)
Upstream DT uses simple-pm-bus instead of simple-bus. simple-pm-bus requires power domain support. On am33xx, PRM manages power domains but all domains are enabled at boot. Add stub driver with custom of_xlate that expects no argumetns to allow simple-pm-bus and dependent devices to probe. Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
2025-11-27power: domain: ti: fix ti_pd_get() to return after verifying transitionSiddharth Vadapalli
The helper function "ti_pd_get()" is responsible for powering on a domain if it is powered off. In the current implementation, if a power domain is determined to be powered off - no prior users and the PDCTL register indicates that the user desired state is OFF, then powering on the domain constitutes setting 'PDCTL_STATE_ON' field of the PDCTL register. While the current implementation indeed requests the power domain to be transition to the ON state, the helper function "ti_pd_get()" doesn't verify that the power domain has 'transitioned' to the ON state before returning to its caller. As a result, it is possible that the device(s) belonging to the power domain may be accessed before it is truly powered on, leading to a bus abort. Fix this by waiting for the power domain to transition to the ON state by using "ti_pd_wait()" before returning from "ti_pd_get()". Fixes: 144464bd2c67 ("power: domain: Introduce driver for raw TI K3 PDs") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Tested-by: Hrushikesh Salunke <h-salunke@ti.com>
2025-11-06Revert "power: regulator: Add vin-supply for GPIO and Fixed regulators"Jonas Karlman
Rockchip boards may depend on a working MMC regulator in SPL to successfully load FIT payload from MMC. Typically, these boards only include the vmmc-supply regulator and not its vin-supply in SPL control FDT. The commit f98d812e5353 ("power: regulator: Add vin-supply for GPIO and Fixed regulators") breaks loading FIT from MMC in SPL on some of these boards due to now requiring the vin-supply to be included in the SPL control FDT. The commit also strangely enables any found vin-supply in regulator_common_of_to_plat() and not when a regulator is enabled or as part of regulator_autoset(). Revert the commit to fix FIT loading in SPL on broken boards. If a board needs to have its vin-supply enabled, two options come to mind: - Add regulator-always-on prop to the regulator in the -u-boot.dtsi for any board. - Implement full support for reference counting of regulators and then update the regulator-uclass to enable any found vin-supply when a regulator is enabled. This reverts commit f98d812e5353408ef77a46bad1f1cdc793ff8a03. Reported-by: Dang Huynh <danct12@riseup.net> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Dragan Simic <dsimic@manjaro.org>
2025-10-30Merge tag 'qcom-for-2026.01-rc2' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-snapdragon A variety of Qualcomm features/fixes for this cycle, notably with a few new platforms gaining support: * Initial support for SDM670 (similar to SDM845), SM6350, and SM7150 platforms is added * USB and UART issues on MSM8916 are addressed (improving stability/ reliability) * Firmware loading is implemented for the GENI serial engine, this is used on some platforms to load firmware for i2c/spi/uart to work Some additional patches like binman support for building MBN files still need some additional work. CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/8ef6ac07b35e39a57501554680bbf452e818d3e3/pipelines?ref=qcom-main
2025-10-30power: regulator: Remove duplicate include of regulator_common.hTanmay Kathpalia
Remove duplicate #include "regulator_common.h" statements from regulator driver files. Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-10-30power: pmic: s2mps11: add support for Samsung S2MPU05 PMICKaustabh Chakraborty
Samsung S2MPU05 PMIC is used in devices with the Exynos7870 SoC, it houses voltage regulators and an RTC module. Add support for this device variant in the driver, which also binds the corresponding voltage regulator driver. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-10-30power: regulator: s2mps11: add support for S2MPU05 PMICKaustabh Chakraborty
Samsung's S2MPU05 PMIC is used by Exynos7870 SoC. It has 5 buck and 38 LDO regulators. Add support for this device variant in the driver. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-10-30power: regulator: s2mps11: declaratively get/set regulator modeKaustabh Chakraborty
The functions s2mps11_{buck,ldo}_mode use the s2mps11_{buck,ldo}_modes arrays directly in order to extract the mode of a certain register. This approach does not allow similar devices of other variants (which may support a different set of modes) to work with the same driver. Instead of using these arrays hardcoded, extract them from the device's uclass platform data. Now the responsibility of setting these arrays properly is done by functions s2mps11_{buck,ldo}_probe, by implementing a switch-case block which can support modes of multiple variants if and when added. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-10-30power: regulator: s2mps11: declaratively define LDOs and BUCKsKaustabh Chakraborty
In the Linux kernel driver, all information related to LDO and BUCK regulators are stored in descriptive arrays. This also allows multiple variants to be supported by the same driver. Define a struct sec_regulator_desc which holds all values required by a regulator. Create an array of said struct containing all regulators. The descriptors are designed to follow a style similar to what's seen in the Linux driver, so comparing one with the other is simple. In functions such as s2mps11_{buck,ldo}_{val,mode} these values are to be used, make necessary modifications to pull them from the descriptors. Since multiple variants have varying descriptors, select them from within a switch-case block. Functions s2mps11_{buck,ldo}_{volt2hex,hex2volt} and arrays s2mps11_buck_{ctrl,out} are phased out as the calculations are now hardcoded in descriptors, thusly, it reduces clutter and enhances readability. Two macros in s2mps11.h, S2MPS11_LDO_NUM and S2MPS11_BUCK_NUM are removed as they are no longer being used. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>