Add functionality to be able to print pin bias settings along with the
pinmux setting.

This can be useful to debug why pins might not be working correctly.

Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Link: https://patch.msgid.link/20260330-pinctrl-mtk-fix-mt8189-v2-3-05a737ec623d@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>

Add a new PINCTRL_PIN_REG_RSEL register type and a new function
mtk_pinconf_bias_set_pu_pd_rsel() to handle setting it.

Some MediaTek SoCs have a pin configuration register called RSEL that
sets the resistance value for bias pullup/pulldown.

Link: https://patch.msgid.link/20260330-pinctrl-mtk-fix-mt8189-v2-1-05a737ec623d@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>

Add a bounds check on the number of base addresses to prevent
out-of-bounds access to the priv->base array.

Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Link: https://patch.msgid.link/20260209-mtk-pinctl-mt8189-v1-1-a7a3069eda6c@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>

Add pinmux_property_set ops for mediatek pinctrl framework

Signed-off-by: Julien Masson <jmasson@baylibre.com>
Signed-off-by: Vitor Sato Eschholz <vsatoes@baylibre.com>
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Tested-by: David Lechner <dlechner@baylibre.com>

Replace uclass_get_device_by_ofnode() with syscon_regmap_lookup_by_phandle()
to get the "mediatek,pctl-regmap" syscon device.

Depending on probe order, uclass_get_device_by_ofnode() may fail, but
syscon_regmap_lookup_by_phandle() has logic in it to handle that case
correctly.

The previous implementation could read more than one syscon if the
"mediatek,pctl-regmap" property had more than one phandle, but the one
board with a devicetree that does that is not supported in U-Boot yet,
so we can save that for later (it may never be needed).

Fixes: 424ceba18bfb ("pinctrl: mediatek: support mediatek,pctl-regmap property")
Signed-off-by: David Lechner <dlechner@baylibre.com>

Ignore the error return value from mtk_pinconf_bias_set_pupd_r1_r0().
The PUPD/R1/R0 registers only include a small subset of the pins, so
it is normal for this function to return an error for most pins.
Therefore, this error should not be propagated.

This fixes not all pins in a pinmux group being configured in some
cases because the propagated error caused the configuration loop to
exit early.

The rest of the function is refactored to return early on errors to
improve readability.

Signed-off-by: David Lechner <dlechner@baylibre.com>

Add support for the mediatek,pctl-regmap devicetree property to the
common MediaTek pinctrl driver.

In upstream devicetrees from Linux, the pinctrl nodes may be on the
interrupt controller register address space rather than the pinctrl
register address space. In this case, there is a syscon node linking to
the actual pinctrl registers. This uses a common property name of
mediatek,pctl-regmap for the phandle to the syscon node.

The logic here is that if this property is present, we look up the
syscon node and use it's address as the base address of the pinctrl
registers and ignore the pinctrl node's own reg property. (Support
for interrupts could be added later if needed.)

There is also at least one SoC in Linux that has two syscon phandles
in this property. This implementation support parsing this, but doesn't
do anything with the second syscon yet (the 2nd syscon is for interrupts
which we are saving for later).

Signed-off-by: David Lechner <dlechner@baylibre.com>

This patch add support to read register base address by name if
provided.

Also devfdt_get_addr_* is changed to dev_read_addr_* to support DT
live tree.

Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>

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 the new symbol to refer to any 'SPL' build, including TPL and VPL

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