Message-Id: <0E900830-E248-4F0F-A048-075EAF1D2440@goldelico.com>
Date: Tue, 25 Nov 2025 11:25:24 +0100
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Romain Gantois <romain.gantois@...tlin.com>
Cc: Liam Girdwood <lgirdwood@...il.com>,
 Mark Brown <broonie@...nel.org>,
 Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Jonathan Cameron <jic23@...nel.org>,
 David Lechner <dlechner@...libre.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>,
 Guenter Roeck <linux@...ck-us.net>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org,
 linux-iio@...r.kernel.org,
 Conor Dooley <conor.dooley@...rochip.com>,
 MyungJoo Ham <myungjoo.ham@...sung.com>,
 Chanwoo Choi <cw00.choi@...sung.com>,
 Peter Rosin <peda@...ntia.se>,
 Mariel Tinaco <Mariel.Tinaco@...log.com>,
 Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Kevin Tsai <ktsai@...ellamicro.com>,
 Linus Walleij <linus.walleij@...aro.org>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>,
 Eugen Hristev <eugen.hristev@...aro.org>,
 Vinod Koul <vkoul@...nel.org>,
 Kishon Vijay Abraham I <kishon@...nel.org>,
 Sebastian Reichel <sre@...nel.org>,
 Chen-Yu Tsai <wens@...e.org>,
 Support Opensource <support.opensource@...semi.com>,
 Paul Cercueil <paul@...pouillou.net>,
 Iskren Chernev <me@...ren.info>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 Matheus Castello <matheus@...tello.eng.br>,
 Saravanan Sekar <sravanhome@...il.com>,
 Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Casey Connolly <casey.connolly@...aro.org>,
 Pali Rohár <pali@...nel.org>,
 Orson Zhai <orsonzhai@...il.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Chunyan Zhang <zhang.lyra@...il.com>,
 Amit Kucheria <amitk@...nel.org>,
 Thara Gopinath <thara.gopinath@...il.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>,
 Zhang Rui <rui.zhang@...el.com>,
 Lukasz Luba <lukasz.luba@....com>,
 Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
 Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>,
 Sylwester Nawrocki <s.nawrocki@...sung.com>,
 Olivier Moysan <olivier.moysan@...s.st.com>,
 Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Dixit Parmar <dixitparmar19@...il.com>,
 linux-hwmon@...r.kernel.org,
 linux-input@...r.kernel.org,
 linux-phy@...ts.infradead.org,
 linux-pm@...r.kernel.org,
 linux-mips@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org,
 linux-arm-msm@...r.kernel.org,
 linux-sound@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 Andy Shevchenko <andriy.shevchenko@...el.com>
Subject: Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator

Hi,


> Am 25.11.2025 um 09:41 schrieb Romain Gantois <romain.gantois@...tlin.com>:
> 
> 
> This is planned support for a voltage regulator chip.


Well, but one which is not by itself programmable. So IMHO, it does not support that chip,
but the circuit it is used in.

> 
> > Are you looking for a virtual "glue" driver to logically combine several low
> > level functions?
> > 
> 
> I'm looking for a clean userspace abstraction for this component, the low-
> level functions in this case are those of a voltage regulator.

As far as I understood it has
- constant voltage
- current can be limited
- it can be turned on/off

That means it is a fixed-regulator (for constant voltage and turn on/off)
and a mechanism to program the current limit (iio-dac). Both have clean
userspace abstraction.

What am I missing?

> > What I still wonder: does your hardware warrant an upstream driver for a
> > non-programable chip if a different solution (with help of user-space)
> > already exist?
> > 
> 
> A different solution does not currently exist (although a userspace-based 
> solution could be designed). I just think that a kernel-based solution is more 
> desirable here.

I agree, but that is a common discussion :) For example, years ago I had a long
discussion if there should be touchscreen pre-calibration in kernel, which is
desirable to get it almost right after boot, or if it is user-space... In the
end it was rejected.

> 
> > Another question: is your scheme generic enough so that it can be expected
> > that other devices are using it in the same way?
> > 
> 
> Yes, the LTM8054 has a fairly common design as far as buck-boost chips go. 
> Things like feedback dividers on the output voltage pin are standard practice.

Yes, I know - but how is this related to the kernel or a driver? To my knowledge
feedback dividers are never relevant for kernel drivers for buck regulators,
especially if they are fixed and can not be programmed. They end up in a specification
of regulator-min-microvolt and regulator-max-microvolt.

So I still wonder why they must be made available to the kernel and user-space.

If you look for example into the schematics of a PocketBeagle 2 
(https://docs.beagleboard.org/pocketbeagle-2.pdf).

Figure 3.23 on page 26 shows a 3.3V step-down converter with enable and feedback
resistors (560k/124k).

Still, this regulator is represented not by a dedicated TLV62595 driver but:

https://elixir.bootlin.com/linux/v6.18-rc7/source/arch/arm64/boot/dts/ti/k3-am62-pocketbeagle2.dts#L91

Well, it does not have a controllable current limit, just a builtin one.
(And a gpio-control could be added by using a regulator-gpio driver).

> And since the driver doesn't rely on a particular way of integrating the 
> LTM8054 with other components, it can be reused wherever the same regulator 
> chip is used.

That are my questions:
- what is so different with an LTM8054 to other buck regulators that it needs a dedicated driver
- is the feature to control current limit by a DAC to the LTM8054 or is it the DAC (in software perspective)
- does it need a conversion factor from mA to binary value? Why is this needed in kernel?
- are there similar designs planned for this chip or already in use which run Linux?

> > Or could the power controller framework (/sys/class/power_supply) fit
> > better?
> > 
> 
> I don't think the power supply abstraction is relevant here. The LTM8054 is a 
> voltage regulator, it doesn't have charge, capacity, temperature monitoring, 
> power limitation, or other power supply class features.

By current limitation you also have power limitation. Yes, it does not
need to provide charge, capacity, temperature but IMHO they are not all mandatory.
It is just a suggestion to look around if there are different abstractions
that already exist and can be used.

> 
> > There is an API to ask chargers etc. for battery voltage and current limits
> > or even write them.
> > 
> > There is also "generic-adc-battery" which allows to hook up with arbitrary
> > iio-adcs for measurements - although you need a DAC in your setup. Maybe an
> > extension here is a better strategy than a dedicated ltm8054 driver?
> 
> 
> What if the LTM8054 is not used to supply a battery?

The question remains if you want to solve something for a single board which
happens to have an LTM8054 or if you are solving a more general design pattern.

In summary my view is that the LTM8054 is just a "fixed-regulator" which
gets an additional current-limiter feature by adding a DAC chip (which needs a
driver of course). So software control is required not by the LTM8054 but by
adding a DAC chip.

Another suggestion: what extending the "regulator-fixed", "regulator-gpio",
"regulator-fixed-clock" pattern by some "regulator-gpio-iio-dac-current-limiter"
driver to make it independent of your specific chip?

By the way, are you aware of this feature of the regulator-gpio driver?

https://elixir.bootlin.com/linux/v6.18-rc7/source/drivers/regulator/gpio-regulator.c#L97

Just to note: I am neither maintainer nor doing any decisions on this, just asking
questions for curiosity and from experience and giving hints for alternative approaches,
where I hope they help to find the really best solution.

Best regards,
Nikolaus

Powered by blists - more mailing lists