> -----Original Message----- > From: Jonathan Cameron <jic23@xxxxxxxxxx> > Sent: Saturday, June 29, 2024 2:40 AM > To: Tinaco, Mariel <Mariel.Tinaco@xxxxxxxxxx> > Cc: David Lechner <dlechner@xxxxxxxxxxxx>; linux-iio@xxxxxxxxxxxxxxx; > devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Lars-Peter Clausen > <lars@xxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski > <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Liam Girdwood > <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>; Hennerich, > Michael <Michael.Hennerich@xxxxxxxxxx>; Marcelo Schmitt > <marcelo.schmitt1@xxxxxxxxx>; Dimitri Fedrau <dima.fedrau@xxxxxxxxx>; > Guenter Roeck <linux@xxxxxxxxxxxx> > 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
