| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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 <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tegra into next
|
|
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 <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
Fix a missing closing quote in the error message when a regulator name
is not unique.
Signed-off-by: David Lechner <[email protected]>
Reviewed-by: Julien Stephan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]> # RK8xx
|
|
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 <[email protected]>
|
|
Add Mapphone and Mot compatibles supported by Linux kernel.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
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 <[email protected]>
|
|
Prepare v2026.04-rc4
|
|
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 <[email protected]>
Closes: https://lore.kernel.org/u-boot/[email protected]/
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Co-developed-by: Macpaul Lin <[email protected]>
Signed-off-by: Macpaul Lin <[email protected]>
Co-developed-by: Bo-Chen Chen <[email protected]>
Signed-off-by: Bo-Chen Chen <[email protected]>
Signed-off-by: David Lechner <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: David Lechner <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add a driver for the power regulators of the MediaTek MT6357 PMIC chip.
Signed-off-by: Julien Masson <[email protected]>
Co-developed-by: Macpaul Lin <[email protected]>
Signed-off-by: Macpaul Lin <[email protected]>
Signed-off-by: David Lechner <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Peng Fan (OSS) <[email protected]> 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/[email protected]
|
|
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 <[email protected]> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <[email protected]> #TI boards
Acked-by: Yao Zi <[email protected]> #TH1520
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Tien Fong Chee <[email protected]>
# Conflicts:
# drivers/ddr/altera/Makefile
|
|
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 <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Julien Stephan <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Use dm_gpio_is_valid() helper function instead of manually checking the
gpio.
Reviewed-by: Peng Fan <[email protected]>
Reviewed-by: Tanmay Kathpalia <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Julien Stephan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Drop the ftrace like debug() that checkpatch --strict complains about:
WARNING: Unnecessary ftrace-like logging - prefer using ftrace
Reviewed-by: Peng Fan <[email protected]>
Reviewed-by: Tanmay Kathpalia <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Julien Stephan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
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/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
gpio-regulator uses dm gpio API, so it depends on SPL_DM_GPIO, not
SPL_GPIO.
Reported-by: Tom Rini <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
Reviewed-by: Kory Maincent <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Udit Kumar <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
Reviewed-by: Kory Maincent <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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) <[email protected]>
|
|
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 <[email protected]>
Tested-by: Hrushikesh Salunke <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
|
|
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
|
|
Remove duplicate #include "regulator_common.h" statements from regulator
driver files.
Signed-off-by: Tanmay Kathpalia <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
There are multiple PMICs by Samsung which are similar in architecture
(register layout, interface, etc.) and is possible to be driven by a
single driver. Variant specific code and data should be managed properly
in the driver.
And an enum which describes all supported variants. Pass the enum as the
device driver data. Introduce a switch-case block on the enum for any
variant specific code.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The probe function, s2mps11_probe() is responsible for binding its PMIC
children. The driver doesn't have any functionality directly, but has
sub-devices which are parts of the device. Therefore, this should be a
bind function. This is the case in the Samsung S5M8767 PMIC driver.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add the pm6150l regulator data found on the Qualcomm SM6350 platform.
The tables are imported from the Linux driver. The SMPS regulators were
not added now.
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Luca Weiss <[email protected]>
|
|
Some drivers which depend on SoCFPGA specific headers had not had
appropriate dependencies list in Kconfig. Add ARCH_SOCFPGA or
TARGET_SOCFPGA_SOC64 where appropriate.
Signed-off-by: Tom Rini <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze
AMD/Xilinx/FPGA changes for v2026.01-rc1 v2
zynqmp:
- DT updates
- Enable new commands
mbv:
- Simplify defconfigs
clk:
- Separate legacy handler and use SMC handler
misc:
- Tighten TTC Kconfig dependency
net:
- Add 10GBE support to Gem
pwm:
- cadence-ttc: Fix array sizes
fwu:
- Add platform hook support
spi:
- Remove undocumented cdns,is-dma property
video:
- Fix DPSUB RGB handling
|
|
In order to enable and build with SPL_REGULATOR_PWM we need to have both
SPL_DM_REGULATOR and SPL_DM_PWM enabled. Build-wise, we can have SPL
have PWM regulator support without enabling it in U-Boot itself so drop
that dependency.
Signed-off-by: Tom Rini <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Currently xilinx_pm_request API supports four u32 payloads. However the
legacy SMC format supports five u32 request payloads and extended SMC
format supports six u32 request payloads. Add support for the same in
xilinx_pm_request API. Also add two dummy arguments to all the callers
of xilinx_pm_request.
The TF-A always fills seven u32 return payload so add support
for the same in xilinx_pm_request API.
Signed-off-by: Naman Trivedi <[email protected]>
Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]>
Acked-by: Senthil Nathan Thangaraj <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/5ae6b560741f3ca8b89059c4ebb87acf75b4718e.1756388537.git.michal.simek@amd.com
|
|
In regulator_list_autoset there is a test for ret being non-zero and
error being zero but it uses the binary '&' instead of the logical '&&'
which could well lead to unexpected results. Correct this to use the
logical '&&' instead.
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
se_desc loop check is wrong, it relies on the desc always has
the expected name to end of the loop. It works because the device tree
has the expected name as of now, but this may not be always true.
Drop se_desc by moving the check into probe and fix the loop check.
Reported-by: Andrew Goodbody <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Fabio Estevam <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Enable the vin-supply when probing the regulator device.
Signed-off-by: Ye Li <[email protected]>
|
|
Prepare v2025.10-rc4
|
