Message-ID: <20251031012218.7cc86801@minigeek.lan>
Date: Fri, 31 Oct 2025 01:22:18 +0000
From: Andre Przywara <andre.przywara@....com>
To: Yixun Lan <dlan@...too.org>
Cc: Lee Jones <lee@...nel.org>, Chen-Yu Tsai <wens@...nel.org>, Liam
 Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Samuel
 Holland <samuel@...lland.org>, Jernej Skrabec <jernej.skrabec@...il.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
 linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] regulator: axp20x: add support for the AXP318W

On Wed, 22 Oct 2025 15:58:16 +0800
Yixun Lan <dlan@...too.org> wrote:

Hi,

> Hi Andre,
> 
> On 01:47 Wed 22 Oct     , Andre Przywara wrote:
> > On Wed, 22 Oct 2025 08:14:20 +0800
> > Yixun Lan <dlan@...too.org> wrote:
> > 
> > Hi,
> > 
> > thanks for having a look!
> >   
> > > Hi Andre,
> > > 
> > > On 12:20 Tue 21 Oct     , Andre Przywara wrote:  
> > > > The X-Powers AXP318W is a typical PMIC from X-Powers, featuring nine
> > > > DC/DC converters and 28 LDOs, on the regulator side.
> > > > 
> > > > Describe the chip's voltage settings and switch registers, how the
> > > > voltages are encoded, and connect this to the MFD device via its
> > > > regulator ID.
> > > > We use just "318" for the internal identifiers, for easier typing and
> > > > less churn. If something else other than the "AXP318W" shows up, that's
> > > > an easy change, externally visible strings carry the additional letter
> > > > already.
> > > > 
> > > > Signed-off-by: Andre Przywara <andre.przywara@....com>
> > > > ---
> > > >  drivers/regulator/axp20x-regulator.c | 170 ++++++++++++++++++++++++++-
> > > >  include/linux/mfd/axp20x.h           |  43 +++++++
> > > >  2 files changed, 211 insertions(+), 2 deletions(-)
> > > >   
> ..
> > > > +
> > > > +static const struct linear_range axp318_dcdc8_ranges[] = {
> > > > +	REGULATOR_LINEAR_RANGE(500000,    0,  70,  10000),
> > > > +	REGULATOR_LINEAR_RANGE(1220000,  71, 102,  20000),
> > > > +	REGULATOR_LINEAR_RANGE(1900000, 103, 118, 100000),
> > > > +};    
> > > 
> > > In the AXP318W datasheet, it says:
> > > section 7.1 DCDC/LCO desgin
> > >  8. DCDC6/7/8/9 only able to tune at two voltage ranges which are
> > >  <1.54v and >1.54v, the tuning voltage should not step cross 1.54v
> > >  (I translate the original doc into english)  
> > 
> > Thanks, I now read something similar in my Google translated copy of the
> > datasheet. But I don't understand what this is supposed to mean? That
> > exactly 1.54V does not work, so the value of 87 is invalid? But any
> > other value can be set?  
> I did a hard chinese - english translation..
> 
> No, I think it's probably a mistake that if user interpret value 87 as invalid,
> from my understanding, DCDC6-9 only able to tune the voltage in two ranges:
> (if user need to adjust the voltage dynamically)
> 
> a) range 0.5v - 1.54v (probably include 1.54v)
> b) range 1.54v - 1.9v (probably also include 1.54v)
> 
> but can not tune in this case, example from range 1.5v - 1.6v which will
> cross 1.54v point.

I am not sure I fully understand: as far is this driver is concerned,
these are just translations from target voltages to register values,
there is no notion of some transition or slope. The upper layer is
free to program any value it wants. So I don't know what the
restriction is, really: is it that the first value programmed to this
register sets a limit? So if you set something below 1.54V, you
cannot program anything higher than that later? And how do you get out
of this, by disabling the output, and re-programming? And do we really
know that, or has someone verified that, or is that just what written
in the manual?

And if that's the case, I don't see how we can model this with the
current driver. It's highly irrelevant anyway, since most voltages
programmed are fixed anyways, and for instance on the Radxa A7E are all
well below 1.54V.

