PCA9450 PMIC supports reading the reset status from the PWRON_STAT
register. Bits 7-4 give indication of the PMIC reset cause:
- PWRON (BIT7) - Power ON triggered by PMIC_ON_REQ input line,
- WDOGB (BIT6) - Boot after cold reset by WDOGB pin (watchdog reset),
- SW_RST (BIT5) - Boot after cold reset initiated by the software,
- PMIC_RST (BIT4) - Boot after PMIC_RST_B input line trigger.
Add support for reading reset status via the sysreset framework in a
convenient printable format.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Reviewed-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The family of PCA9450 PMICs have the ability to perform system resets.
Restarting via PMIC is preferred method of restarting the system as all
the peripherals are brought to a know state after a power-cycle. The
PCA9450 features a cold restart procedure which is initiated by an I2C
command 0x14 to the SW_RST register.
Support in Linux for restarting via PCA9450 PMIC has been added by
Linux commit 6157e62b07d9 ("regulator: pca9450: Add restart handler").
Now add support for it also in the U-Boot via sysreset framework.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Reviewed-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
exynos_power_init sets up regulators for the emmc and sdcard, but
these regulators are already marked as always-on and boot-on and hence
are handled already by the regulator-uclass. Since we currently try to
set them up twice we get error -114 (EALREADY) from exynos_power_init
on every boot:
LDO20@VDDQ_EMMC_1.8V: set 1800000 uV; enabling (ret: -114)
LDO22@VDDQ_EMMC_2.8V: set 2800000 uV; enabling (ret: -114)
LDO21@TFLASH_2.8V: set 2800000 uV; enabling (ret: -114)
Remove the superfluous exynos_power_init to silence these errors.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux uses just regulators { }; instead of voltage-regulators { };, so
this change aligns the DTSes found in the two projects.
The max8997 driver does not yet parse the regulators node, so we can
safely change its name without breaking anything.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
All u-boot users now use maxim,max8997-pmic instead, as does Linux's
DTSes, so we can now safely drop the maxim,max8997 compatible.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Instead of maxim,max8997. Linux uses maxim,max8997-pmic, so with this
change we align the trats DTS with its linux counterpart.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux's DTSes uses maxim,max8997-pmic, so check for this compatible
as well so that max8997 pmic driver can support both u-boot and
Linux's DTSes.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux uses just regulators { }; instead of voltage-regulators { };, so
this change aligns the DTSes found in the two projects.
The max8998 driver does not yet parse the regulators node, so we can
safely change its name without breaking anything.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux uses just regulators { }; instead of voltage-regulators { };, so
this change aligns the DTSes found in the two projects.
The max8998 driver does not yet parse the regulators node, so we can
safely change its name without breaking anything.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
All devicetrees that use s2mps11 driver have been converted to use
regulators { };, so we can safely drop the voltage-regulators fallback
check.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
With this both linux and u-boot uses the same node name, which
simplifies devicetree parsing in s2mps11 driver.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux's DTSes uses regulators { }; while u-boot's DTSes uses
voltage-regulators { };. Look for regulators, and fallback to
voltage-regulators if not found, so that both type of DTSes can be
used with the driver.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The sd-vsel-gpios property in the root of the PMIC node is deprecated
and therefore not parsed by the driver anymore. We can safely remove
this as it wasn't used anyway due to the pad not having the correct
pinmux settings.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The sd-vsel-gpios property in the root of the PMIC node is deprecated
and therefore not parsed by the driver anymore. We can safely remove
this as it wasn't used anyway due to the pad not having the correct
pinmux settings.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
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>
This reverts commit 2add051175.
It turns out that all boards using the PCA9450 actually have the
SD_VSEL input connected to the VSELECT signal of the SoCs SD/MMC
interface. Therefore we don't need manual control for this signal
via GPIO and there aren't any users.
This is equivalent to the following change in Linux:
c73be62caabb ("Revert "regulator: pca9450: Add SD_VSEL GPIO for LDO5"")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The code in tps65910_regulator.c treats the field supply in struct
tps65910_regulator_pdata as an int and even tests the value for being
negative so change it from a u32 to int so that the code all works as
expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The video test here is specific to the sandbox SDL video driver, so only
build it when that is enabled rather than VIDEO is enabled.
Reported-by: Alison Chaiken <alison@she-devel.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The MediaTek mt6323 power driver cannot build without access to some
platform specific header files. Express that requirements in Kconfig as
well.
Signed-off-by: Tom Rini <trini@konsulko.com>
The commends in include/power/pmic.h say that once SPL_DM_PMIC exists we
should update things. This has been true for some time, so let us update
this to have the legacy portions in their own header, which should not
be directly included. This cleans up the logic within the file too
slightly.
Signed-off-by: Tom Rini <trini@konsulko.com>
riscv was missing from the list.
To some, the architecture's name may not be obvious from the code name.
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
Strictly speaking, "has" doesn't make sense.
"supports" seems like a better word and it probably was what the original author meant.
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
These are fixes to what looks like obvious typos.
Some minor improvments are also included, such as:
- Write "symbolic link" instead of symlink
- Correct capitalization for LLVM (all caps)
- Remove dead link and surrounding sentence
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
This is needed because distro_efi_read_bootflow_net will then need
dhcp_run which is not already enabled by CMD_NET.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When doing compile testing build we cannot rely on having a valid file
for EFI_VAR_SEED_FILE to exist, so disable this option when doing
compile tests.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
int is not sufficient to hold and test the return from an EFI function
call. Use efi_status_t instead so that the test can work as expected.
This issue was found by Smatch.
Fixes: 275854baee ("efi: Add a serial driver")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
After the commit 7a53abb183 ("rockchip: rk3588: Remove USB3 DRD nodes
in u-boot.dtsi") was merged for v2024.10 there is no reason to keep the
usb nodes for the Generic RK3588 board in the board u-boot.dtsi.
Move usb related nodes from board u-boot.dtsi to main board device tree.
While at it, also drop use of the usb3-phy as we only want to enable the
usb2-phy to be compatible with as many boards as possible.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK3576 SoC comes with USB OTG support using a DWC3 controller with
a USB2 PHY and a USB3 PHY (USBDP PHY).
Some board designs may not use the USBDP PHY for USB3 purpose. For these
board to use USB OTG the input clock source must change to use UTMI clk
instead of PIPE clk.
Change to always disable the USB3OTG0 U3 port early and leave it to the
USBDP PHY driver to re-enable the U3 port when a usb3-phy is described
in the board device tree.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK3588 SoC comes with USB OTG support using a DWC3 controller with
a USB2 PHY and a USB3 PHY (USBDP PHY).
Some board designs may not use the USBDP PHY for USB3 purpose. For these
board to use USB OTG the input clock source must change to use UTMI clk
instead of PIPE clk.
Change to always disable the USB3OTG U3 ports early and leave it to the
USBDP PHY driver to re-enable the U3 port when a usb3-phy is described
in the board device tree.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Rockchip TypeC glue driver improperly present itself as a UCLASS_PHY
driver, without ever implementing the required phy_ops.
This is something that in special circumstances can lead to a NULL
pointer dereference followed by a SError crash.
Change the glue driver to use UCLASS_NOP to fix this.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Rockchip USB2PHY glue driver improperly present itself as a
UCLASS_PHY driver, without ever implementing the required phy_ops.
This is something that in special circumstances can lead to a NULL
pointer dereference followed by a SError crash.
Change the glue driver to use UCLASS_NOP to fix this.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Change to use syscon_regmap_lookup_by_phandle() helper instead of
finding the syscon udevice and making a call to syscon_get_regmap().
No runtime change is expected with this simplication.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The init ops for Rockchip COMBPHY driver is more complex than it needs
to be, e.g. declaring multiple init functions that only differ in the
error message.
Simplify the init ops based on code from the Linux mainline driver.
This change also ensure that errors returned from combphy_cfg() and
reset_deassert_bulk() is propertly propagated to the caller. No other
runtime change is expected with this simplication.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Generic PHY reference counting helps ensure driver ops for init/exit and
power on/off are called at correct state. For this to work the PHY
driver must initialize PHY-id to a persistent value in of_xlate ops.
The Rockchip COMBPHY driver does not initialize the PHY-id field, this
typically lead to use of unshared reference counting among different
struct phy instances.
Initialize the PHY-id in of_xlate ops to ensure use of shared reference
counting among all struct phy instances.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
With working shared reference counting for Generic PHY ops there is no
need for the Rockchip USBDP PHY driver to keep its own status (reference
counting) handling.
Simplify the init ops now that shared reference counting is working.
This also removes the unused mode_change handling as part of the
simplication.
No runtime change is expected with this simplication.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Generic PHY reference counting helps ensure driver ops for init/exit and
power on/off are called at correct state. For this to work the PHY
driver must initialize PHY-id to a persistent value in of_xlate ops.
The Rockchip USBDP PHY driver does not initialize the PHY-id field, this
typically lead to use of unshared reference counting among different
struct phy instances.
Initialize the PHY-id in of_xlate ops to ensure use of shared reference
counting among all struct phy instances.
E.g. on a ROCK 5B following could be observed:
=> usb start
starting USB...
[...]
Bus usb@fc400000: 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
=> usb reset
resetting USB...
[...]
rockchip_udphy phy@fed90000: cmn ana lcpll lock timeout
rockchip_udphy phy@fed90000: failed to init usbdp combophy
rockchip_udphy phy@fed90000: PHY: Failed to init phy@fed90000: -110.
Can't init PHY1
Bus usb@fc400000: probe failed, error -110
scanning usb for storage devices... 0 Storage Device(s) found
With shared reference counting this is fixed:
=> usb reset
resetting USB...
[...]
Bus usb@fc400000: 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
