The AXP209 LDO3 regulator supports voltage rate control, or can set a
slew rate.

This allows for the power to gradually rise up to the desired voltage,
instead of spiking up as fast as possible. Reason to have this can be
to reduce the inrush currents for example.

There are 3 slopes to choose from, the default, 'none' is a voltage rise
of 0.0167 V/uS, a 1.6 mV/uS and a 0.8 mV/uS voltage rise.

In ideal world (where vendors follow the recommended design guidelines)
this setting should not be enabled by default. Unless of course AXP209
crashes instead of reporting overcurrent condition as it normally should
do in this case.
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NPriit Laes <plaes@plaes.org>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>

The AXP209 has a few 'magisc-ish' values that are better served with
clear defines.
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NPriit Laes <plaes@plaes.org>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>

Use a define for the chip version mask on the axp209.
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NPriit Laes <plaes@plaes.org>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>

Use the standard BIT() macro for bitfield definitions in headers.
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NPriit Laes <plaes@plaes.org>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>

When we clear a pmic_bus bit, we do a read-modify-write operation.
We waste some time however, by writing back the exact samea value
that was already set in the chip. Let us thus only do the write
in case data was changed.
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NPriit Laes <plaes@plaes.org>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>

Currently during init, we enable all power, then enable the dram and
after that check whether there was an error during power-up.

This makes little sense, we should enable power and then check if power
was brought up properly before we continue to initialize other things.

This patch moves the DRAM init after the power failure check.
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NPriit Laes <plaes@plaes.org>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>

Add an entry for the Ficus EE board to the existing rock960 MAINTAINERS
file.
Signed-off-by: NTom Rini <trini@konsulko.com>

- Changes the declaration of regs_phy in dwc2-otg to uintptr_t
  to ensure it can be cast to void* for use with writel().
- Add the Rock960 and Ficus boards.

Add board support for Ficus EE board from Vamrs. This board utilizes
common Rock960 family support.

Following peripherals are tested and known to work:
* Gigabit Ethernet
* USB 2.0
* MMC
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
[Reworked based on common Rock960 family support]
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Add board support for Rock960 CE board from Vamrs. This board utilizes
common Rock960 family support.

Following peripherals are tested and known to work:
* USB 2.0
* MMC

This commit also adds DDR configuration for LPDDR3-2GiB-1600MHz which
is being used on the board.
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPeter Robinson <pbrobinson@gmail.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Rock960 is a family of boards based on Rockchip RK3399 SoC from Vamrs.
It consists of Rock960 (Consumer Edition) and Ficus (Enterprise Edition)
96Boards.

Below are some of the key differences between both Rock960 and Ficus
boards:

1. Different host enable GPIO for USB
2. Different power and reset GPIO for PCI-E
3. No Ethernet port on Rock960

The common board support will be utilized by both boards. The device
tree has been organized in such a way that only the properties which
differ between both boards are placed in the board specific dts and
the reset of the nodes are placed in common dtsi file.
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[Added instructions for SD card boot]
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPeter Robinson <pbrobinson@gmail.com>

Those pins would be used by many boards.

Commit grabbed from Linux:

commit b41023282d07b61a53e2c9b9508912b1e7ce7b4f
Author: Randy Li <ayaka@soulik.info>
Date:   Thu Jun 21 21:32:10 2018 +0800

    arm64: dts: rockchip: add some common pin-settings to rk3399

    Those pins would be used by many boards.
Signed-off-by: NRandy Li <ayaka@soulik.info>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: NRandy Li <ayaka@soulik.info>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Tested-by: NPeter Robinson <pbrobinson@gmail.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

The regs_phy field of the platform data structure for dwc2-otg is
today declared an unsigned int, but will eventually be cast into a
void* for a writel operation.  This triggers errors on modern GCC
versions.

E.g. we get the following error with GCC 6.3:
  drivers/usb/phy/rockchip_usb2_phy.c: In function 'property_enable':
  arch/arm/include/asm/io.h:49:29: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   #define __arch_putl(v,a)  (*(volatile unsigned int *)(a) = (v))
                               ^
  arch/arm/include/asm/io.h:117:48: note: in expansion of macro '__arch_putl'
   #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
                                                  ^~~~~~~~~~~
  drivers/usb/phy/rockchip_usb2_phy.c:61:2: note: in expansion of macro 'writel'
    writel(val, pdata->regs_phy + reg->offset);
    ^~~~~~

This commit changes regs_phy to be a uintptr_t to ensure that it is
large enough to hold any valid pointer (and fix the associated
warning).
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Minor sandbox enhancements  / fixes
tpm improvements to clear up v1/v2 support
buildman toolchain fixes
New serial options to set/get config

- Various MTD fixes from Boris
- Zap various unused / legacy paths.
- pxa3xx NAND update from Miquel
Signed-off-by: NTom Rini <trini@konsulko.com>

SPI flash based MTD devs can be registered/unregistered at any time
through the sf probe command or the spi_flash_free() function.

This commit does not try to fix the root cause as it would probably
require rewriting most of the code and have an mtd_info object
instance per spi_flash object (not to mention that the the spi-flash
layer is likely to be replaced by a spi-nor layer ported from Linux).