So long story short: I would ignore this until someone reports an
actual issue. For the boards at hand I don't expect any.

> I don't understand the logic behind but guess it's up to the HW/SoC
> restriction in the design perspective..
> >   
> > > 
> > > so, with this restricition, should we split the range into two?
> > > one is dcdc6_lo_range, another dcdc6_hi_range
> > > 
> > > or what do you think?
> > > 
> > > ..  
> > > > +	AXP_DESC(AXP318, ELDO1, "eldo1", "eldoin", 500, 1500, 25,
> > > > +		 AXP318_ELDO1_CONTROL, AXP318_ELDO_V_OUT_MASK,
> > > > +		 AXP318_LDO_OUTPUT_CONTROL3, BIT(6)),
> > > > +	AXP_DESC(AXP318, ELDO2, "eldo2", "eldoin", 500, 1500, 25,
> > > > +		 AXP318_ELDO2_CONTROL, AXP318_ELDO_V_OUT_MASK,
> > > > +		 AXP318_LDO_OUTPUT_CONTROL3, BIT(7)),
> > > > +	AXP_DESC(AXP318, ELDO3, "eldo3", "eldoin", 500, 1500, 25,
> > > > +		 AXP318_ELDO3_CONTROL, AXP318_ELDO_V_OUT_MASK,
> > > > +		 AXP318_LDO_OUTPUT_CONTROL4, BIT(0)),
> > > > +	AXP_DESC(AXP318, ELDO4, "eldo4", "eldoin", 500, 1500, 25,
> > > > +		 AXP318_ELDO4_CONTROL, AXP318_ELDO_V_OUT_MASK,
> > > > +		 AXP318_LDO_OUTPUT_CONTROL4, BIT(1)),
> > > > +	AXP_DESC(AXP318, ELDO5, "eldo5", "eldoin", 500, 1500, 25,
> > > > +		 AXP318_ELDO5_CONTROL, AXP318_ELDO_V_OUT_MASK,
> > > > +		 AXP318_LDO_OUTPUT_CONTROL4, BIT(2)),
> > > > +	AXP_DESC(AXP318, ELDO6, "eldo6", "eldoin", 500, 1500, 25,
> > > > +		 AXP318_ELDO6_CONTROL, AXP318_ELDO_V_OUT_MASK,
> > > > +		 AXP318_LDO_OUTPUT_CONTROL4, BIT(3)),    
> > > 
> > > also, in section 7.1 DCDC/LCO desgin
> > >  3. ELDOIN can use DCDC's output as the voltage input, once in this case,
> > >  the LDO (output?) config voltage should lower than DCDC input voltage.
> > > 
> > > Note: ELDOIN can use PS(Power Supply, should be equal to DCIN) or DCDC as input
> > > 
> > > in case of Radxa A7A (A733) board, it use DCDC9 as ELDOIN,
> > > Should we do something in the driver level? or leave up to user  
> > 
> > "User" really means board vendor here, right? As the actual board  
> could be user from software level perspective, who use or design this

No actual *user* on the software side would program those voltages,
those are all described in the DT. Again, if the board designer didn't
consider this, it's a major fault, and it just wouldn't work.

> > user is not meant to adjust those voltages anyway, and any range
> > limitations should be considered during the board design phase.  
> I'd be fine if push these up to designer, and blame them for wrong usage

Yes.

> > So yes, DCDC9 is at 1.24V on the Radxa, and ELDOIN is connected to
> > that, but only ELDO1 and ELDO6 are used, and they are fixed to 900mV
> > and 800mV, respectively, and connected to SoC pins that require exactly
> > those voltages. So there is no room for change or to adjust things
> > here, and the requirements are met.  
> for this single case, right, we shouldn't worry about..
> 
> > If board designers/people ignore that, that it just won't work, and
> > they get to keep the pieces. Nothing the driver can do here.
> >   
> from a driver level, at least we can emit an error message to alert 
> user of the wrong voltage value set..

But where would you do that? Is there a callback or hook, where we
could check this? I don't see any.

Cheers,
Andre

Powered by blists - more mailing lists