SL101 unlike TF101/G has no Lid sensor, so lets add a separate env for
SL101 without Lid sensor used.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Hall sensor found in SL101 is not used for closed dock detection as on
TF101 or TF101G, it is used to detect if keyboard slider is out. To address
this, lets move Lid sensor switch into TF101/G trees and add Tablet mode
switch into SL101 tree.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
LAN9514 is a chip on E850-96 board which acts as a USB host hub and
Ethernet controller. It's controlled via USB lines when DWC3 is
configured to be in USB host role (by setting the "dr_mode" property to
"host" value in e850-96 dts file).
Enable network support and LAN9514 chip support. This makes Ethernet
functional on E850-96 board.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Exynos850 SoC has a dual-role USB controller which can be configured in
USB host role. As it's the only one USB controller on the board, it's
shared between "device" USB connector (micro-USB) and host USB
connectors. The hardware automatically powers on the host related parts
when the micro-USB cable (for device role) is being disconnected. Also,
as U-Boot lacks dynamic USB role switching capability, the only way to
switch the role at the moment is to modify "dr_mode" property in
U-Boot's device tree file here:
dts/upstream/src/arm64/exynos/exynos850-e850-96.dts
This won't affect the dynamic role switching later in Linux kernel, as a
separate (different) device tree blob is provided to the kernel.
Enable the USB host support and corresponding commands to make it
functional in E850-96 board.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Linux kernel should use some separate device tree obtained from another
source anyway. For example the dtb file can be read from /boot directory
in eMMC rootfs partition, either by GRUB or U-Boot. Using U-Boot's
device tree blob to provide it to the kernel (when
CONFIG_DEFAULT_FDT_FILE is set and nobody else overrides this choice)
might lead to undesired effects when booting the OS. For example, if a
user sets "dr_mode" property to "host" value in U-Boot's dts to enable
USB host capabilities in U-Boot, it might confuse usb-conn-gpio driver
in Linux kernel later like this:
platform connector: deferred probe pending: usb-conn-gpio:
failed to get role switch
Disable CONFIG_DEFAULT_FDT_FILE option to avoid any possible confusion.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Provide a way for the user to select which storage to load the LDFW
firmware from, by setting the corresponding environment variables:
- bootdev: block device interface name
- bootdevnum: block device number
- bootdevpart: partition number
This might be useful when the OS is flashed and booted from a different
storage device than eMMC (e.g. USB flash drive). In this case it should
be sufficient to just set:
=> setenv bootdev usb
=> env save
assuming that the USB drive layout follows the same partitioning scheme
as defined in $partitions.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Make it possible to provide the information about storage device where
LDFW firmware resides to the firmware loading routine. The firmware
loader code shouldn't have that data hard-coded anyway, and it also
allows for implementing more dynamic behavior later, like choosing the
storage device containing LDFW via some environment variables.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Make use of PMIC configuration routines and enable all LDOs that might
be useful for bootloader and kernel. The most crucial regulator being
enabled at the moment is LDO24 which provides power to LAN9514 chip.
That makes Ethernet controller and USB hub functional.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add functions for configuring voltage regulators on S2MPU12 PMIC chip
for E850-96 board. The chip is accessed by commanding APM core (via
ACPM IPC protocol) to perform corresponding transfers over I3C bus.
The most important regulator being set up is LDO24 used for LAN9514 chip
power. As LAN9514 implements USB hub and Ethernet controller
functionality, it's crucial to enable and configure LDO24 to be able to
use it further. While at it, configure the rest of regulators that might
be needed later, both in the bootloader and in kernel.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add functions to access I3C bus via APM (Active Power Management) core
by using ACPM IPC protocol. It will be further used for configuring PMIC
chip voltage regulators.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Set the environment variable for Ethernet MAC address (ethaddr). Use the
SoC ID to make sure it's unique. It'll be formatted in a way that
follows the consecutive style of the serial number ("serial#" variable),
i.e.:
OTP_CHIPID0 = 0xf51c8113
OTP_CHIPID1 = 0x236
get_chip_id() = 0x236f51c8113
serial# = 00000236f51c8113
ethaddr = 02:36:f5:1c:81:13
where corresponding bytes of the MAC address are:
mac_addr[0] = 0x02 // OTP_CHIPID1[15:8]
mac_addr[1] = 0x36 // OTP_CHIPID1[7:0]
mac_addr[2] = 0xf5 // OTP_CHIPID0[31:24]
mac_addr[3] = 0x1c // OTP_CHIPID0[23:16]
mac_addr[4] = 0x81 // OTP_CHIPID0[15:8]
mac_addr[5] = 0x13 // OTP_CHIPID0[7:0]
because OTP_CHIPID1 has only 16 significant bits (with actual ID
values), and all 32 bits of OTP_CHIPID0 are significant.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
In exynos7420_peric1_get_rate the variable ret is declared as an
'unsigned int' but is then used to receive the return value of
clk_get_by_index which returns an int. The value of ret is then tested
for being less than 0 which will always fail for an unsigned variable.
Fix this by declaring ret as an 'int' so that the test for the error
condition is valid.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Remove unnecessary whitespace before '\n' in trace printf
format strings (checkpatch warning QUOTED_WHITESPACE_BEFORE_NEWLINE).
No functional change intended.
Signed-off-by: Bhimeswararao Matsa <bhimeswararao.matsa@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In sdhci_iproc_execute_tuning the variable tuning_loop_counter is
unsigned and therefore will always fail the test for it being less than
0. Fix this by changing the variable type to be s8.
This issue was 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>
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>
