Message-ID: <4053840.MHq7AAxBmi@fw-rgant>
Date: Mon, 24 Nov 2025 16:57:16 +0100
From: Romain Gantois <romain.gantois@...tlin.com>
To: "H. Nikolaus Schaller" <hns@...delico.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 Nikolaus,

On Monday, 24 November 2025 16:35:28 CET H. Nikolaus Schaller wrote:
...
> > Sorry, I don't quite understand your remark. To integrate this voltage
> > regulator component into the Linux regulator abstraction, I'm providing a
> > current limit control function. To provide such a function, the voltage
> > level on a pin has to be controlled. AFAIK, the kernel abstraction used
> > to set precise voltages on lines is an IO channel.
> 
> I was curious to learn about this topic and looked into the data sheet:
> 
> https://www.analog.com/media/en/technical-documentation/data-sheets/8054fa.p
> df
> 
> As far as I see the LTM8054 does not even have a programming interface.
> So is it reasonable to provide a dedicated driver at all?
> 
> The figure on page 20 seems to suggest that there is an external DAC
> which drives the regulator. And the regulator drives for example a fan.
> 
> So I would think of a driver for the specific DAC and ignore the specific
> LTM chip at all.
> 

In my use case, the LTM8054 feeds a DC output port on which various devices 
may be plugged. Dynamic output current limitation and output voltage level 
control for these devices is a requirement, as well as stepped voltage 
transitions, thus the need for a proper regulator device.

The LTM8054's feedback pin can be driven by a different DAC, which allows for 
dynamic output voltage control. This is a more complex upstreaming topic 
however, so I've left it out of this initial series. There are other component 
functions which fit in squarely into the regulator framework, such as 
input current limit control and soft-start. But I understand that the current 
driver might look a bit "bare".

> What could be necessary is if you really want to be able to "regulate"
> the current going to Vout, some bridge between regulator API and some
> IIO DAC.
> 
> And enabling/disabling the regulator by some GPIO can be described in
> the DT already through a "regulator-fixed".
> 

This is a possibility, but when you bring in all of these other hardware 
functions that I mentionned e.g. output voltage control and stepping, you'll 
end up with several different devices which look unrelated from userspace, but 
actually control the same chip.

Userspace will also have to know about some hardware details to properly 
control the DACs, such as the values of the sense and feedback resistors. In 
my opinion, this bypasses the kernel's abstraction of hardware.

Thanks,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Content of type "text/html" skipped

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists