Re: [PATCH v2 2/5] iio: add processed write API

[Romain Gantois <romain.gantois@bootlin.com>]

[-- Attachment #1: Type: text/plain, Size: 2656 bytes --]

On Wednesday, 1 October 2025 12:03:21 CEST David Lechner wrote:
> On Wed, Oct 1, 2025 at 9:19 AM Romain Gantois <romain.gantois@bootlin.com>
> 
...
> > > > +           case IIO_VAL_INT_PLUS_MICRO:
> > > > +           case IIO_VAL_INT_PLUS_NANO:
> > > > +                   break;
> > > > +           case IIO_VAL_FRACTIONAL:
> > > > +                   offset_val /= offset_val2;
> > > > +                   break;
> > > > +           case IIO_VAL_FRACTIONAL_LOG2:
> > > > +                   offset_val >>= offset_val2;
> > > > +                   break;
> > > > +           default:
> > > > +                   return -EINVAL;
> > > > +           }
> > > > +
> > > > +           *raw -= offset_val;
> > > > +   }
> > > 
> > > There are some rounding biases in this function, but I'm not sure if
> > > it is worth trying to make a perfectly fair function.
> > 
> > I'm unfamiliar with the notion of rounding bias, does it mean that nested
> > calls of this function would tend to amplify rounding errors? In this
> > case,
> > would rounding to the nearest integer instead of whatever is being done by
> > the
> > integer division here be a good solution?
> 
> In this case, the issue is when you are taking multiple samples. When you
> look at the average of all of the samples, you will be able to see the
> bias. For example, in one of the drivers I was looking at there is an
> offset of xxxx.6. Since the IIO_VAL_INT_PLUS_MICRO case is just dropping
> any fractional part, the raw value will be on average 0.6 lsb lower that
> the requested value. This could be a problem in an application where high
> precision is required. But probably not noticeable in cases where 1 lsb is
> less than the noise level.
> 

Thanks a lot for the detailed explanation. For the IIO_VAL_INT_PLUS_MICRO/NANO 
cases, I think that scaling by MICRO/NANO, then subtracting the offset, then 
dividing and rounding to the closest would give a small precision improvement 
in some cases. It would be a bit slower though, but for low sample-rate 
devices like the ones in IIO I don't think it would be noticeable. I'll give 
it a try.

> The floor division for IIO_VAL_FRACTIONAL creates a similar bias.
> DIV_ROUND_CLOSEST can help there, but even that has a small bias because
> values of exactly 0.5 always get rounded in the same direction. That kind
> of bias is much smaller though, so easier to ignore.
> 

DIV_ROUND_CLOSEST would indeed reduce the bias at no substantial cost, 
so I think I'll go with that.

Thanks,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]