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

Jonathan Cameron
2024-06-28T18:40:04Z

> >
> > > > * 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?

>
> > > > * 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