Re: [PATCH 2/2 v2] iio: magnetometer: ak8974: Provide scaling

[Stephan Gerhold <stephan@gerhold.net>]

Hi Linus,

On Thu, Apr 16, 2020 at 04:09:17PM +0200, Linus Walleij wrote:
> The manual for the HSCDTD008A gives us a scaling for the
> three axis as +/- 2.4mT per axis.
> 

I wonder if we can really assume that this applies to
the other models (e.g. AK8974) as well?

> When I implement this the biggest axis indicates 0.59 Gauss
> which is a reasonable measurement for the earths magnetic
> which is in the range of 0.25 to 0.65 Gauss on the surface
> according to Wikipedia.
> 
> Cc: Nick Reitemeyer <nick.reitemeyer@web.de>
> Cc: Stephan Gerhold <stephan@gerhold.net>
> Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Split out the measurement refactoring.
> ---
>  drivers/iio/magnetometer/ak8974.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/magnetometer/ak8974.c b/drivers/iio/magnetometer/ak8974.c
> index 5361647b9054..effcdd93e650 100644
> --- a/drivers/iio/magnetometer/ak8974.c
> +++ b/drivers/iio/magnetometer/ak8974.c
> @@ -603,6 +603,18 @@ static int ak8974_read_raw(struct iio_dev *indio_dev,
>  		*val = outval;
>  		ret = IIO_VAL_INT;
>  		break;
> +	case IIO_CHAN_INFO_SCALE:
> +		/*
> +		 * The datasheet for HSCDTF008A, page 3 specifies the
> +		 * range of the sensor as +/- 2.4 mT per axis, which corresponds
> +		 * to +/- 2400 uT = +/- 24 Gauss. So 0x7fff is 24 Gauss and
> +		 * 0xffff is -24 Gauss. To account for the one missing value if
> +		 * we multiply by 1/S16_MAX, instead multiply with 2/U16_MAX.
> +		 */

I just want to note that (according to the datasheet), HSCDTD008A
produces either 14-bit or 15-bit measurements (depending on
the HSCDTD008A_CTRL4_RANGE bit that we set by default).

I think this isn't exposed correctly in the AK8974_AXIS_CHANNEL() macro
(realbits is 16 instead of 15), so this might need special casing for
hscdt008a?

The reason I mention this is because I think it would also affect the
scaling that you implement here. With 15-bit output it produces values
from +16383 (0x3fff) (= 2.4 mT?) to -16384 (0xc000) (= -2.4 mT?).

So it would never reach the 0x7fff and 0xffff you mention
in your comment.

> +		*val = 24 * 2;
> +		*val2 = U16_MAX;
> +		ret = IIO_VAL_FRACTIONAL;
> +		break;
>  	}
>  out_err_read:
>  	return ret;
> @@ -667,7 +679,8 @@ static const struct iio_chan_spec_ext_info ak8974_ext_info[] = {
>  		.type = IIO_MAGN,					\
>  		.modified = 1,						\
>  		.channel2 = IIO_MOD_##axis,				\
> -		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),		\
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |		\
> +			BIT(IIO_CHAN_INFO_SCALE),			\
>  		.ext_info = ak8974_ext_info,				\
>  		.address = index,					\
>  		.scan_index = index,					\
> -- 
> 2.21.1
>