RE: [PATCH 0/2] add AD8460 DAC driver

Tinaco, Mariel
2024-07-07T23:30:27Z

> -----Original Message-----
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Saturday, June 29, 2024 2:40 AM
> To: Tinaco, Mariel <Mariel.Tinaco@analog.com>
> Cc: David Lechner <dlechner@baylibre.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>; Hennerich,
> Michael <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
>
> [External]
>
>
> > >
> > > > > * Programmable quiescent current (optional)
> > > Could probably figure out a suitable control for this, but I'm not
> > > entirely sure what it is :)
> >
> > Thinking about it, wouldn't the raw attribute be a suitable control
> > for this? This Value is relative to nominal supply current and acts as a
> "monotonic but nonlinear"
> > multiplier.
> > A register value maps to a current level from 0 to 2 times the nominal
> > current supplied. I also thought that it could be hardware gain but
> > the gain computation wasn't explicitly indicated in the datasheet and
> > there is not yet "current_hardwaregain" attribute available in the ABI. So I
> settled with raw.
>
> I don't entirely understand what is actually for, but a raw current output might
> be appropriate.
>
> >I
> > Think there would only be an issue of we expose the "processed"
> >attribute Because it has a particular computation. But I'm not
> >planning to expose the Processed attribute
>
> Is there any reason someone might in future though?

They would have to measure the supply current to see the effect of
This attribute, then that would be the "processed" value. I don't think
that would be necessary

>
> >
> > > > > * 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.
> >
> > I included this in my current revision, thanks for the idea. Although
> > the optional use Isn’t yet available in the consumer API. My question
> > is, in case the ADC channel to read The TMP pin is not available,
> > should I still make the temp raw value available and Set to 0? Or
> > should the temp raw attribute be unavailable or unlisted completely from IIO
> Info.
> If no ADC channel then remove it from the chan_spec. That probably means you
> need separate arrays of struct iio_chan_spec for the two case.
>
> Jonathan
>
> > > > >
> > > >
> > > > 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