2021-03-06 23:55:13

by Evgeny Boger

[permalink] [raw]
Subject: [PATCH] iio: adc: axp20x_adc: fix charging current reporting on AXP22x

Both the charging and discharging currents on AXP22x are stored as
12-bit integers, in accordance with the datasheet.
It's also confirmed by vendor BSP (axp20x_adc.c:axp22_icharge_to_mA).

The scale factor of 0.5 is never mentioned in datasheet, nor in the
vendor source code. I think it was here to compensate for
erroneous additional bit in register width.

Tested on custom A40i+AXP221s board with external ammeter as
a reference.

Signed-off-by: Evgeny Boger <[email protected]>
---
drivers/iio/adc/axp20x_adc.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
index 3e0c0233b431..8db6699c20c3 100644
--- a/drivers/iio/adc/axp20x_adc.c
+++ b/drivers/iio/adc/axp20x_adc.c
@@ -253,17 +253,7 @@ static int axp22x_adc_raw(struct iio_dev *indio_dev,
struct axp20x_adc_iio *info = iio_priv(indio_dev);
int size;

- /*
- * N.B.: Unlike the Chinese datasheets tell, the charging current is
- * stored on 12 bits, not 13 bits. Only discharging current is on 13
- * bits.
- */
- if (chan->type == IIO_CURRENT && chan->channel == AXP22X_BATT_DISCHRG_I)
- size = 13;
- else
- size = 12;
-
- *val = axp20x_read_variable_width(info->regmap, chan->address, size);
+ *val = axp20x_read_variable_width(info->regmap, chan->address, 12);
if (*val < 0)
return *val;

@@ -387,7 +377,7 @@ static int axp22x_adc_scale(struct iio_chan_spec const *chan, int *val,

case IIO_CURRENT:
*val = 0;
- *val2 = 500000;
+ *val2 = 1000000;
return IIO_VAL_INT_PLUS_MICRO;

case IIO_TEMP:
--
2.17.1


2021-03-07 14:19:42

by Jonathan Cameron

[permalink] [raw]
Subject: Re: [PATCH] iio: adc: axp20x_adc: fix charging current reporting on AXP22x

On Sun, 7 Mar 2021 02:52:38 +0300
Evgeny Boger <[email protected]> wrote:

> Both the charging and discharging currents on AXP22x are stored as
> 12-bit integers, in accordance with the datasheet.
> It's also confirmed by vendor BSP (axp20x_adc.c:axp22_icharge_to_mA).
>
> The scale factor of 0.5 is never mentioned in datasheet, nor in the
> vendor source code. I think it was here to compensate for
> erroneous additional bit in register width.
>
> Tested on custom A40i+AXP221s board with external ammeter as
> a reference.
>
> Signed-off-by: Evgeny Boger <[email protected]>

+CC Quentin's bootlin address.

One comment inline,

Jonathan

> ---
> drivers/iio/adc/axp20x_adc.c | 14 ++------------
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> index 3e0c0233b431..8db6699c20c3 100644
> --- a/drivers/iio/adc/axp20x_adc.c
> +++ b/drivers/iio/adc/axp20x_adc.c
> @@ -253,17 +253,7 @@ static int axp22x_adc_raw(struct iio_dev *indio_dev,
> struct axp20x_adc_iio *info = iio_priv(indio_dev);
> int size;
>
> - /*
> - * N.B.: Unlike the Chinese datasheets tell, the charging current is
> - * stored on 12 bits, not 13 bits. Only discharging current is on 13
> - * bits.
> - */
> - if (chan->type == IIO_CURRENT && chan->channel == AXP22X_BATT_DISCHRG_I)
> - size = 13;
> - else
> - size = 12;
> -
> - *val = axp20x_read_variable_width(info->regmap, chan->address, size);
> + *val = axp20x_read_variable_width(info->regmap, chan->address, 12);
> if (*val < 0)
> return *val;
>
> @@ -387,7 +377,7 @@ static int axp22x_adc_scale(struct iio_chan_spec const *chan, int *val,
>
> case IIO_CURRENT:
> *val = 0;
> - *val2 = 500000;
> + *val2 = 1000000;
> return IIO_VAL_INT_PLUS_MICRO;
*val = 1;
return IIO_VAL_INT;

Should work if the scale factor is 1.
Note that we could just have reported the channel as _processed in the first place, but
given we didn't better to keep the ABI the same and just have a noop scale factor.

>
> case IIO_TEMP: