Commit f32a8007 ("dm: i2c: Make i2c_get_chip_for_busnum() fail if the
chip is not detected") introduced a regression for the NVIDIA Jetson TX2.

For some reason the xfer callback of the tegra i2c driver doesn't support
probing the I2C devices with a 0-length message.
Fixing the regression by providing a dummy implementation of probe_chip()
that does nothing.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Tested-by: NStephen Warren <swarren@nvidia.com>

The genboardscfg.py script will emit a WARNING message if we have new
defconfig files that are not listed in a MAINTAINERS file.  Make new
cases of this a failure we catch in Travis-CI.
Signed-off-by: NTom Rini <trini@konsulko.com>

Add TFA boot flow for some Layerscape platforms
Add support for lx2160a SoC

[trini: Add a bunch of missing MAINTAINERS entries]
Signed-off-by: NTom Rini <trini@konsulko.com>

- mips: bcm: disable CONFIG_SWAP_IO_SPACE to force native endianess in readl() & co.
  this fixes 09ace916
- mips: bcm6838: fix device tree warning

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Improvements:
- init DRAM for RK322x in SPL
- add FAN53555 PMIC/regulator driver
- update MicroCrystal RV3029 driver to Kconfig and sync from Linux
- add bootcount uclass and first DM-driver for bootcount

- DM_I2C_COMPAT removal for all ti platforms from Jean-Jacques Hiblot
- Fix in i2c command help output from Chirstoph Muellner.

- DWC3 and UDC cleanup

- Enable RTC for Intel Tangier
- Wrap the call to 8259 PIC with Kconfig options for old targets without
  8259
- Warp the call to USB init with Kconfg options for coreboot & EFI
  payload

Now that we have FAN53555 support, we can enable the regulators in our
DTS.  To make these easier to identify on the U-Boot commandline, we
rename them to the names of the voltage rails they control.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

With a driver for the FAN53555 regulator family available, let's
enable it for the RK3399-Q7 (which has two of these devices
on-module).

We enable this for the full U-Boot stage only, as these regulators
provide a suitable default voltage and supply non-critical (i.e.
for booting up) power rails only.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

This adds a driver for the FAN53555 family of regulators and wraps it
in a PMIC implementation.

While these devices support a 'normal' and 'suspend' mode (controlled
via an external pin) to switch between two programmable voltages, this
incarnation of the driver assumes that the device is always operating
in 'normal' mode.

Only setting/reading the programmed voltage is supported at this time
and the following device functionality remains unsupported:
  - switching the selected voltage (via a GPIO)
  - disabling the voltage output via software-control
This matches the functionality of the Linux driver.

Tested on a RK3399-Q7 (with 'option 5' devices): setting voltages from
the U-Boot shell and verifying output voltages on the board.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>

This implements a driver using a RTC-based backing store for the DM
bootcount implementation.  The node configuring this feature will be
compatible with 'u-boot,bootcount-rtc' and the underlying RTC device
shall be reference through the property 'rtc'. An offset into the RTC
device's register space can be provided through the 'offset' property.

Tested on a RK3399-Q7 on a Flamingo carrier board using the SRAM area
of the carrier board's RV3029 RTC.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

The original bootcount methods do not provide an interface to DM and
rely on a static configuration for I2C devices (e.g. bus, chip-addr,
etc. are configured through defines statically).  On a modern system
that exposes multiple devices in a DTS-configurable way, this is less
than optimal and a interface to DM-based devices will be desirable.

This adds a simple driver that is DM-aware and configurable via DTS.
If ambiguous (i.e. multiple bootcount-devices are present) the
/chosen/u-boot,bootcount-device property can be used to select one
bootcount device.

Initially, this provides support for the following DM devices:
 * RTC devices
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>

Patch for rk322x TPL is not merged, and only SPL is available now,
enable the sdram driver in SPL first. We should update back to TPL
after TPL is enabled for rk322x.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

In case SYS_I2C or DM_I2C are defined, then the "i2c " prefix
of the "i2c crc32" command is missing.
This patch addresses this, so that users can't get confused
by the "crc32" command.

Without the patch we get

    => i2c help
    i2c - I2C sub-system

    Usage:
    i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
    crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
    i2c dev [dev] - show or set current I2C bus
    [...]

With the patch we get

    => i2c help
    i2c - I2C sub-system

    Usage:
    i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
    i2c crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
    i2c dev [dev] - show or set current I2C bus
    ...
Signed-off-by: NChristoph Muellner <christoph.muellner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

The DRA7 platforms requires that the dtb used in the SPL really matches the
platform  to have the best MMC performances.
To detect the board type/version an I2C EEPROM is read. This requires that
DM is initialized before the detection. As a consequence we must reset the
DM after the board detection is a new dtb would better match the platform.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

To reset the DM after a new dtb is loaded, we need to call dm_uninit()
and then dm_init(). This fails however because gd->dm_root is not nullified
by dm_uninit().
Fixing it by setting gd->dm_root in dm_uninit().
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>

It is currently not possible to include the support to remove devices in
the SPL. This is however needed by platforms that re-select their dtb after
DM is initialized; they need to remove all the previously bound devices
before triggering a scan of the new DT.

Add a Kconfig option to be able to include the support for device removal
in the SPL.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Seeries-changes:3
- update commit message
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

In some cases it may be useful to be able to change the fdt we have been
using and use another one instead. For example, the TI platforms uses an
EEPROM to store board information and, based on the type of board,
different dtbs are used by the SPL. When DM_I2C is used, a first dtb must
be used before the I2C is initialized and only then the final dtb can be
selected.
To speed up the process and reduce memory usage, introduce a new function
fdtdec_setup_best_match() that re-use the DTBs loaded in memory by
fdtdec_setup() to select the best match.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

This is required to take advantage of MULTI_DTB_FIT before relocation.
If it is too low, DM will be initialized only after relocation has
taken place. That is too late for the DRA7 because I2C DM is used before
the relocation to setup the voltages required, among other things, to
properly initialize the DRAM.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

am57xx configs uses DM_I2C both in SPL and u-boot.
Remove code for non-DM I2C support.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

DM_I2C_COMPAT is a compatibility layer that allows using the non-DM I2C
API when DM_I2C is used. The goal is to eventually remove DM_I2C_COMPAT
when all I2C "clients" have been migrated to use the DM API.
This a step in that direction for the TI based platforms.
Build tested with buildman:
buildman -dle am33xx ti omap3 omap4 omap5 davinci keystone

boot tested with:
am335x_evm, am335x_boneblack, am335x_boneblack_vboot (DM version),
am57xx_evm, dra7xx_evm, k2g_evm, am437x_evm
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Remove the last call to the non-DM I2C API.
Also remove the #undef CONFIG_DM_I2C_COMPAT because it is not defined
in the common header file anymore.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NFelix Brack <fb@ltec.ch>
Tested-by: NFelix Brack <fb@ltec.ch>
Reviewed-by: NHeiko Schocher <hs@denx.de>

The EEPROM reading in the board detection code is done through legacy
I2C functions which on platforms using DM_I2C this functionality is
provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms
to use the board detection code without relying on CONFIG_DM_I2C_COMPAT
go ahead and add an I2C handling implementation that directly uses the
I2C DM functionality.
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Those driver are not DM drivers per se (not using the PMIC/regulator
framework) and are using the legacy I2C API. Make them compatible with
the DM_I2C API.

This impacts the following drivers:
- palmas (used by am57xx/dra7xx evms)
- tps65218 (used by am43xx evms)
- tps65217 and tps65910 (used by am335x evms and am335x boneblack vboot)
- twl4030 (used by omap3_logicpd)
- tps65217 (used by brppt1)
- twl6030
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

In order to use DM_I2C, we need to move the board detection after the
early SPL initialization.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

If DM_I2C is used , the I2C controllers must be registered as U_BOOT_DEVICE
because OF_CONTROL is not used in the SPL.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

This allows the driver to be used without OF_CONTROL.
AM335x support DM_SPL but does not use SPL_OF_CONTROL. Enabling DM_I2C in
SPL thus requires that the omap I2C can be passed platdata.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Move away from SoC specific headers to handle different register layout.
Instead use driver data to get appropriate register layouts like in the
kernel. While at it, perform some mostly cosmetic alignment/cleanup in
the functions being updated.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Those platforms need CONFIG_SPL_DM_SEQ_ALIAS because they enable both
DM_I2C and SPL_DM. Without CONFIG_SPL_DM_SEQ_ALIAS, it is not possible to
get the I2C bus with i2c_get_chip_for_busnum().
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NFelix Brack <fb@ltec.ch>
Tested-by: NFelix Brack <fb@ltec.ch>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

If OF_CONTROL is not enabled and DM_SEQ_ALIAS is enabled, we must
assign an alias (requested sequence number) to devices that belongs to a
class with the DM_UC_FLAG_SEQ_ALIAS flag. Otherwise
uclass_find_device_by_seq() cannot be used to get/probe a device. In
particular i2c_get_chip_for_busnum() cannot be used.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>

i2c_get_chip_for_busnum() really should check the presence of the chip on
the bus. Most of the users of this function assume that this is done.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

The implementation of the EEPROM commands does not support the DM I2C API.
Prevent compilation breakage by not enabling it if the non-DM API is not
available (if DM_I2C is used without DM_I2C_COMPAT)
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Up until now the call to initialize the USB subsystem was hardcoded
for U-Boot running as an EFI payload. This was used to enable the
use of a USB keyboard in the U-Boot shell. However not all boards
might need this functionality. As initializing the USB subsystem can
take a considerable amount of time (several seconds on some boards),
we now initialize the USB subsystem only if U-Boot is configured to
use USB keyboards.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>

Up until now the call to initialize the USB subsystem was hardcoded
for U-Boot running as a coreboot payload. This was used to enable
the use of a USB keyboard in the U-Boot shell. However not all boards
might need this functionality. As initializing the USB subsystem can
take a considerable amount of time (several seconds on some boards),
we now initialize the USB subsystem only if U-Boot is configured to
use USB keyboards.
Signed-off-by: NThomas RIENOESSL <thomas.rienoessl@bachmann.info>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>