From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C1D9314A8E; Mon, 24 Nov 2025 15:57:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763999865; cv=none; b=vFxuXZKy5L2cbD3I7cfXYtXBcwR7r08uV9rY0QdSaAPkVSbmpbpTH88ent484qmFdO0SMqN/upv2AuVosIJBhQDimq1ybVZD+xRWEPVPNsszyW7vZdIYPWFITJG8Kd6LHSpUIgt5Tl9wxZLTnUHR7Ig+nguAa/hPKBHS0+DBLNA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763999865; c=relaxed/simple; bh=yGI97hDLro8+McOQ+lHZp2VCQuWtN25N7eUBLNYm8jU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rTCsm3F2lnq7TAt/+LcdW13xRmQbXCch6c9ZUKmnAMj/ev38+TWORiKXVad0Mr8ZrqOCBtHIACfQ+775h1cgIMw/cPEzmJocUsX1XkHzOxSlMMcSz6mLyJKWzklWBv36HJvmKyNvQy/6NSHG8E8uAiEIDeC+jzWk+uzxyIGyXw8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=VarxPDuE; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="VarxPDuE" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id A03C64E41884; Mon, 24 Nov 2025 15:57:41 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 71C74606FC; Mon, 24 Nov 2025 15:57:41 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 0297B10371A40; Mon, 24 Nov 2025 16:57:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1763999858; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=UX028RVBrtav4WisvLm2dO1F8K5+rUIM4Xp+GTn4l88=; b=VarxPDuEXoNSmVvJFI8GatO2RP9trnXzaYCfsYMM6RiiQJ2m93PBXrieFqWdi7u6Z2RoZg GAGA01Dg63AWsSjF79FfLxVFlCWOLC7nb+Zva16AiZR4LFaDIOkwTjS+1qvXT6UkmCc4TH yzjFgzaGeZFlS18DchOYD0zIe6ixo0ZO9D4JFiPQlx//8nY7IyIYwgA24Z48+/kegy6SN7 r9KW3P+aPv0ig9jzpcYgX+xbOwsPSqiPsLbiFMkGf/rdRqa9+vF2g0o12LRVP64iuC5S5t QWlRuX+uUfAmODHQDKv6cyMvrBcyY/vc3NIbj+57IejdauvBbh+DRTxNEjxg7Q== From: Romain Gantois To: "H. Nikolaus Schaller" Cc: Liam Girdwood , Mark Brown , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jonathan Cameron , David Lechner , Nuno =?UTF-8?B?U8Oh?= , Andy Shevchenko , Guenter Roeck , Thomas Petazzoni , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-iio@vger.kernel.org, Conor Dooley , MyungJoo Ham , Chanwoo Choi , Peter Rosin , Mariel Tinaco , Lars-Peter Clausen , Michael Hennerich , Kevin Tsai , Linus Walleij , Dmitry Torokhov , Eugen Hristev , Vinod Koul , Kishon Vijay Abraham I , Sebastian Reichel , Chen-Yu Tsai , Support Opensource , Paul Cercueil , Iskren Chernev , Marek Szyprowski , Matheus Castello , Saravanan Sekar , Matthias Brugger , AngeloGioacchino Del Regno , Casey Connolly , Pali =?UTF-8?B?Um9ow6Fy?= , Orson Zhai , Baolin Wang , Chunyan Zhang , Amit Kucheria , Thara Gopinath , "Rafael J. Wysocki" , Daniel Lezcano , Zhang Rui , Lukasz Luba , Claudiu Beznea , Jaroslav Kysela , Takashi Iwai , Sylwester Nawrocki , Olivier Moysan , Arnaud Pouliquen , Maxime Coquelin , Alexandre Torgue , Dixit Parmar , linux-hwmon@vger.kernel.org, linux-input@vger.kernel.org, linux-phy@lists.infradead.org, linux-pm@vger.kernel.org, linux-mips@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-sound@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, Andy Shevchenko Subject: Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator Date: Mon, 24 Nov 2025 16:57:16 +0100 Message-ID: <4053840.MHq7AAxBmi@fw-rgant> In-Reply-To: <563331EB-2460-4CF5-87B3-5FE60B18BB70@goldelico.com> References: <20251124-ltm8054-driver-v4-0-107a8a814abe@bootlin.com> <23111366.EfDdHjke4D@fw-rgant> <563331EB-2460-4CF5-87B3-5FE60B18BB70@goldelico.com> Precedence: bulk X-Mailing-List: linux-input@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2111402.atdPhlSkOF"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Last-TLS-Session-Version: TLSv1.3 --nextPart2111402.atdPhlSkOF Content-Type: multipart/alternative; boundary="nextPart2186563.taCxCBeP46"; protected-headers="v1" Content-Transfer-Encoding: 7Bit From: Romain Gantois To: "H. Nikolaus Schaller" Date: Mon, 24 Nov 2025 16:57:16 +0100 Message-ID: <4053840.MHq7AAxBmi@fw-rgant> In-Reply-To: <563331EB-2460-4CF5-87B3-5FE60B18BB70@goldelico.com> MIME-Version: 1.0 This is a multi-part message in MIME format. --nextPart2186563.taCxCBeP46 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" 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 --nextPart2186563.taCxCBeP46 Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="utf-8"

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


--nextPart2186563.taCxCBeP46-- --nextPart2111402.atdPhlSkOF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEIcCsAScRrtr7W0x0KCYAIARzeA4FAmkkgFwACgkQKCYAIARz eA6Alg/8COym+7pL1LpZ1EUBzLeuPJJMpNXAoKBsdBPOyD3NnxUoT3dqx1KV6Qxl qgm6tINDewDnwWGblDKog18X7I3G9JZVLM4/LwN//KMnkzo+GcECfLyFvnNrzKhg X1ZpkaamjbifIadbFXhOy1HQ/A6tO90ICk4ae2Dgye9PCZAqsL/GUGtcwiJzbWTk mNNqqvmwxf7KGS/63peSY0oGREjOfo95tZPllfLxP5lgvdVP/kiTot7ErGsaFh5y zzUIaEYjpiE86eQ+0/gKRs+Xkn4sAOyPzzRwoycI9JsYuJOPLEkIdChhAKNkKUD9 MmGR4aMVjgLxKxu2dfNwsJmVQJ8mkVor+3jqyP77XSyM7E71ZesHrujCRodKaicr hiTtUMGt5qkalsMDHQLJ8MR3R/hMJWK2u1uKitIC0NhXCNQfR2yGlEothJDFcdQL K0cOhaJGpDnxfaopsfnN9ianNPZ5MhUYJj6qvQPAjTtARK8E+uL2ysXgZ9bQ1xKx g+URjMLJ49zdR8rHCJw0PLPE7Cb8GcsPFlad9yWPzjhJxk5y8JTMNWAnzZTRH96b I/PLDFBC9fy13WU6sj9591J0oxcpRC/k6ctEDZzN5sQZ8J+2rwc9moNFpGRpuLGc sefn100uth/gnbi+8IJjmTB564t5KIY0Xpnk7+3vfqFC2a88B+o= =Wv+m -----END PGP SIGNATURE----- --nextPart2111402.atdPhlSkOF--