On Wed, Aug 9, 2023 at 3:48 PM Mighty bavishimithil@gmail.com wrote:

...

The current code "mostly works" because we have not run into systems supporting only raw but not scale or only scale but not raw, and I doubt there are few using the rescaler on anything such, but let's fix the logic.

This does break the logic for twl6030/6032 boards as the seem to only have only raw and processed masks[1]. What would a probable solution for it be, to modify the twl gpadc to include scale+raw or just revert back to the OR?

[1] https://github.com/torvalds/linux/blob/master/drivers/iio/adc/twl6030-gpadc....

How does it break it?

It's a change to the AFE rescaler driver so it can't really "break" twl6030-gpadc.

Isn't the complete picture involving some device tree using the prescaler etc?

Can you try to dig out that so we can see the whole situation?

Yours, Linus Walleij

On Mon, Aug 21, 2023 at 6:45 PM Mighty bavishimithil@gmail.com wrote:

...

How does it break it?

It's a change to the AFE rescaler driver so it can't really "break" twl6030-gpadc.

Not necessarily the gpadc, but it breaks my current-sense-shunt which requires an adc channel for it to work, since the iio-rescale driver wont recognise the channel (as it only is IIO_CHAN_INFO_RAW, so the && breaks)

OK so twl6030 is providing some channels with IIO_CHAN_INFO_RAW without IIO_CHAN_INFO_SCALE.

How is the rescaler supposed to rescale the raw value without any scale?

Say the raw value is 100, then 100 what? Microvolts? Certainly the twl6030 has to provide a scale or a processed channel to be used with the rescaler. If the rescaler would assume "no scale means scale 1:1" then that is equivalent to a processed channel, and you can just patch the twl6030 driver to convert all IIO_CHAN_INFO_RAW to IIO_CHAN_INFO_PROCESSED.

Either the datasheet has the right scale for the channels, or it is something design (board) specific and then it should be a parameter to the driver e.g. through the device tree or similar mechanism.

Yours, Linus Walleij

On Thu, Aug 24, 2023 at 9:39 AM Mighty bavishimithil@gmail.com wrote:

...

patch the twl6030 driver to convert all IIO_CHAN_INFO_RAW to IIO_CHAN_INFO_PROCESSED.

That would break the case here https://github.com/torvalds/linux/blob/master/drivers/iio/adc/twl6030-gpadc.... hence I think we just comply to adding scale as well, even though it would be 1:1?

Seems reasonable to me!

There is this https://github.com/torvalds/linux/blob/master/drivers/iio/adc/twl6030-gpadc.... but I'm not very sure about how it changes the scale.

That looks like the channel is actually processed, not raw, right? i.e. that should only be done on channels marked as processed.

This should definitely be reflected in the scale attribute for the raw channel instead, especially if you support buffered reads (I don't know if the driver does this) because buffered reads usually just read out the values from the hardware without any such processing and rely on scale to correct them in userspace afterwards.

Yours, Linus Walleij

On Thu, 24 Aug 2023 10:28:01 +0200 Linus Walleij linus.walleij@linaro.org wrote:

On Thu, Aug 24, 2023 at 10:24 AM Linus Walleij linus.walleij@linaro.org wrote:

...

This should definitely be reflected in the scale attribute for the raw channel instead,

Actually both IIO_CHAN_INFO_SCALE and IIO_CHAN_INFO_OFFSET as it looks.

I usually use tools/iio/iio_generic_buffer.c to test the result after applied scale and offset as it takes those into account.

Yours, Linus Walleij

Not 100% the follow is relevant as I've lost track of the discussion but maybe it is useful.

Worth noting there are a few reasons why RAW and PROCESSED can coexist in drivers and indeed why SCALE can be absent.. (OFFSET is much the same)

1) If SCALE = 1.0 the driver is allowed not to provide it - the channel might still be raw if OFFSET != 0 2) If the channel has a horrible non linear and none invertable conversion to standard units and events support the you might need PROCESSED to provide the useful value, but RAW to give you clue what the current value is for setting an event (light sensors are usual place we see this). 3) Historical ABI errors. If we first had RAW and no scale or offset because we had no known values for them. Then later we discovered that there was a non linear transform involved (often when someone found a magic calibration code somewhere). Given the RAW interface might be in use and isn't a bug as such, we can't easily remove it. The new PROCESSED interface needs to be there because of the non linear transform..

Odd corner cases... In this particular case the original code made no sense but might have allowed for case 3 by accident?

Jonathan

On Tue, 29 Aug 2023 09:17:00 +0200 Linus Walleij linus.walleij@linaro.org wrote:

On Mon, Aug 28, 2023 at 8:18 PM Jonathan Cameron jic23@kernel.org wrote:

...

Not 100% the follow is relevant as I've lost track of the discussion but maybe it is useful.

Worth noting there are a few reasons why RAW and PROCESSED can coexist in drivers and indeed why SCALE can be absent.. (OFFSET is much the same)

That's fine. If we have PROCESSED the rescaler will use that first.

What we're discussing are channels that have just RAW and no PROCESSED, nor SCALE or OFFSET yet are connected to a rescaler.

...

1. If SCALE = 1.0 the driver is allowed not to provide it - the channel might still be raw if OFFSET != 0

I'm not so sure the rescaler can handle that though. Just no-one ran into it yet...

...

2. If the channel has a horrible non linear and none invertable conversion to standard units and events support the you might need PROCESSED to provide the useful value, but RAW to give you clue what the current value is for setting an event (light sensors are usual place we see this).

3. Historical ABI errors. If we first had RAW and no scale or offset because we had no known values for them. Then later we discovered that there was a non linear transform involved (often when someone found a magic calibration code somewhere). Given the RAW interface might be in use and isn't a bug as such, we can't easily remove it. The new PROCESSED interface needs to be there because of the non linear transform..

Odd corner cases... In this particular case the original code made no sense but might have allowed for case 3 by accident?

I think it's fine, we make PROCESSED take precedence in all cases as long as SCALE is not there as well.

rescale_configure_channel() does this:

    if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) &&
        iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE)) {
            dev_info(dev, "using raw+scale source channel\n");
    } else if (iio_channel_has_info(schan, IIO_CHAN_INFO_PROCESSED)) {
            dev_info(dev, "using processed channel\n");
            rescale->chan_processed = true;
    } else {
            dev_err(dev, "source channel is not supported\n");
            return -EINVAL;
    }

I think the first line should be

if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) && (iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE || iio_channel_has_info(schan,IIO_CHAN_INFO_OFFSET)))

right? We just never ran into it.

Makes sense to me.

Jonathan

Yours, Linus Walleij

On Mon, Aug 28, 2023 at 11:48 PM Jonathan Cameron jic23@kernel.org wrote:

2. If the channel has a horrible non linear and none invertable conversion to standard units and events support the you might need PROCESSED to provide the useful value, but RAW to give you clue what the current value is for setting an event (light sensors are usual place we see this).

In this very specific case yes, it is being used as a current sense shunt for a light+prox sensor (gp2ap002), so I do think that it might be case 2 instead of 3. But with no other devices using the twl6030/32 gpadc for any features it could also be due to it not being updated like case 3. Also the fact that the adc would break in cases when its not just a light sensor as well, we just dont have any such devices yet. I'm pretty lost at how the code handles RAW and PROCESSED anyways, cant seem to find a proper rescaler. Ideally BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE) should be there in it, but since SCALE isnt used anywhere in the driver it wouldnt break any functionality, but it would lose logic. We'd have to look into the working of the gpadc again to understand how the factors fit in there.

Regards, Mithil

On Sun, Sep 3, 2023 at 8:04 PM Mighty bavishimithil@gmail.com wrote:

On Mon, Aug 28, 2023 at 11:48 PM Jonathan Cameron jic23@kernel.org wrote:

...

2. If the channel has a horrible non linear and none invertable conversion to standard units and events support the you might need PROCESSED to provide the useful value, but RAW to give you clue what the current value is for setting an event (light sensors are usual place we see this).

In this very specific case yes, it is being used as a current sense shunt for a light+prox sensor (gp2ap002), so I do think that it might be case 2 instead of 3. But with no other devices using the twl6030/32 gpadc for any features it could also be due to it not being updated like case 3.

See if my patch fixes the issue for you, else we need to patch twl6030 as indicated.

Also the fact that the adc would break in cases when its not just a light sensor as well, we just dont have any such devices yet.

I have tested the gp2ap002 both with and without light sensor. They have different product numbers and thus different device tree compatibles if the component supports light sensoring and not just proximity detection, see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docu... So just use the right compatible (if you're using device tree) and it'll be fine.

Yours, Linus Walleij