On Mon May 31, 2021 at 10:08 AM EDT, Peter Rosin wrote:

On 2021-05-31 15:36, Liam Beguin wrote:

quoted

Hi Peter,

On Mon May 31, 2021 at 4:52 AM EDT, Peter Rosin wrote:

quoted

Hi!

Thanks for the patch!

On 2021-05-30 02:59, Liam Beguin wrote:

quoted

From: Liam Beguin <redacted>

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.

I understand what you meant now.

At first, I tried to apply the upstream offset from inside the rescaler.
As you said it felt difficult and it felt like this must've been
implemented somewhere else before.

After looking around, I noticed that the code to do that was already
part of inkern.c and exposed through iio_read_channel_processed().
If the upstream channel doesn't provide a processed value, the upstream
offset and scale are automatically applied.

So with the changes in [3/9] the rescaler's raw value becomes the
upstream channel's processed value.

This seems like an easier and probably cleaner way of adding offset
support in the rescaler.

Does that make sense?

Cheers,
Liam

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