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

[Jonathan Cameron <jic23@kernel.org>]

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