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 f98d812e53 ("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 f98d812e53.
Reported-by: Dang Huynh <danct12@riseup.net>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
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: 8ef6ac07b3/pipelines
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>
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>
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>
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 <neil.armstrong@linaro.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
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 <trini@konsulko.com>
Signed-off-by: Peng Fan <peng.fan@nxp.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 <andrew.goodbody@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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 <andrew.goodbody@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
There are two ways to set the output voltage of the LD05
regulator. First by writing to the voltage selection registers
and second by toggling the SD_VSEL signal.
Usually board designers connect SD_VSEL to the VSELECT signal
controlled by the USDHC controller, but in some cases the
signal is hardwired to a fixed low level (therefore selecting
3.3V as initial value for allowing to boot from the SD card).
In these cases, the voltage is only determined by the value
of the LDO5CTRL_L register. Introduce a property
nxp,sd-vsel-fixed-low to let the driver know that SD_VSEL
is low and there is no GPIO to actually get that
information from dynamically.
This is equivalent to the following change in Linux:
c8c1ab2c5cb7 ("regulator: pca9450: Handle hardware with fixed SD_VSEL for LDO5")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
For LDO5 we need to be able to check the status of the SD_VSEL input in
order to know which control register is used. Read the status of the
SD_VSEL signal via GPIO and use the correct register accordingly.
To use this, the LDO5 node in the devicetree needs the sd-vsel-gpios
property to reference the GPIO that is used to read back the SD_VSEL
status internally. Please note that the SION bit in the IOMUX must be
set if the signal is muxed as VSELECT and controlled by the USDHC
controller.
This is equivalent to the following change in Linux:
3ce6f4f943dd ("regulator: pca9450: Fix control register for LDO5")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The LDO5 regulator has two configuration registers, but only
LDO5CTRL_L contains the bits for enabling/disabling the regulator.
This is equivalent to the following change in Linux:
f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5")
Fixes: 326337fb00 ("pmic: pca9450: Add regulator driver")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In tps65941_buck_val and tps65941_ldo_val hex is an unsigned variable
being assigned the return value from a function that returns int. Change
hex to be an int so that the following test for an error as a negative
value will work as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In order to get the expected result from
rzg2l_usbphy_regulator_get_enable the return expression needs
parenthesis so that the binary and is performed before the double
logical not.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In palmas_smps_val and palmas_ldo_val hex is an unsigned variable being
assigned the return value from a function that returns int. Change hex
to be an int so that the following test for an error as a negative value
will work as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In lp87565_buck_val hex is an unsigned variable being assigned the return
value from a function that returns int. Change hex to be an int so that
the following test for an error as a negative value will work as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In lp873x_buck_val and lp873x_ldo_val hex is an unsigned variable being
assigned the return value from a function that returns int. Change hex
to be an int so that the following test for an error as a negative value
will work as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
The X-Powers AXP323 is very close sibling to the AXP313A, only that it
adds support for dual-phasing the first two DC/DC converters.
We do not really care about this particular feature, so just add the new
compatible string and tie it to the existing AXP313A support code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
uclass_find_next_device always returns 0, so instead make it a void and
update calling sites.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
E Shattow <e@freeshell.de> says:
Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot.
There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix
or placeholder in documentation and error messages.
External devicetree-rebasing dts/upstream and the generated code of
xilinx/zynq are ignored for the series.
Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de
Use consistent lowercase hex prefix style in drivers/*
Does not change hex prefix case in allcaps uppercase style error messages
Signed-off-by: E Shattow <e@freeshell.de>
Allows use of the regulator functions of the RK8XX PMIC in SPL, which is
necessary to support the functionality of the Rockchip IO-domain driver
on relevant platforms.
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Added a new regulator driver for the MAXIM MAX8907 PMIC, providing
essential regulator functionalities and incorporated the necessary binding
framework within the core PMIC driver.
Tested-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
If there is a SoC specific SCMI protocol driver, using
scmi_proto_driver_get() function can avoid to add SoC specific code to
scmi_agent-uclass.c.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
AXP PMICs have a pin which can either report the USB VBUS state, or
driving a regulator that supplies USB VBUS. Add a regulator driver for
controlling this pin. The selection between input and output is done via
the x-powers,drive-vbus-en pin on the PMIC (parent) node.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The current code attempts to bind scmi_voltage_domain to regulator subnode
of the SCMI protocol node, so scmi_voltage_domain can then bind regulators
directly to subnodes of its node. This kind of behavior should not be in
core code, move it into scmi_voltage_domain driver code. Let the driver
descend into regulator node and bind regulators to its subnodes.
Fixes: 1f213ee4db ("firmware: scmi: voltage regulator")
Signed-off-by: Marek Vasut <marex@denx.de>
[Alice Guo: Fix scmi_regulator_bind]
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
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: 5d7dbd22cf ("power: regulator: tps65941: use function callbacks for conversion ops")
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
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 <s-ramamoorthy@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
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 <s-ramamoorthy@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Simon Glass <sjg@chromium.org> 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.
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 <sjg@chromium.org>
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 <joy.zou@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Both regulators_enable_boot_on/off() are unused and superseded by
regulator uclass regulator_post_probe(). Remove both functions.
Signed-off-by: Marek Vasut <marex@denx.de>
