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

[Kurt Borja]

On Mon Jun 29, 2026 at 7:32 PM -05, Jonathan Cameron wrote:
> 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.

IIO_VAL_DECIMAL64_PICO is just what I needed. I'll go for that, thanks!

>
> Thanks,
>
> Jonathan

-- 
Thanks,
 ~ Kurt