arm: dts: include gpio nodes for card detect

Several MMC drivers use GPIO for card detection with cd-gpios property in
the MMC node pointing to a GPIO node. However, as U-Boot tries to save
space by keeping only required nodes using u-boot* properties, several
devices tree result in having only in the MMC node but not the GPIO node
associated to cd-gpios.

This patch, fixes several ocurrence of this issue.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm

dm: doc: update of-plat with new phandle support

Update documentation to reflect the new phandle support when OF_PLATDATA
is used. Now phandles are implemented as pointers to U_BOOT_DEVICE,
which makes it possible to get a pointer to the actual device.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dtoc: extend dtoc to use struct driver_info when linking nodes

In the current implementation, when dtoc parses a dtb to generate a struct
platdata it converts the information related to linked nodes as pointers
to struct platdata of destination nodes. By doing this, it makes
difficult to get pointer to udevices created based on these
information.

This patch extends dtoc to use struct driver_info when populating
information about linked nodes, which makes it easier to later get
the devices created. In this context, reimplement functions like
clk_get_by_index_platdata() which made use of the previous approach.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: Move section u_boot_list to make it RW

In order to be able to update data in u_boot_list, move this section to
make it RW.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

core: extend struct driver_info to point to device

Currently when creating an U_BOOT_DEVICE entry a struct driver_info
is declared, which contains the data needed to instantiate the device.
However, the actual device is created at runtime and there is no proper
way to get the device based on its struct driver_info.

This patch extends struct driver_info adding a pointer to udevice which
is populated during the bind process, allowing to generate a set of
functions to get the device based on its struct driver_info.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

core: drop const for struct driver_info

In order to prepare for a new support of phandle when OF_PLATDATA is used
drop the const for struct driver_info as this struct will need to be
updated on runtime.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: doc: update of-plat with the support for driver aliases

Update the documentation with the support for driver aliases using
U_BOOT_DRIVER_ALIAS.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dtoc: add option to disable warnings

As dtoc now performs checks for valid driver names, when running dtoc
tests several warnings arise as these tests don't use valid driver
names.

This patch adds an option to disable those warning, which is only
intended for running tests.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dtoc: add support to scan drivers

Currently dtoc scans dtbs to convert them to struct platdata and
to generate U_BOOT_DEVICE entries. These entries need to be filled
with the driver name, but at this moment the information used is the
compatible name present in the dtb. This causes that only nodes with
a compatible name that matches a driver name generate a working
entry.

In order to improve this behaviour, this patch adds to dtoc the
capability of scan drivers source code to generate a list of valid driver
names and aliases. This allows to generate U_BOOT_DEVICE entries using
valid driver names and rise a warning in the case a name is not valid.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Open files in utf-8 mode:
Signed-off-by: Simon Glass <sjg@chromium.org>

core: add support for U_BOOT_DRIVER_ALIAS

Currently when using OF_PLATDATA the binding between devices and drivers
is done trying to match the compatible string in the node with a driver
name. However, usually a single driver supports multiple compatible strings
which causes that only devices which its compatible string matches a
driver name get bound.

To overcome this issue, this patch adds the U_BOOT_DRIVER_ALIAS macro,
which generates no code at all, but allows an easy way to declare driver
name aliases. Thanks to this, dtoc could be improve to look for the driver
name based on its alias when it populates the U_BOOT_DEVICE entry.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dtoc: add missing code comments

Add missing information about internal class members in order to make
the code easier to follow.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

drivers: rename drivers to match compatible string

When using OF_PLATDATA, the bind process between devices and drivers
is performed trying to match compatible string with driver names.
However driver names are not strictly defined, and also there are different
names used when declaring a driver with U_BOOT_DRIVER, the name of the
symbol used in the linker list and the used in the struct driver_info.

In order to make things a bit more clear, rename the drivers names. This
will also help for further OF_PLATDATA improvements, such as checking
for valid driver names.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a fix for sandbox of-platdata to avoid using an invalid ANSI colour:
Signed-off-by: Simon Glass <sjg@chromium.org>

test/dm: fdtdec: Add tests for fdtdec_add_reserved_memory()

