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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux