On 2021-05-31 15:36, Liam Beguin wrote: > Hi Peter, > > On Mon May 31, 2021 at 4:52 AM EDT, Peter Rosin wrote: >> Hi! >> >> Thanks for the patch! >> >> On 2021-05-30 02:59, Liam Beguin wrote: >>> From: Liam Beguin <lvb@xxxxxxxxxx> >>> >>> This is a preparatory change required for the addition of temperature >>> sensing front ends. >> >> I think this is too simplistic. I think that if the upstream iio-dev has >> an offset, it should be dealt with (i.e. be rescaled). The rescale >> driver >> cannot ignore such an upstream offset and then throw in some other >> unrelated offset of its own. That would be thoroughly confusing. > > I'm not sure I fully understand. The upstream offset should be dealt > with when calling iio_read_channel_processed(). That was my main > motivation behind using the IIO core to get a processed value. You can rescale a channel with an offset, but without using processed values. I.e. the upstream channel provides raw values, a scale and an offset. The current rescale code ignores the upstream offset. I did not need that when I created the driver, and at a glace it felt "difficult". So I punted. But if the rescaler is going to start to handle offsets of any kind, it will get very confusing if the upstream offset is ignored. The proper way to do that is not something I have thought deeply about, and I don't know what the proper behavior is. For a processed channel, the offset is baked into the value that is scaled. Maybe the sane thing is to do that for a non-processed channel as well? But that gets a bit ugly, as it is counter to the simplicity, beauty and efficiency of the rescaler driver. In the non-processed case the driver is just adjusting the scale value. But since we are talking about proportional relationships, it should be possible to rescale a non-processed channel with an offset by just adjusting the offset in some way related to the rescale factor. Doing it with integer math is the "difficult" part... Cheers, Peter
