On Fri, 08 Jul 2022 12:35:19 +0200
Nuno Sá <noname.nuno@xxxxxxxxx> wrote:
> On Fri, 2022-07-08 at 11:28 +0200, Lars-Peter Clausen wrote:
> > On 7/8/22 10:02, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > the ADS7950 has a register bit (called TI_ADS7950_CR_RANGE_5V in
> > > the
> > > driver) that selects the input range. Depending on that bit the
> > > input
> > > range is either [0 .. V_{REF}] or [0 .. 2 * V_{REF}].
> > >
> > > The driver currently defaults to setting that bit, so the range is
> > > the
> > > big one.
> > >
> > > On a machine here however I know the input is in the smaller range
> > > and
> > > I'd like to benefit from the higher resolution of the small range.
> > > I
> > > wonder how to make this tunable. Should that be done using a
> > > firmware
> > > property? ("single-input-range" vs. "double-input-range"? Or input-
> > > range
> > > = <1> vs. input-range = <2> which better matches the data sheet
> > > that
> > > calls the two modes "Range 1 (0 to V_{REF})" and "Range 2 (0 to
> > > 2xV_{REF})") Or should this be made tunable via sysfs? (E.g. by
> > > writing
> > > to the scale property? Or a separate property?)
> >
> > Hi,
> >
> > Its a bit of a tricky one. You can find arguments for and against
> > either. Like "devicetree is for hardware description and not
> > application
> > specific configuration data", or "I know which setting I want to use,
> > having the kernel apply it makes it a lot easier".
> >
> > What we've done in the past in the IIO framework is to make the scale
> > property writable for such devices. Together with a scale_available
> > property to list valid options. This is the most flexible option as
> > it
> > allows to change the setting at runtime for applications where it is
> > required.
> >
>
> Yes, it's a tricky one and I have the feeling that thoughts about this
> are changing frequently :).
>
> Well, this feels identical to what I had in a DAC [1] I recently
> upstreamed. IIRC, on the first version of the series or during
> discussion on the RFC I also had in mind to make it configurable
> through sysfs but Jonathan advised me to go with a fw property.
DACs sometimes have a safety issue (you can fry boards if you set them wrong
and it's not unheard of for designers to make them safe for only a particular
range on a multirange DAC).
Assuming this ADC is sensible that shouldn't be the case here... (famous
last words ;)
Jonathan
>
> [1]:https://elixir.bootlin.com/linux/latest/source/drivers/iio/dac/ltc2688.c#L786
>
> - Nuno Sá
