To ease debugging, use dev_err() instead of dev_dbg() for
alerting when regulator has nonunique value.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

Replace some debug() by dev_dbg() when dev variable
is available/valid.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

Convert to using livetree API functions.

Without this if livetree is enabled (OF_LIVE) the imx8m-power-domain
driver will (silently) fail to probe its children leaving you with
no power domain support causing issues with certain devices.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

Manorit Chawdhry <m-chawdhry@ti.com> says:

This series adds support for Adaptive voltage scaling on J721S2 device [0].

[0]: https://www.ti.com/lit/pdf/spruj28 (Section 5.2.4.1 AVS Support)

AVS Test for J721S2: https://gist.github.com/manorit2001/b2fd9f6764a863294d4aa0755c83c84f
Boot Test results: https://gist.github.com/manorit2001/d44e035552cb19aadeb0d928d5cb5f26

Link: https://lore.kernel.org/r/20241015-b4-upstream-j721s2-avs-v5-0-5c8087387dc5@ti.com

This Kconfig depends on DM_PMIC but hadn't be explicitly stated which
could cause config related issues.

Adds the dependency in Kconfig for tps65941.

Fixes: 6b86dd0c1ead ("power: pmic: tps65941: Add support for tps65941 family of PMICs")
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Aniket Limaye <a-limaye@ti.com>

- Add Libre Computer boards into proper libre-computer board directory
- Add new Boards:
 - Libre Computer aml-s905d3-cc
 - Libre Computer aml-a311d-cc
- Add capsule update to libretech-ac and the new boards since they have an onboard SPI nor flash
- Fix HDMI support after sync to v6.11 and regulator enable from Marek
- Fix khadas-vim3 android config for android-mainline kernel
- Disable meson64 boot targets when configs are not eavailable

The upstream Device Tree for GXBB/GXL/G12A was updated with VPU domain
shared between the VPU and HDMI node, causing a double enable.

Simply store the enable state and avoid enabling twice, fixing
HDMI output on all platforms.

Link: https://lore.kernel.org/r/20241009-u-boot-topic-fix-hdmi-v1-2-2479cd90c4ea@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>

This switches all boards with the Allwinner H616/H618/H313/H700 SoCs over to
use OF_UPSTREAM. We are doing it for this SoC family only since the DTs
between the U-Boot and the kernel repo are exactly identical, whereas other
families have one compatibility fix in U-Boot to allow booting older kernels.
Other will follow if this plays out well.

The biggest chunk otherwise is adding support for an Anbernic game console,
using the H700 SoC. For that we need to enhance the DRAM support code, and
pick two DT commits from the mainline kernel/DT rebasing repo, followed
by the defconfig patch.

On top of that two small fixes for the old Allwinner A80.

Gitlab CI passed, and I booted that briefly on some boards, including an
H616 and an H618 one (with LPDDR4).

Simon Glass <sjg@chromium.org> says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.

Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.

Update the comment in bootstage to refer to this symbol, instead of
SPL_

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