Message-ID: <20250919000020.16969-1-andre.przywara@arm.com>
Date: Fri, 19 Sep 2025 01:00:15 +0100
From: Andre Przywara <andre.przywara@....com>
To: Lee Jones <lee@...nel.org>,
	Chen-Yu Tsai <wens@...e.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Samuel Holland <samuel@...lland.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>
Cc: devicetree@...r.kernel.org,
	linux-sunxi@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Mikhail Kalashnikov <iuncuim@...il.com>
Subject: [RFC PATCH 0/5] mfd: axp20x: program poly-phased regulators

Hi,

this series introduces support for X-Power AXP PMICs to actively control
poly-phase configurations. Some AXP PMICs allow to join two or more voltage
rails together, under the PMIC's control, to achieve higher currents and
reduced ripple, by offsetting each rail's phase.

So far we were just querying the active poly-phase configuration, as all
boards were using the reset default setup, which matched the board's
requirements. This information was just used to leave the coupled regulator
alone, as its configuration is synchronised internally to the "leading"
regulator.

Now boards with the A523 family of SoCs often come with an AXP323
dual-phase regulator, but use a single-phase reset default. However this
regulator pair supplies the "big" CPU cluster, so definitely needs a
dual-phase setup. Ignoring that leads to an immediate hang as soon as the
cluster leaves the safe 792 MHz/900mv OPP.

Looking at various datasheets of AXP PMICs reveals that there exist
dual-phase, but also triple-phase setups, although the latter is only used
by one PMIC at the moment. To be future proof, the following DT binding
design is proposed:
- The "x-powers,polyphased" property is introduced to list phandles of
  regulators that are phased together. Only the lead regulator needs
  to use that property:
	regulators {
		reg_dcdc1: dcdc1 {
			regulator-always-on;
			regulator-min-microvolt = <900000>;
			regulator-max-microvolt = <1220000>;
			regulator-name = "vdd-cpub";
			x-powers,polyphased = <&reg_dcdc2>;
		};

		reg_dcdc2: dcdc2 {
			/* dual-phased to DCDC1 */
		};
	};
- If the "x-powers,polyphased" property exists, but the list is empty
  (like a boolean property), the regulator will be removed from the
  poly-phase setup, so the affected regulators become independent.
- If the "x-powers,polyphased" property is absent, the existing poly-phase
  configuration will not be touched. This preserves backwards compatibility
  with the current situation.

Some off-tree downstream patches use a temptingly simpler solution: the
secondary rails just list a boolean property, to opt in to a poly-phase
setup. Besides becoming slightly ambiguous in a true multiphase
configuration, with three or more regulators involved, this has the big
disadvantage of not being backwards compatible: a missing property might
let the driver turn the poly-phase setup off, potentially breaking
existing setups.
The design proposed above avoids this problem by explicitly pointing out
all participating regulator rails, at the cost of some more code
complexity.

This series introduces the DT binding changes in patch 1/5.
Patch 2/5 refactors the current poly-phase *detection* code, to introduce
a data structure describing the known pairs. This should be considered
regardless of the rest of the patches, as a clean up.
Patch 3/5 adds support for connecting dual-phase regulators, patch 4/5
extends this to cover the one used tri-phase special case.
The final patch adds the property to the A527/T527 board DTs that need it.

This is a prerequisite for the upcoming DVFS support for the A523 family
of SoCs, as all those boards so far require to actively enable the
dual-phase bit.

I am marking this as RFC, to get opinions on those questions:
- Is the proposed DT binding a good solution? Shall the property name
  be more generic? Is there an existing solution to this problem?
- Is there a better, more generic way to describe poly-phased regulators
  in a data structure? The one proposed in patch 2/5 just supports
  dual-phased regulators, for simplicity.
- Do we need support for the special-cased tri-phase setup, as seen in
  patch 4/5? This is coded as some special case, but technically the
  boards using this tri-phase setup (Allwinner A80 based boards) are
  happy with the PMIC reset default.

I would be grateful to get some feedback on this, so that we can push
for a solution to eventually enable DVFS for the A523 family of SoCs.

Based on v6.17-rc1.

Cheers,
Andre

Andre Przywara (5):
  dt-bindings: mfd: x-powers,axp152: Add polyphased property
  mfd: axp20x: Refactor axp20x_is_polyphase_slave()
  mfd: axp20x: Allow programming dual-phase regulator pairs
  mfd: axp20x: Support tri-phase setup
  arm64: dts: allwinner: a523: Mark dual-phased regulators

 .../bindings/mfd/x-powers,axp152.yaml         |  14 ++
 .../dts/allwinner/sun55i-a527-cubie-a5e.dts   |   5 +-
 .../dts/allwinner/sun55i-h728-x96qpro+.dts    |   5 +-
 .../dts/allwinner/sun55i-t527-avaota-a1.dts   |   5 +-
 .../dts/allwinner/sun55i-t527-orangepi-4a.dts |   5 +-
 drivers/regulator/axp20x-regulator.c          | 190 ++++++++++++++----
 6 files changed, 181 insertions(+), 43 deletions(-)

-- 
2.46.4

Powered by blists - more mailing lists