Received-SPF: pass (google.com: domain of linux-kernel+bounces-176641-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Sat, 11 May 2024 17:21:55 +0100
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: Mariel Tinaco <Mariel.Tinaco@analog.com>, linux-iio@vger.kernel.org,
 devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Lars-Peter
 Clausen <lars@metafoo.de>, Rob Herring <robh@kernel.org>, Krzysztof
 Kozlowski <krzk+dt@kernel.org>, Conor Dooley <conor+dt@kernel.org>, Liam
 Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Michael
 Hennerich <Michael.Hennerich@analog.com>, Marcelo Schmitt
 <marcelo.schmitt1@gmail.com>, Dimitri Fedrau <dima.fedrau@gmail.com>,
 Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH 0/2] add AD8460 DAC driver
Message-ID: <20240511172155.08bc0987@jic23-huawei>
In-Reply-To: <CAMknhBHd2XCJH4rgYDq=vbCL5E_tM3FxFPWbNy9PvxLCJL4tcA@mail.gmail.com>
References: <20240510064053.278257-1-Mariel.Tinaco@analog.com>
	<CAMknhBHd2XCJH4rgYDq=vbCL5E_tM3FxFPWbNy9PvxLCJL4tcA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 10 May 2024 12:30:46 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On Fri, May 10, 2024 at 1:42=E2=80=AFAM Mariel Tinaco <Mariel.Tinaco@anal=
og.com> wrote:
> >
> > The AD8460 is a 14-bit, high power +-40V 1A, high-speed DAC,
> > with dual digital input modes, programmable supply current and
> > fault monitoring and protection settings for output current,
> > output voltage and junction temperature.
> >
> > The fault monitoring and shutdown protection features were
> > supported in the earlier versions of the IIO driver but was
> > scrapped due to uncertainties if the functionalities belong to
> > the IIO driver. However, it would be best to implement it for
> > the device's quality of life. I'd like to know if it's better
> > suited as a stand-alone HWMON driver.

That probably doesn't make sense.  This reply btw is based on the
text here. I haven't yet looked in detail at the datasheet.

Some fault conditions are relatively easy to map to threshold events
on an input channel.  The ones that are harder are things
like short circuit detectors where it's hard to know what the
actual threshold is.

The other place we are limited is in multiple levels for the
same thing.  So warning and fault levels. That stuff is handled
much better by hwmon where these things are more common.
The issue we have is that the event encoding is a bit tight
but we could see if there is a way to add these.

> >
> > The following are the configurable and readable parameters
> > through SPI that could be implemented on the HWMON driver:
> >   * An enable bit to arm/protect the device on overcurrent,
> > overvoltage or overtemperature events. The device is shut down
> > upon detection.

We don't have a good way to handle restarting from shutdown, but
perhaps we could use another action to signal that - maybe even
going as far as saying that the driver should be reloaded.

As for the thresholds, they sound like the map to IIO events
reasonably well. =20

> >   * A configurable range/threshold for voltage, current and
> > temperature that raises alarm when exceeded while the device is
> > armed.

That maps fine to the IIO event threshold controls.

> >   * Flags that can be polled to raise alarm upon detection of
> > overcurrent, overvoltage or overtemperature events, and apply
> > additional protective measures.
The specific need to poll is awkward but you could do it easily
enough in driver and use the IIO event stuff to signal any
events detected.


> >   * Programmable quiescent current (optional)
Could probably figure out a suitable control for this, but I'm not
entirely sure what it is :)

> >   * Thermal monitoring is done by measuring voltage on TMP pin
> > (unlikely to be included)

If you did want to, the usual trick for these is to include
an optional use as a consumer of an IIO provider which would be
a separate ADC.=20

> > =20
>=20
> Adding myself to the cc: here since I'm interested to see what
> Jonathan (or anyone else) has to say about the fault monitoring.

Jonathan