Instead, we try to be as safe as can be by checking the code returned
by del_mtd_device() and complain loudly when there's nothing we can
do about the deregistration failure. When that happens we also reset
sf_mtd_info.priv to NULL, and check for NULL pointer in the mtd hooks
so that -ENODEV is returned instead of hitting a NULL pointer
dereference exception when the MTD instance is later accessed by a user.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

The DM implementation of spi_flash_free() does not unregister the MTD
device before removing the spi dev object. This leads to a use-after-free
bug when the MTD device is later accessed by a MTD user (observed when
attaching the device to UBI after env_sf_load() has called
spi_flash_free()).

Implement ->remove() and call spi_flash_mtd_unregister() from there.

Fixes: 9fe6d871 ("mtd, spi: Add MTD layer driver")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>
Reviewed-by: NJagan Teki <jagan@openedev.com>

MTD partition creation code is a bit tricky. It tries to figure out
when things have changed (either MTD dev list or mtdparts/mtdids vars)
and when that happens it first deletes all the partitions that had been
previously created and then creates the new ones based on the new
mtdparts/mtdids values.
But before deleting the old partitions, it ensures that none of the
currently registered parts are being used and bails out when that's
not the case. So, we end up in a situation where, if at least one MTD
dev has one of its partitions used by someone (UBI for instance), the
partitions update logic no longer works for other devs.

Rework the code to relax the logic and allow updates of MTD parts on
devices that are not being used (we still refuse to updates parts on
devices who have at least one of their partitions used by someone).

Fixes: 5db66b3a ("cmd: mtd: add 'mtd' command")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

The mtdparts variable might contain partition definitions for several
MTD devices. Each partition layout is separated by a ';', so let's
make sure we don't pick a wrong name when mtdparts is malformed.

Fixes: 5db66b3a ("cmd: mtd: add 'mtd' command")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

The local mtd_name[] variable is limited in size. Return an error if
the name passed in mtdparts does not fit in this local var.

Fixes: 5db66b3a ("cmd: mtd: add 'mtd' command")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

strstr() does not guarantee that the string we're searching for is
placed at the beginning. Use strncmp() instead.

Fixes: 5db66b3a ("cmd: mtd: add 'mtd' command")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

The environment is not guaranteed to contain a valid mtdids variable
when called from mtd_search_alternate_name(). Call get_mtdids() instead
of env_get("mtdids").

Fixes: ff4afa8a ("mtd: uboot: search for an equivalent MTD name with the mtdids")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

spi_flash_mtd_register() can be called several times and each time it
will register the same mtd_info instance like if it was a new one.
The MTD ID allocation gets crazy when that happens, so let's track the
status of the sf_mtd_info object to avoid that.

Fixes: 9fe6d871 ("mtd, spi: Add MTD layer driver")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>
Reviewed-by: NJagan Teki <jagan@openedev.com>

If we don't do that, partitions might still be exposed while the
underlying device is gone.

Fixes: 2a74930d ("mtd: mtdpart: implement proper partition handling")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

Updates to the MTD device list should trigger a new parsing of the
mtdids/mtdparts vars even if those vars haven't changed.

Fixes: 5db66b3a ("cmd: mtd: add 'mtd' command")
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

We need to parse mtdparts/mtids again everytime a device has been
added/removed from the MTD list, but there's currently no way to know
when such an update has been done.

Add an ->updated field to the idr struct that we set to true every time
a device is added/removed and expose a function returning the value
of this field and resetting it to false.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Tested-by: NHeiko Schocher <hs@denx.de>

Microsoft specifies a SPCR (Serial Port Console Redirection Table) [1].
Let's provide it in U-Boot.

[1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-tableSigned-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add SPCR table description as it provided in Linux kernel.

Port subtype for ACPI_DBG2_SERIAL_PORT is used as an interface type in SPCR.
Thus, provide a set of definitions to be utilized later.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

New callback will supply necessary information, for example,
to ACPI SPCR table.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

- Fix BBL may be corrupted problem.
- Support U-Boot run in S-mode.

video, bmp and cls command updates

Cache the value of the reg-io-width property for the future use.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Group reg_* members of struct ns16550_platdata together for better maintenance.

No functional change intended.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

New callback will give a necessary information to fill up ACPI SPCR table,
for example. Maybe used later for other purposes.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Change ADR_SPACE_SYSTEM_IO to SERIAL_ADDRESS_SPACE_IO to fix build error:
Signed-off-by: NSimon Glass <sjg@chromium.org>

In some cases it would be good to know the settings, such as parity,
of current serial console. One example might be an ACPI SPCR table
to generate using these parameters.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Don't disable regulator which are tagged as "regulator-always-on" in DT.
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NJack Mitchell <jack@embed.me.uk>
Tested-by: NJack Mitchell <jack@embed.me.uk>
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NRichard Röjfors <richard@puffinpack.se>
Tested-by: NRichard Röjfors <richard@puffinpack.se>
Reviewed-by: NFelix Brack <fb@ltec.ch>
Tested-by: NFelix Brack <fb@ltec.ch>

This functions allow us to get and remap I/O addresses by name, which is useful when there are multiple reg addresses indexed by reg-names property.
This is needed in bmips dma/eth patch series, but can also be used on many
other drivers.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add an entry for my maintainership of this tool.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The comment in uclass-id.h states that
    "U-Boot uclasses start here - in alphabetical order"
but the subsequent list is not sorted alphabetically.
This reestablishes order.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

The documentation comment for dm_rtc_set was referring to dm_rtc_put
instead. Fix it.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>