Re: [PATCH v2 2/7] iio: adc: Add ti-ads1262 driver

[Jonathan Cameron]

On Mon, 29 Jun 2026 09:38:13 -0500
David Lechner <dlechner@xxxxxxxxxxxx> wrote:

> On 6/28/26 3:00 PM, Kurt Borja wrote:
> > On Sun Jun 28, 2026 at 12:15 PM -05, David Lechner wrote:  
> >> On 6/28/26 12:36 AM, Kurt Borja wrote:  
> >>> Add the ti-ads1262 driver with initial support for the primary ADC
> >>> (ADC1). The ADS1263 auxiliary ADC (ADC2) is handled by a separate driver
> >>> and interoperability considerations were taken into account.
> >>>  
> 
> ...
> 
> >>> +static int ads1262_read_raw(struct iio_dev *indio_dev,
> >>> +			    struct iio_chan_spec const *chan, int *val,
> >>> +			    int *val2, long mask)
> >>> +{
> >>> +	struct ads1262 *st = iio_priv(indio_dev);
> >>> +	struct ads1262_channel *chan_data = &st->channels[chan->scan_index];
> >>> +	u8 realbits = chan->scan_type.realbits;
> >>> +	__be32 raw;
> >>> +	int ret;
> >>> +
> >>> +	switch (mask) {
> >>> +	case IIO_CHAN_INFO_RAW:
> >>> +		ret = ads1262_channel_read(st, chan_data, &raw);
> >>> +		if (ret)
> >>> +			return ret;
> >>> +		*val = sign_extend32(be32_to_cpu(raw), realbits - 1);
> >>> +
> >>> +		return IIO_VAL_INT;
> >>> +
> >>> +	case IIO_CHAN_INFO_SCALE: {
> >>> +		guard(mutex)(&st->chan_lock);
> >>> +
> >>> +		ret = ads1262_channel_get_scale(st, chan, val, val2);
> >>> +		if (ret)
> >>> +			return ret;
> >>> +
> >>> +		return IIO_VAL_INT_PLUS_NANO;
> >>> +	}
> >>> +
> >>> +	case IIO_CHAN_INFO_HARDWAREGAIN: {  
> >>
> >> There is only one other ADC that uses "hardwaregain". Usually, we just make
> >> scale writeable to control the gain. I don't remember what the rules for
> >> that attribute are. Using it for in_voltage is not documented in the ABI.  
> > 
> > I went with hardwaregain because the scale loses too many significant
> > digits at high gain. With the internal reference and gain = 1, the scale
> > is at 0.000001164; then at gain = 32, the scale is at 0.000000036.
> > 
> > In this case I expect users to just calculate the scale themselves based
> > on the hardwaregain. Is this acceptable? If not I'll go with
> > scale_available.  
> 
> I'm pretty sure there is a series floating around that has proposed
> adding new fixed-point IIO_VAL_* types that could be another solution.
> We'll see what Jonathan says about this too.

Yup. That series should allow for easy representation of very small values.

It's in my testing branch already (see iio.git on kernel.org)
and IIO_VAL_DECIMAL64_PICO for most extreme case.

HARDWAREGAIN doesn't seem appropriate here, so please do the really
small scales instead.

Thanks,

Jonathan