Add Renesas R-Car R8A78000 X5H MDLC power domain and reset driver,
which serves as a remap driver between DT power domain and reset IDs
and SCMI power domain and reset IDs in case U-Boot runs on Cortex-A,
and as a direct hardware access driver for RSIP.

The R-Car X5H SCP firmware uses different SCMI power domain and
reset IDs in different versions of the SCP firmware, which makes
this remapping necessary. The SCMI base protocol version is updated
for each new SCP firmware version, it is therefore possible to
determine which SCP firmware version is running on the platform
from the base protocol and then determine which remapping table to
use for DT power domain and reset ID to SCMI power domain and reset
ID remapping.

Currently supported versions are SCP 4.28, 4.31, 4.32 .

The DT power domain and reset ID to SCMI power domain and reset ID
remap and call mechanism is simple. Unlike SCMI clock protocol driver,
the SCMI reset and power domain protocol drivers register only a single
device. This driver looks up that single device, obtains its reset or
power domain ops, sets up struct reset_ctl or struct power_domain with
remapped SCMI ID, and invokes operations directly on the device.

In case of RSIP, all power domains are already enabled by BootROM or
early SoC initialization code, the driver therefore only acts as a
stub for the power domain part. The reset part operates as a direct
hardware access reset driver.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,pmgr-pwrstate" anymore [1]. Use
"apple,t8103-pmgr-pwrstate" as base compatible as it is the SoC driver
and bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,pmgr-pwrstate".

Link: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ [1]
Link: https://lore.kernel.org/asahi/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.net/ [2]
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>

Use CONFIG_$(PHASE_)DM_REGULATOR_PFUZE100 as the build condition for
pfuze100 regulator driver.
Add Kconfig option for SPL_DM_REGULATOR_PFUZE100.
To avoid break current platforms, set the Kconfig default value same
as PMIC_PFUZE100.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

Some BUCKs could work in single/dual phase mode, not in independent
mode. In single/dual phase mode, registers of both regulators,
must be identically set. So configure mode and value for both BUCKs.

CONF registers are not touched, leave them as default OTP settings.

PFUZE100/200 SW3A/B, could work in single/dual phase mode, so introduce
a new macro by adding a pointer to the SW3B descriptor.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

Some PFUZE regulators can operate in either low or high output voltage mode,
with different minimum voltages and voltage step sizes selected by a hardware
control bit. However, the current PFUZE100 regulator driver assumes low output
voltage mode only, resulting in incorrect voltage calculation and programming
when high voltage mode is enabled.

Extend the regulator descriptor to describe high output voltage mode by adding
a mask to detect the mode and a dedicated voltage description (min_uV and
step size). Update voltage get/set handling to dynamically select the correct
voltage parameters based on the high voltage mode bit.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

regulator-min-microvolt in device tree is not always match the minimal
voltage in the pmic datasheet, direclty using the min value from device
tree as base may cause wrong voltage settings being written.

Directly use the min_uV from datasheet to avoid wrong settings.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

Depending on the phase selection (single or multi), the FPWM bits
configured forces the regulator to operate in PWM mode. In case of
multi-phase selection, the FPWM_MP bits enforce the regulator to also
operate in multi-phase. This fixes correct multi-phase operation.

While at this, correct incorrect macro alignment as well.

Fixes: 065a452ae6a1 ("power: regulator: tps65941: add regulator support")
Link: https://www.ti.com/lit/ds/symlink/tps6594-q1.pdf
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Takuma Fujiwara <t-fujiwara1@ti.com>
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

Add mt8195 support.

Support comes directly from commit e88edc977b00 ("soc: mediatek: pwrap:
add pwrap driver for MT8195 SoC") from the Linux Kernel.

Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-8-73e83aa6345b@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>

Fix mt8188_regs definition to use tabs instead of spaces for alignment
to be consistent with other definitions.

Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-7-73e83aa6345b@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>

Change the logic for selecting pmic_children_info to use the compatible
string from the devicetree instead of expecting the pwrap (part of the
MCU) to correspond to the separate PMIC chip.

In addition to being more correct, it also saves a few lines of code for
each MCU type that is added by dropping the enum and type field.

Reviewed-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20260409-mtk-pmic-fixes-v2-6-73e83aa6345b@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>