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
Attachment:
signature.asc
Description: This is a digitally signed message part.