This adds a test case to test the functionality of the fdtdec API
fdtdec_add_reserved_memory().

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test/dm: fdtdec: Corect a typo in dm_test_fdtdec_set_carveout()

It should be "writable".

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test/dm: fdtdec: Add the missing gd declaration

Add DECLARE_GLOBAL_DATA_PTR since it is referenced in the test codes.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fdt: remove CMD_FDT_MAX_DUMP

When printing the device tree we want to get an output that can be used as
input for the device tree compiler. This requires that we do not write
bogus lines like

    pcie@10000000 {
            interrupt-map = * 0x4000127c [0x00000280];

For instance the QEMU virt device has a property interrupt-map with 640
bytes which exceeds CMD_FDT_MAX_DUMP=64.

So lets do away with the artificial limitation to 64 bytes.

As indicated in commit f0a29d43313c ("fdt: Limit printed hex in fdt print
and list commands") if a device tree contains binary blobs, it may still
be desirable to limit the output length. Provide environment variable
fdt_max_dump for this purpose.

Fixes: 5d927b428622 ("Kconfig: Drop CONFIG_CMD_FDT_MAX_DUMP")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

log: use BIT() instead of 1 <<

Use the BIT() macro when creating a bitmask for the logging fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

log: don't show function by default

The name of the function emitting a log message may be of interest for a
developer but is distracting for normal users. See the example below:

    try_load_entry() Booting: Debian

Make the default format for log messages customizable. By default show
only the message text.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

checkpatch: Don't warn about PREFER_IF in headers/DT files

This warning should only be displayed for C files. Fix it and update the
test.

Signed-off-by: Simon Glass <sjg@chromium.org>

patman: Add tests for the rest of the checkpatch checks

Finish off the tests for our small collection of checkpatch checks.

Signed-off-by: Simon Glass <sjg@chromium.org>

patman: Decode output from the '--show-types' option

Collect the 'checkpatch type' from each error, warning and check. Provide
this to patman and update the uclass test to use it.

Signed-off-by: Simon Glass <sjg@chromium.org>

patman: Add a test for the 'possible new uclass' check

It is quite likely that the number of U-Boot-specific tests in
checkpatch.pl will increase over time. We should have tests for these to
avoid undefined behaviour and bugs being introduced, which might cause
people to ignore the warnings.

Add a simple new class that can generate a patch with a single-line
addition in it. Use that to add a test for one of the checkpatch checks.

Signed-off-by: Simon Glass <sjg@chromium.org>

patman: Rename test.py to test_checkpatch.py

These tests check checkpatch.pl operation and can server as our tests for
the U-Boot-specific updates to that script. Rename the file and update
comments to indicate this.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Correct comment on uclass_id_foreach_dev()

This parameter should be a struct uclass, not struct udevice. Correct it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-By: Michael Trimarchi <michael@amarulasolutions.com>

log: uclass_get_name() depends on CONFIG_SPL_DM

If CONFIG_SPL_DM=n and CONFIG_SPL_LOG=y a build error occurs:

ld.bfd: common/built-in.o: in function `log_get_cat_name':
common/log.c:48: undefined reference to `uclass_get_name'
make[1]: *** [scripts/Makefile.spl:422: spl/u-boot-spl] Error 1

Call uclass_get_name() only if DM is enabled.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: make RAM size configurable

Up to now the RAM size of the sandbox is hard coded as 128 MiB. This does
not allow testing the correct handling of addresses outside the 32bit
range. 128 MiB is also rather small when tracing functions where the trace
is written to RAM.

Provide configuration variable CONFIG_SANDBOX_RAM_SIZE_MB to set the RAM
size in MiB. It defaults to 128 MiB with a minimum of 64 MiB.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

patman: Drop import of test_util in test_util

This module doesn't need to import itself. It causes problems on
very old Python 3 (e.g. 3.4.0). Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

patman: Avoid importing gitutil in settings

Pass this module in so that settings does not need to import it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Stefan Bosch <stefan_b@posteo.net>

patman: Pass in maintainer dirs to avoid and import

Adjust the get_maintainer module to accept a list of directories to search
for the script. This avoids needing to import gitutil.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Stefan Bosch <stefan_b@posteo.net>

patman: Use a dict in gitutil to avoid importing series

Only a few members of this class are used and only in a test. To avoid
importing the module, convert the test to use a dict.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Stefan Bosch <stefan_b@posteo.net>

patman: Avoid circular dependency between command and tools

This seems to cause problems in some cases. Split the dependency by
copying the code to command.

Reported-by: Stefan Bosch <stefan_b@posteo.net>
Signed-off-by: Simon Glass <sjg@chromium.org>

patman: Drop unnecessary import in gitutil

The checkpatch module is not used, so drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Stefan Bosch <stefan_b@posteo.net>

sandbox: spi: sandbox_sf_state_name() is required

Compiling drivers/mtd/spi/sandbox.c fails when compiled with
CONFIG_LOG=n:

In file included from include/common.h:20,
                 from drivers/mtd/spi/sandbox.c:13:
drivers/mtd/spi/sandbox.c:295:15: error: format ‘%s’ expects argument of
type ‘char *’, but argument 7 has type ‘int’ [-Werror=format=]
  295 |   log_content(" cmd: transition to %s state\n",
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’
   37 | #define pr_fmt(fmt) fmt
      |                     ^~~
include/log.h:128:30: note: in expansion of macro ‘log_nop’
  128 | #define log_content(_fmt...) log_nop(LOG_CATEGORY, \
      |                              ^~~~~~~
drivers/mtd/spi/sandbox.c:295:3: note: in expansion of macro
‘log_content’
  295 |   log_content(" cmd: transition to %s state\n",
      |   ^~~~~~~~~~~
drivers/mtd/spi/sandbox.c:295:37: note: format string is defined here
  295 |   log_content(" cmd: transition to %s state\n",
      |                                    ~^
      |                                     |
      |                                     char *
      |                                    %d

Supply function sandbox_sf_state_name() independent of CONFIG_LOG.

Fixes: c3aed5db591e ("sandbox: spi: Add more logging")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: handling out of memory

assert() only works in debug mode. So checking a successful memory
allocation should not use assert().

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86

- Add two- and three-argument versions of CONFIG_IS_ENABLED in
  linux/kconfig.h
- Adds a new feature which supports copying modified parts of
  the frame buffer to the uncached hardware buffer
- Enable the copy framebuffer on various x86 targets

Merge tag 'for-v2020.10' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c

i2c changes for v2020.10
- Add support for I2C controllers found on Octeon II/III and Octeon TX
  TX2 SoC platforms.
- Add I2C controller support for Cortina Access CAxxxx SoCs
- new rtc methods, rtc command, and tests
- imx_lpi2c: Improve the codes to use private data
- stm32f7_i2c.c: Add new compatible "st,stm32mp15-i2c"
- stm32f7_i2c.c: Add Fast Mode Plus support
- pwm: Add PWM driver for SiFive SoC

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell

- Armada 38x DDR3 fixes, enhancements (Chris)
- Armada 38x UTMI PHY SerDes fix (Chris)
- Helios4 update - sync with clearfog (Dennis)
- LaCie Kirkwood board rework - enable DM (Simon)
- net/mvpp2 memory init fix (Sven)

net: mvpp2: fix second cp110 initialization

Since the mdio code got upstreamed it is not possible
to activate network ports on CP110 Master and Slave.

The problem is in mvpp2_base_probe which is called for each
CP110 and it initializes the buffer area for descs and rx_buffers.

This should only happen once though and the bd space is actually
set to 0 after the first run of the function.

This leads to an error when the second CP110 tries the initialization
again and disables all network ports on this CP110.

This patch adds a static variable to check if the buffer area is
initialized only once globally.

Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: kirkwood: enable DM_ETH for LaCie board

This patch enables DM_ETH for the following Kirkwood-based LaCie boards:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: kirkwood: enable DM_USB for LaCie board

This patch enables DM_USB and USB_STORAGE for the following
Kirkwood-based LaCie boards:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: kirkwood: switch LaCie boards to sata_mv driver

This patch switches the SATA driver from mvsata_ide to sata_mv for the
following Kirkwood-based LaCie boards:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: kirkwood: convert LaCie boards to DM_SPI_FLASH

This patch converts the following Kirkwood-based LaCie boards to DM,
DM_SPI and DM_SPI_FLASH:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>

arm: kirkwood: add DT spi0 alias to LaCie boards

The spi0 alias is needed by the environment code to retrieve the SPI
flash. This patch adds some -u-boot.dtsi files, providing the spi0
aliases, for all the following Kirkwood-based LaCie boards:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2

Note that this -u-boot.dtsi files will be removed as soon as the spi0
aliases will be available in the upstream Linux dtsi files.

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>

arm: mvebu: helios4: sync helios4 config to clearfog and dts to kernel

The helios4 is built on the same microsom as the clearfog, by syncing the config
we enable the same featureset that exists in the som on the helios4. The current
config does not boot as some of the clearfog changes needed to be made on the
helios4 also, generally speaking most changes for the clearfog should also be
made on the helios4.

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: a38x: Adjust UTMI PHY parameters

When running USB compliance tests on our Armada-385 hardware platforms
we have seen some eye mask violations. Marvell's internal documentation
says: Based on silicon test results, it is recommended to change the
impedance calibration threshold setting to 0x6 prior to calibration.

Port changes from Marvell's u-boot fork[1] to address this.

[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/a6221551

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: a38x: Fix typo

Fix spelling of Alignment.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

mv_ddr: ddr3: Update {min,max}_read_sample calculation

Measurements on actual hardware shown that the read ODT is early by 3
clocks. Adjust the calculation to avoid this.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Stefan Roese <sr@denx.de>

mv_ddr: ddr3: Use correct bitmask for read sample delay

In the Armada 385 functional spec (MV-S109094-00 Rev. C) the read sample
delay fields are 5 bits wide. Use the correct bitmask of 0x1f when
extracting the value.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

x86: apl: Re-enable loading of SPL

At present the SPL loader is not included in the TPL image so SPL cannot
be loaded. Fix it by including this file for both SPL and TPL.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: c87f9ce2273 ("x86: Don't build some unused objects in TPL")
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

spi: Remove unnecessary #ifdefs in header file

These prevent use of compile-time checks such as:

    if (CONFIG_IS_ENABLED(DM_SPI))

since, for example, if CONFIG_SPL_DM_SPI is not enabled then the
definitions are not included by spi.h and the C code will not build.

The #ifdefs are unnecessary since there are no conflicts with the pre-DM
code. In any case we have almost switched over to driver model for SPI.

Drop these #ifdefs from spi.h to fix a build warning on chromebook_coral
in the following patch.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

bootstage: Fix 'stacked' typo

This should be 'stashed'. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

linux/kconfig.h: create two- and three-argument versions of CONFIG_IS_ENABLED

This adds a bunch of preprocessor magic to extend the capabilities of
CONFIG_IS_ENABLED. The existing semantics of

  CONFIG_IS_ENABLED(FOO)

expanding to a 1 or 0 (depending on build context and the defined-ness
or not of the appropriate CONFIG_FOO/CONFIG_SPL_FOO/CONFIG_TPL_FOO)
are of course preserved. With this, one is also allowed a two-argument
form

  CONFIG_IS_ENABLED(FOO, (something))

which expands to something precisely when CONFIG_IS_ENABLED(FOO) would
expand to 1, and expands to nothing otherwise. It is, in other words,
completely equivalent to the three lines

  #if CONFIG_IS_ENABLED(FOO)
  something
  #endif

The second argument must be parenthesized in order to allow any
tokens, including a trailing comma, to appear - one use case for this
is precisely to make it a bit more ergonomic to build an array and
only include certain items depending on .config. That should increase
both readability and not least "git grep"ability.

A third variant is also introduced,

  CONFIG_IS_ENABLED(FOO, (xxx), (yyy))

which corresponds to

  #if CONFIG_IS_ENABLED(FOO)
  xxx
  #else
  yyy
  #endif

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

linux/kconfig.h: remove unused helper macros

U-Boot does not have loadable modules, and nothing currently uses any
of the (CONFIG_)?IS_(BUILTIN|MODULE) macros - only
the (CONFIG_)?IS_ENABLED variants are ever used.

While I understand the desire to keep this somewhat synchronized with
linux, we've already departed by the introduction of the
CONFIG_IS_ENABLED extra logic, and deleting these makes the next patch
much simpler, since I won't have to duplicate a lot of logic for no
real gain (as there are no users).

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

linux/kconfig.h: simplify logic for choosing CONFIG_{SPL_, TPL_, }*

Instead of using the arg1_or_junk trick to pick between two choices,
with a bit of duplication between the branches (and most of the
CONFIG_TPL_BUILD case being redundant, as _IS_TPL is known to be
defined to 1 in that case), simply define a prefix that we inject
between CONFIG_ and the given config symbol.

This only requires one level of indirection (to get the
_CONFIG_PREFIX macro expanded before the token concatenation takes
place), and makes it easy to, say, introduce a CONFIG_HOSTTOOL_
prefix. [I would expect most HOSTTOOL_ symbols to just be def_bool y,
but it would allow us to clean up some of the ifdef HOSTCC mess in the
sources shared between U-Boot and host tools.]

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

arm: cmd_stm32prog: Fix the CONFIG_IS_ENABLED() usage

Add parentheses around CONFIG_IS_ENABLED() in the if statement, to
fix potential build failures.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

x86: minnowmax: Drop screen resolution to 1024x768

This seems like a more reasonable resolution for this board, since it is
quite slow. It also allows it to work with a 5" LCD display in my lab.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

minnowmax: Enable the copy framebuffer

Update the video driver to support this feature and enable it on
minnowmax to speed up the display.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from over 13 seconds to
300ms, at 1280x1024.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

chromebook_link: Enable the copy framebuffer

Update the video driver to support this feature and enable it on link.
Also remove the multi-line scrolling since normal scrolling is fast enough
now.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 930ms to 29ms.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

chromebook_samus: Enable the copy framebuffer

Update the video driver to support this feature and enable it on samus.
Also remove the multi-line scrolling since normal scrolling is fast enough
now.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 430ms to 12ms.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: video: Support copy framebuffer with probed devices

For PCI video devices that are not mentioned in the devicetree, U-Boot
does not bind a driver before relocation, since PCI is not fully probed
at that point. Furthermore it is possible for the video device to be on
a secondary bus which is not even scanned.

This is fine if the framebuffer is allocated in fixed memory, as it
normally is on x86. But when using this as a copy framebuffer, we also
need U-Boot to allocate its own cached framebuffer for working in. Since
the video driver is never bound before relocation, the framebuffer size
is never set and U-Boot does no allocation.

Add a new CONFIG option to reserve 16MB of memory for this eventuality.
This allows vesa devices to use the copy framebuffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Correctly handle multiple framebuffers

At present video_bottom is set to the bottom of each framebuffer when it
is allocated. This is not correct, since it should hold the bottom of the
entire area available for framebuffers.

Fix this by adding a private address in the uclass which keeps track of
the next available spot for a framebuffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

x86: fsp: video: Allocate a frame buffer when needed

When the copy framebuffer is in use, we must also have the standard U-Boot
framebuffer available. Update the FSP driver to support this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: pci: Set up the copy framebuffer

When using a copy framebuffer we need to tell the video subsystem its
address. U-Boot's normally allocated framebuffer is used as the working
buffer, but nothing is displayed until it is copied to the copy
framebuffer.

For this to work the video driver must request that a framebuffer be
allocated separately from the hardware framebuffer, so add a check for
that.

Also add a log category so that logging appears correctly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: sandbox: Add support for the copy framebuffer

Enable this feature on sandbox by updating the SDL driver to have two
framebuffers.

Update the video tests to check that the copy framebuffer is kept in sync.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>

video: Add comments to struct sandbox_sdl_plat

This struct is not commented but needs it. Also fix the comment in
check_vidconsole_output() about the encoding for the rotation value.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>

video: Update the copy framebuffer when writing bitmaps

Adjust the bitmap code to sync to the copy framebuffer when done.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Update rotated console to support copy buffer

Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Update truetype console to support copy buffer

Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Update normal console to support copy buffer

Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Add helpers for vidconsole for the copy framebuffer

Add a convenience function to call video_sync_copy() for a vidconsole.
Also add a memmove() helper, which does the memmove() as well as the sync.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Clear the copy framebuffer when clearing the screen

Update video_clear() to also sync to the copy framebuffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Set up the copy framebuffer when enabled

This framebuffer is separately mapped. Update the video post-probe
function to set this up.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Add support for copying to a hardware framebuffer

Some architectures use a cached framebuffer and flush the cache as needed
so that changes are visible. This is supported by U-Boot.

However x86 uses an uncached framebuffer with a 'write-combining' feature
to speed up writes.  Reads are permitted but they are extremely expensive.

Unfortunately, reading from the frame buffer is quite common, e.g. to
scroll it. This makes scrolling very slow.

Add a new feature which supports copying modified parts of the frame
buffer to the uncached hardware buffer. This speeds up scrolling by at
least 10x on x86 so the extra complexity cost seems worth it.

As a starting point, add the Kconfig, update the video structures to keep
track of the buffer and add a function to do the copy.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Add a comment for struct video_uc_platdata

Add a few notes to explain the purpose of each member of this struct.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

video: Drop unnecessary #ifdef around vid_console_color()

All of the functions in this file only apply if DM_VIDEO is enabled. Drop
the #ifdef as it just clutters things up. Add the needed forward
declaration.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

video: Adjust rotated console to start at right edge

At present when the console is rotated 180 degrees it starts almost a
whole character to the left of the right edge (typically 7 pixels with
an 8-pixel-wide font). On a display which aligns with the font width,
this just wastes space. On a display that does not this can result in
x_frac going negative for the final character (the one on the left
side) and the overflow -EAGAIN check at the start of the function
failing.

Change the function to start at the rightmost pixel to fix these
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Split out expression parts into variables

The functions in this file do similar things but not always in the same
way. To make the code easier to read and compare, use a separate 'linenum'
variable in every function. This is then multiplied by the line length to
get the offset within the frame buffer to modify. Also use an 'x' variable
to hold the pixel position within that line. This is multipled by the
pixel size and added to the offset.

Also move the pbytes declaration up a little with the other long lines.

A side effect of splitting out these variables is that they are promoted
to int, i.e. a signed type, from the unsigned short used in the
vidconsole_priv struct. This would be necessary should any of the
variables go negative. At present this can actually happen in
console_putc_xy_2(), if the display width is not a multiple of the
character size (see next patch).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

sandbox: video: Allow selection of rotated console

Add a devicetree property to select a rotated console. This uses the same
encoding as vidconsole itself: 0=normal; 1=90 degrees clockwise, 2=upside
down, 3=90 degrees anticlockwise.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>

video: Show an error when a vidconsole function fails

At present these functions fail silently even when debugging, which is not
very helpful. Add a way to print a message to the serial output when an
error is detected.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

console: Add a way to output to serial only

In the video drivers it is useful to print errors while debugging but
doing so risks an infinite loop as the debugging info itself may go
through the video drivers.

Add a new console function that prints information only to the serial
device, thus making it safe for use in debugging.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: fsp: Reinit the FPU after FSP meminit

The APL FSP appears to leave the FPU in a bad state in that it has
registers in use. This causes an error when the next FPU operation is
performed.

Work around this by re-resetting the FPU after calling FSP-M. This allows
the freetype console to work correctly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

pwm: Add PWM driver for SiFive SoC

Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC
This driver is simple port of Linux pwm sifive driver from Linux v5.6

commit: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM")

Signed-off-by: Yash Shah <yash.shah@sifive.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

pwm: Add DT documentation for SiFive PWM Controller

DT documentation for PWM controller added from Linux v5.6

commit: daa78cc3408e
("pwm: sifive: Add DT documentation for SiFive PWM Controller")

Signed-off-by: Yash Shah <yash.shah@sifive.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: stm32f7: SYSCFG Fast Mode Plus support for I2C STM32F7

Read SYSCFG bindings to set Fast Mode Plus bits if Fast Mode Plus
speed is selected.

Handle the stm32mp15 specific compatible to handle FastMode+
registers handling which is different on the stm32mp15 compared
to the stm32f7 or stm32h7.
Indeed, on the stm32mp15, the FastMode+ set and clear registers
are separated while on the other platforms (F7 or H7) the control
is done in a unique register.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: stm32f7: add stm32mp15 compatible

Add a new compatible "st,stm32mp15-i2c" introduced in Linux kernel v5.8

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

test: dm: rtc: add tests of rtc shell command

Add tests of the "list", "read" and "write" subcommands of the rtc
shell command.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

sandbox: add rtc command to defconfigs

In order to allow adding unit tests of the rtc command, add it to the
various sandbox defconfigs.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

test: dm: rtc: add test of dm_rtc_read, dm_rtc_write

Define a few aux registers and check that they can be read/written
individually. Also check that one can access the time-keeping
registers directly and get the expected results.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: i2c_rtc_emul: catch any write to the "reset" register

It's more natural that any write that happens to touch the reset
register should cause a reset, rather than just a write that starts at
that offset.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: sandbox-rtc: fix set method

The current set method is broken; a simple test case is to first set
the date to something in April, then change the date to 31st May:

=> date 040412122020.34
Date: 2020-04-04 (Saturday)    Time: 12:12:34
=> date 053112122020.34
Date: 2020-05-01 (Friday)    Time: 12:12:34

or via the amending of the existing rtc_set_get test case similarly:

$ ./u-boot -T -v
=> ut dm rtc_set_get
Test: dm_test_rtc_set_get: rtc.c
expected: 31/08/2004 18:18:00
actual: 01/08/2004 18:18:00

The problem is that after each register write,
sandbox_i2c_rtc_complete_write() gets called and sets the internal
time from the current set of registers. However, when we get to
writing 31 to mday, the registers are in an inconsistent state (mon is
still 4), so the mktime machinery ends up translating April 31st to
May 1st. Upon the next register write, the registers are populated by
sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets
overwritten by a 1.

Fix it by writing all registers at once, and for consistency, update
the get method to retrieve them all with one "i2c transfer".

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: add rtc command

Mostly as an aid for debugging RTC drivers, provide a command that can
be used to read/write arbitrary registers (assuming the driver
provides the read/write methods or their single-register-at-a-time
variants).

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: pcf2127: provide ->write method

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: pcf2127: provide ->read method

This simply consists of renaming the existing pcf2127_read_reg()
helper to follow the naming of the other
methods (i.e. pcf2127_rtc_<method name>) and changing the type of its
"len" parameter.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: fall back to ->{read, write} if ->{read, write}8 are not provided

Similar to how the dm_rtc_{read,write} functions fall back to using
the {read,write}8 methods, do the opposite in the rtc_{read,write}8
functions.

This way, each driver only needs to provide either ->read8 or ->read
to make both rtc_read8() and dm_rtc_read() work - without this, a
driver that provides ->read() would most likely just duplicate the
logic here for implementing a ->read8() method in term of its ->read()
method. The same remarks of course apply to the write case.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: add dm_rtc_write() helper

Similar to dm_rtc_read(), introduce a helper that allows the caller to
write multiple consecutive 8-bit registers with one call. If the
driver provides the ->write method, use that, otherwise loop using
->write8.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: add dm_rtc_read helper and ->read method

Some users may want to read multiple consecutive 8-bit
registers. Instead of each caller having to implement the loop,
provide a dm_rtc_read() helper. Also, allow a driver to provide a
->read method, which can be more efficient than reading one register
at a time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

i2c: imx_lpi2c: Improve the codes to use private data

Current driver calls the devfdt_get_addr to get the base address
of lpi2c controller in each sub-functions. Since the devfdt_get_addr
accesses the DTB and translate the address, it introduces much
overhead.
Improve the codes to use private variable which has recorded the
base address from probe.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

board: presidio-asic: Add I2C support

Add I2C board support for Cortina Access Presidio Engineering Board

Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
CC: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: i2c-cortina: added CAxxxx I2C support

Add I2C controller support for Cortina Access CAxxxx SoCs

Signed-off-by: Arthur Li <arthur.li@cortina-access.com>
Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
CC: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
hs: fixed build error, add include log.h

i2c: octeon_i2c: Add I2C controller driver for Octeon

Add support for I2C controllers found on Octeon II/III and Octeon TX
TX2 SoC platforms.

Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Suneel Garapati <sgarapati@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Chandrakala Chavva <cchavva@marvell.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>