Message-ID: <2024471.PYKUYFuaPT@fw-rgant>
Date: Mon, 08 Dec 2025 09:57:24 +0100
From: Romain Gantois <romain.gantois@...tlin.com>
To: Guenter Roeck <linux@...ck-us.net>, Jonathan Cameron <jic23@...nel.org>
Cc: "H. Nikolaus Schaller" <hns@...delico.com>,
 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>, David Lechner <dlechner@...libre.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>,
 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

On Sunday, 7 December 2025 19:48:18 CET Jonathan Cameron wrote:
> On Tue, 25 Nov 2025 08:37:20 -0800
> 
> Guenter Roeck <linux@...ck-us.net> wrote:
> > On 11/25/25 02:25, H. Nikolaus Schaller wrote:
> > ...
> > 
> > > 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?
> > 
> > The name is terrible ;-), but that is what I would have suggested as well.
> > I don't see anything chip specific in this code. If there is a need for
> > a regulator driver which uses gpio to enable it and a DAC for current
> > limiting, it should be made generic.
> 
> Agreed - something generic is the ideal way to go.
> 
> However, before going too far it is worth exploring what are common circuits
> with these things to identify what parameters we need to describe how the
> DAC channel is used - e.g is linear scaling enough?  You'll need to that to
> define a DT binding. If it turns out to be too complex, then fallback to
> specific compatibles in a generic driver to cover the ones that don't fit
> with a common scheme.  A similar case we already have is discrete
> components as analog front ends for ADCs - mostly they fall into a few
> categories and we have drivers covering those, but some are very odd indeed
> and for those ones we do have a driver even though they don't have anything
> to control as such - most extreme case being when it's a non linear analog
> sensor.
> 

I actually did use a modified version of iio-rescale in my downstream code. My 
use case includes an OpAmp inverter circuit placed in front of a DAC, and it's 
useful for me to be able to describe this in a modular fashion, as two IIO 
device tree nodes representing respectively the DAC and the OpAmp circuit 
front-end.

Moreover, the LTM8054 takes a voltage on its CTL pin and infers a current 
limit from it. This is also something which could be represented as a sort of 
AFE node.

 LTM8054 output voltage control:           
+---+ +------------+ +--------------------+
|DAC+->Inverter AFE+->Feedback circuit AFE|
+---+ +------------+ +--------------------+
                                           
 LTM8054 output current limit control:     
+---+ +--------------------+               
|DAC+->Voltage-controller  |               
+---+ |current limiter AFE |               
      +--------------------+               

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