Add get_pin_name ops to obtain a pin name given a
pin index of a specified pin-controller.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add get_pins_count ops to obtain the number of pins
owns by a pin-controller.
On STM32 SoCs bindings, each pin-controller owns
several gpio banks. Each GPIO bank can own up to 16 pins.

To obtain the total pins count, walk through each sub-nodes
(ie GPIO banks) and sum each GPIO banks pins number. For that
in probe() we build a list with each GPIO device reference found.
This list will also be used with future get_pin_muxing and get_pin_name
ops to speed up and optimize walk through all GPIO banks.

As this code is common to all STM32 SoCs, this code is put
under SPL_BUILD compilation flag to avoid to increase SPL code size
for STM32F7 which is limited to 32Ko.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

pinmux command allows to :
 - list all pin-controllers available on platforms
 - select a pin-controller
 - display the muxing of all pins of the current pin-controller
   or all pin-controllers depending of given options
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
cmd: pinmux: Fix pinmux command

if "pinmux status" command is used without having
set dev using "pinmux dev", print pinmux usage
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add uclass_foreach_dev_probe() which iterates through
devices of a given uclass. Devices are probed if necessary
and are ready to use.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Similarly to uclass_first_device_err(), add uclass_next_device_err()
which returns an error if there are no next devices in that uclass.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods
to obtain pin's name and pin's muxing given a pin reference.

This will be used by the new pinmux command.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add get_pin_muxing() which allows to display the muxing
of a given pin belonging to a pin-controller.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Signed-off-by: NMartin Fuzzey <martin.fuzzey@flowbird.group>

README.omap3 has two options.  For option 1, CONFIG_SYS_TEXT_BASE
is set to 0x80100000.  Option 2 lists 0x80008000.  The existing
value is neither of these, so this patch makes it equivalent to
Option 1.
Signed-off-by: NAdam Ford <aford173@gmail.com>

In an effort to free up more resources in SPL and U-Boot, building
for Thumb shrinks the code side.

Before:

  text	   data	    bss	    dec	    hex	filename
  685588  25808	 275724	 987120	  f0ff0	u-boot

  text	   data	    bss	    dec	    hex	filename
  55324	    417	  67460	 123201	  1e141	spl/u-boot-spl

After:

   text	   data	    bss	    dec	    hex	filename
 515502	  25808	 275708	 817018	  c777a	u-boot

   text	   data	    bss	    dec	    hex	filename
  42910	    417	  67460	 110787	  1b0c3	spl/u-boot-spl
Signed-off-by: NAdam Ford <aford173@gmail.com>

The AM3517 is mostly am omap3, so this partch removes the custom
memory configurations and just uses the default common entries
for omap3 and armv7.
Signed-off-by: NAdam Ford <aford173@gmail.com>

Some minor changes have been made to the AM3517-evm and the underlying
am3517.dtsi files.  This patch re-sync's the DTS and DTSI files with
Linux.
Signed-off-by: NAdam Ford <aford173@gmail.com>

Testing and analysis shows that at the moment LPC32xx NAND SLC driver
can not get PL080 DMA backbone support in SPL build, because SPL NAND
loaders operate with subpage (ECC step to be precisely) reads, and
this is not supported in the NAND SLC + DMA + hardware ECC calculation
bundle.

The change removes a cautious build time warning and explicitly
disables DMA flavour of the driver for SPL builds, to reduce the
amound of #ifdef sections the code blocks are minimally reorganized.
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>

Build option CONFIG_SYS_MAX_NAND_CHIPS is used by NXP LPC32xx NAND MLC
driver only, as a preparation for potential removal or replacement of
the option the change predefines CONFIG_SYS_MAX_NAND_CHIPS to 1, same
value is used by the single user Work Microwave Work 92105 board, thus
it will be safe now to remove the option as a board specific one.
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>

The pca953x_gpio driver uses default value of polarity inversion
register. For some devices like PCA9557 and MAX7310, their polarity
inversion register default value is 0xf0. So for high 4 ports, when
reading their values, the values are inverted as the actual level.

This patch clears the polarity inversion register to 0 at init, so
that the port read and write values are aligned.
Signed-off-by: NYe Li <ye.li@nxp.com>
Acked-by: NFugang Duan <fugang.duan@nxp.com>
Acked-by: NPeng Fan <peng.fan@nxp.com>
Signed-off-by: NAnatolij Gustschin <agust@denx.de>

The earlier commit f4fcba5c ("clk: implement clk_set_defaults()")
which introduced the functionality for setting clock defaults such as
rates and parents will skip the processing when executing in a re-reloc
state. This for example can prevent the assigning of clock parents
when running in SPL code. Go ahead and remove this limitation.
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

This add the initial support of the broadcom reference
board bcm968580xref with a bcm6858 SoC.

This board has 512 MB of ram, 256 MB of flash (nand),
2 usb port, 1 uart, 4 ethernet ports (LAN), 1 ethernet port (WAN).
Signed-off-by: NPhilippe Reynes <philippe.reynes@softathome.com>

This add the initial support of the broadcom bcm6858 SoC family,
only the cpu, dram and uart are supported.
Signed-off-by: NPhilippe Reynes <philippe.reynes@softathome.com>

This driver add the support of serial on bcm6858.
It's based on serial for bcm6345.
Signed-off-by: NPhilippe Reynes <philippe.reynes@softathome.com>

Display all digits on 64bit systems. Currently we print only the lower
32 bits. Examples of values that can exceed 32 bits are the size and start of
memory banks.

For fdt_blob use the same output method as for other values. This avoids
misalignment.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Convert the Watchdog driver for AT91SAM9x processors to support
the driver model and device tree. Changes "CONFIG_AT91SAM9_WATCHDOG"
to new "CONFIG_WDT_AT91" Kconfig option.
Signed-off-by: NPrasanthi Chellakumar <prasanthi.chellakumar@microchip.com>

Allow platform vendors to handle SError interrupt exceptions from
ARMv8 PSCI exception vectors by overriding this weak function
'plat_error_handler'.
Signed-off-by: NChee Hong Ang <chee.hong.ang@intel.com>

Kconfig option to allow all External Abort and SError exception
taken to EL3.
Signed-off-by: NChee Hong Ang <chee.hong.ang@intel.com>

Allow EL3 to handle all the External Abort and SError interrupt
exception occur in all exception levels.
Signed-off-by: NChee Hong Ang <chee.hong.ang@intel.com>

The clearfog, corvus, wb45n and picosam9g45 configs are close to
exceeding their size limits, so enable THUMB2 builds on them to reclaim
space.
Signed-off-by: NTom Rini <trini@konsulko.com>

- virtio implementation and supporting patches
- DM_FLAG_PRE_RELOC fixes
- regmap improvements
- minor buildman and sandbox things

The latest version of pytest (4.0.0) makes some of the code we have in
test/py/conftest.py a fatal error that needs to be migrated.
Unfortunately this in turn requires changes that don't exist in older
versions of pytest such as 2.8.7 that ships with Ubuntu 16.04.  Force
travis to use this older version of pytest.
Signed-off-by: NTom Rini <trini@konsulko.com>

This reverts commit c5bbfaf0.

Disabling CONFIG_DISPLAY_CPUINFO was a temporary solution to get
the v2018.11 release out. Now the merge window opens, revert it.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

To support CONFIG_DISPLAY_CPUINFO, add "u-boot,dm-pre-reloc" for
all cpu nodes in Sandbox test.dts.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NStefan Roese <sr@denx.de>

It turns out commit c0434407 broke some boards which have DM CPU
driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail
to boot when print_cpuinfo() is called during boot.

Fixes: c0434407 ("board_f: Use static print_cpuinfo if CONFIG_CPU is active")
Reported-by: NStefan Roese <sr@denx.de>
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NStefan Roese <sr@denx.de>
Tested-by: NStefan Roese <sr@denx.de>

Add some description about pre-relocation driver binding, including
usage of DM_FLAG_PRE_RELOC flag and caveats.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>