The IIO ABI mandates acceleration values from accelerometer to be
emitted in m/s^2. The KX022A was emitting values in micro m/s^2.
Fix driver to report the correct scale values.
Signed-off-by: Matti Vaittinen <[email protected]>
Reported-by: Jagath Jog J <[email protected]>
Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer")
---
The fix is somewhat crude and just crops the last 3 digits (rounds) of the
scale while using IIO_VAL_INT_PLUS_NANO. I played with a thought of using
IIO_VAL_FRACTIONAL, which could have modelled the computation
G_range * g * scaling / (2^16 * scaling) - where scaling 10000 would
have allowed using g value 980665.
This would have worked fine for reporting scale and available scales -
but would be somewhat tricky when converting the user-supplied scale to
register values in write_raw().
Well, the g varies from 9.832 (poles) to 9.780 (equator) according to
some website - no proper source check done but this sounds about right -
so maybe the loss of accuracy is acceptable.
I did only very quick testing on KX022A and iio_generic_buffer. After
the patch the values seemed to be correct order of magnitude. Further
testing is appreciated :)
---
drivers/iio/accel/kionix-kx022a.c | 37 ++++++++++++++++++++++---------
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
index 4ea3c6718ed4..971fc60efef0 100644
--- a/drivers/iio/accel/kionix-kx022a.c
+++ b/drivers/iio/accel/kionix-kx022a.c
@@ -273,17 +273,17 @@ static const unsigned int kx022a_odrs[] = {
* (range / 2^bits) * g = (range / 2^bits) * 9.80665 m/s^2
* => KX022A uses 16 bit (HiRes mode - assume the low 8 bits are zeroed
* in low-power mode(?) )
- * => +/-2G => 4 / 2^16 * 9,80665 * 10^6 (to scale to micro)
- * => +/-2G - 598.550415
- * +/-4G - 1197.10083
- * +/-8G - 2394.20166
- * +/-16G - 4788.40332
+ * => +/-2G => 4 / 2^16 * 9,80665
+ * => +/-2G - 0.000598550415
+ * +/-4G - 0.00119710083
+ * +/-8G - 0.00239420166
+ * +/-16G - 0.00478840332
*/
static const int kx022a_scale_table[][2] = {
- { 598, 550415 },
- { 1197, 100830 },
- { 2394, 201660 },
- { 4788, 403320 },
+ { 0, 598550 },
+ { 0, 1197101 },
+ { 0, 2394202 },
+ { 0, 4788403 },
};
static int kx022a_read_avail(struct iio_dev *indio_dev,
@@ -302,7 +302,7 @@ static int kx022a_read_avail(struct iio_dev *indio_dev,
*vals = (const int *)kx022a_scale_table;
*length = ARRAY_SIZE(kx022a_scale_table) *
ARRAY_SIZE(kx022a_scale_table[0]);
- *type = IIO_VAL_INT_PLUS_MICRO;
+ *type = IIO_VAL_INT_PLUS_NANO;
return IIO_AVAIL_LIST;
default:
return -EINVAL;
@@ -366,6 +366,20 @@ static int kx022a_turn_on_unlock(struct kx022a_data *data)
return ret;
}
+static int kx022a_write_raw_get_fmt(struct iio_dev *idev,
+ struct iio_chan_spec const *chan,
+ long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ return IIO_VAL_INT_PLUS_NANO;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ return -EINVAL;
+ }
+}
+
static int kx022a_write_raw(struct iio_dev *idev,
struct iio_chan_spec const *chan,
int val, int val2, long mask)
@@ -510,7 +524,7 @@ static int kx022a_read_raw(struct iio_dev *idev,
kx022a_reg2scale(regval, val, val2);
- return IIO_VAL_INT_PLUS_MICRO;
+ return IIO_VAL_INT_PLUS_NANO;
}
return -EINVAL;
@@ -712,6 +726,7 @@ static int kx022a_fifo_flush(struct iio_dev *idev, unsigned int samples)
static const struct iio_info kx022a_info = {
.read_raw = &kx022a_read_raw,
.write_raw = &kx022a_write_raw,
+ .write_raw_get_fmt = &kx022a_write_raw_get_fmt,
.read_avail = &kx022a_read_avail,
.validate_trigger = iio_validate_own_trigger,
--
2.41.0
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
Hi Matti,
On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen
<[email protected]> wrote:
>
> The IIO ABI mandates acceleration values from accelerometer to be
> emitted in m/s^2. The KX022A was emitting values in micro m/s^2.
>
> Fix driver to report the correct scale values.
>
> Signed-off-by: Matti Vaittinen <[email protected]>
> Reported-by: Jagath Jog J <[email protected]>
> Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer")
>
> ---
> The fix is somewhat crude and just crops the last 3 digits (rounds) of the
> scale while using IIO_VAL_INT_PLUS_NANO. I played with a thought of using
> IIO_VAL_FRACTIONAL, which could have modelled the computation
> G_range * g * scaling / (2^16 * scaling) - where scaling 10000 would
> have allowed using g value 980665.
>
> This would have worked fine for reporting scale and available scales -
> but would be somewhat tricky when converting the user-supplied scale to
> register values in write_raw().
>
> Well, the g varies from 9.832 (poles) to 9.780 (equator) according to
> some website - no proper source check done but this sounds about right -
> so maybe the loss of accuracy is acceptable.
>
> I did only very quick testing on KX022A and iio_generic_buffer. After
> the patch the values seemed to be correct order of magnitude. Further
> testing is appreciated :)
Values are correct with this change, Thank you for fixing.
Tested-by: Jagath Jog J <[email protected]>
Regards
Jagath
>
> ---
> drivers/iio/accel/kionix-kx022a.c | 37 ++++++++++++++++++++++---------
> 1 file changed, 26 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
> index 4ea3c6718ed4..971fc60efef0 100644
> --- a/drivers/iio/accel/kionix-kx022a.c
> +++ b/drivers/iio/accel/kionix-kx022a.c
> @@ -273,17 +273,17 @@ static const unsigned int kx022a_odrs[] = {
> * (range / 2^bits) * g = (range / 2^bits) * 9.80665 m/s^2
> * => KX022A uses 16 bit (HiRes mode - assume the low 8 bits are zeroed
> * in low-power mode(?) )
> - * => +/-2G => 4 / 2^16 * 9,80665 * 10^6 (to scale to micro)
> - * => +/-2G - 598.550415
> - * +/-4G - 1197.10083
> - * +/-8G - 2394.20166
> - * +/-16G - 4788.40332
> + * => +/-2G => 4 / 2^16 * 9,80665
> + * => +/-2G - 0.000598550415
> + * +/-4G - 0.00119710083
> + * +/-8G - 0.00239420166
> + * +/-16G - 0.00478840332
> */
> static const int kx022a_scale_table[][2] = {
> - { 598, 550415 },
> - { 1197, 100830 },
> - { 2394, 201660 },
> - { 4788, 403320 },
> + { 0, 598550 },
> + { 0, 1197101 },
> + { 0, 2394202 },
> + { 0, 4788403 },
> };
>
> static int kx022a_read_avail(struct iio_dev *indio_dev,
> @@ -302,7 +302,7 @@ static int kx022a_read_avail(struct iio_dev *indio_dev,
> *vals = (const int *)kx022a_scale_table;
> *length = ARRAY_SIZE(kx022a_scale_table) *
> ARRAY_SIZE(kx022a_scale_table[0]);
> - *type = IIO_VAL_INT_PLUS_MICRO;
> + *type = IIO_VAL_INT_PLUS_NANO;
> return IIO_AVAIL_LIST;
> default:
> return -EINVAL;
> @@ -366,6 +366,20 @@ static int kx022a_turn_on_unlock(struct kx022a_data *data)
> return ret;
> }
>
> +static int kx022a_write_raw_get_fmt(struct iio_dev *idev,
> + struct iio_chan_spec const *chan,
> + long mask)
> +{
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + return IIO_VAL_INT_PLUS_NANO;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return IIO_VAL_INT_PLUS_MICRO;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> static int kx022a_write_raw(struct iio_dev *idev,
> struct iio_chan_spec const *chan,
> int val, int val2, long mask)
> @@ -510,7 +524,7 @@ static int kx022a_read_raw(struct iio_dev *idev,
>
> kx022a_reg2scale(regval, val, val2);
>
> - return IIO_VAL_INT_PLUS_MICRO;
> + return IIO_VAL_INT_PLUS_NANO;
> }
>
> return -EINVAL;
> @@ -712,6 +726,7 @@ static int kx022a_fifo_flush(struct iio_dev *idev, unsigned int samples)
> static const struct iio_info kx022a_info = {
> .read_raw = &kx022a_read_raw,
> .write_raw = &kx022a_write_raw,
> + .write_raw_get_fmt = &kx022a_write_raw_get_fmt,
> .read_avail = &kx022a_read_avail,
>
> .validate_trigger = iio_validate_own_trigger,
> --
> 2.41.0
>
>
> --
> Matti Vaittinen, Linux device drivers
> ROHM Semiconductors, Finland SWDC
> Kiviharjunlenkki 1E
> 90220 OULU
> FINLAND
>
> ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
> Simon says - in Latin please.
> ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
> Thanks to Simon Glass for the translation =]
On 10/19/23 21:21, Jagath Jog J wrote:
> Hi Matti,
>
> On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen
> <[email protected]> wrote:
>>
>> The IIO ABI mandates acceleration values from accelerometer to be
>> emitted in m/s^2. The KX022A was emitting values in micro m/s^2.
>>
>> Fix driver to report the correct scale values.
>>
>> Signed-off-by: Matti Vaittinen <[email protected]>
>> Reported-by: Jagath Jog J <[email protected]>
>> Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer")
>>
>> ---
>> The fix is somewhat crude and just crops the last 3 digits (rounds) of the
>> scale while using IIO_VAL_INT_PLUS_NANO. I played with a thought of using
>> IIO_VAL_FRACTIONAL, which could have modelled the computation
>> G_range * g * scaling / (2^16 * scaling) - where scaling 10000 would
>> have allowed using g value 980665.
>>
>> This would have worked fine for reporting scale and available scales -
>> but would be somewhat tricky when converting the user-supplied scale to
>> register values in write_raw().
>>
>> Well, the g varies from 9.832 (poles) to 9.780 (equator) according to
>> some website - no proper source check done but this sounds about right -
>> so maybe the loss of accuracy is acceptable.
>>
>> I did only very quick testing on KX022A and iio_generic_buffer. After
>> the patch the values seemed to be correct order of magnitude. Further
>> testing is appreciated :)
>
> Values are correct with this change, Thank you for fixing.
> Tested-by: Jagath Jog J <[email protected]>
Thanks a ton for testing! May I ask which component did you use (or did
you just use some 'simulated' regster values?)
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
On Fri, Oct 20, 2023 at 5:39 PM Matti Vaittinen
<[email protected]> wrote:
>
> On 10/19/23 21:21, Jagath Jog J wrote:
> > Hi Matti,
> >
> > On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen
> > <[email protected]> wrote:
> >>
> >> I did only very quick testing on KX022A and iio_generic_buffer. After
> >> the patch the values seemed to be correct order of magnitude. Further
> >> testing is appreciated :)
> >
> > Values are correct with this change, Thank you for fixing.
> > Tested-by: Jagath Jog J <[email protected]>
>
> Thanks a ton for testing! May I ask which component did you use (or did
> you just use some 'simulated' regster values?)
Hi Matti,
I just simulated with the register values, Should the 'tested-by' tag only be
provided after hardware testing? I referred to this driver because it's
the most recent accelerometer driver that was merged.
Regards
Jagath
On Thu, 19 Oct 2023 16:23:56 +0300
Matti Vaittinen <[email protected]> wrote:
> The IIO ABI mandates acceleration values from accelerometer to be
> emitted in m/s^2. The KX022A was emitting values in micro m/s^2.
>
> Fix driver to report the correct scale values.
>
> Signed-off-by: Matti Vaittinen <[email protected]>
> Reported-by: Jagath Jog J <[email protected]>
> Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer")
>
> ---
> The fix is somewhat crude and just crops the last 3 digits (rounds) of the
> scale while using IIO_VAL_INT_PLUS_NANO. I played with a thought of using
> IIO_VAL_FRACTIONAL, which could have modelled the computation
> G_range * g * scaling / (2^16 * scaling) - where scaling 10000 would
> have allowed using g value 980665.
>
> This would have worked fine for reporting scale and available scales -
> but would be somewhat tricky when converting the user-supplied scale to
> register values in write_raw().
>
> Well, the g varies from 9.832 (poles) to 9.780 (equator) according to
> some website - no proper source check done but this sounds about right -
> so maybe the loss of accuracy is acceptable.
MEMS accelerometers tend to be pretty inaccurate. So I'd not worry too much about
this loss of accuracy at all.
The 0 point according to the datasheet I just looked at is +- 25mg and
if I read the sensitivity numbers right part to part variation in scale
is well above 5%. For 2G mode, it lists acceptable 1G values of
min=15401, typical=16384, max=17367
So if anyone actually wants to do precision measurement they need to calibrate
their particular device + deal with the variation due to temperature etc
which makes this even more fun.
Applied to my local fixes-togreg branch of iio.git, but I've just sent a pull request
so this may not go out until after the 6.7 merge window.
Jonathan
>
> I did only very quick testing on KX022A and iio_generic_buffer. After
> the patch the values seemed to be correct order of magnitude. Further
> testing is appreciated :)
>
> ---
> drivers/iio/accel/kionix-kx022a.c | 37 ++++++++++++++++++++++---------
> 1 file changed, 26 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
> index 4ea3c6718ed4..971fc60efef0 100644
> --- a/drivers/iio/accel/kionix-kx022a.c
> +++ b/drivers/iio/accel/kionix-kx022a.c
> @@ -273,17 +273,17 @@ static const unsigned int kx022a_odrs[] = {
> * (range / 2^bits) * g = (range / 2^bits) * 9.80665 m/s^2
> * => KX022A uses 16 bit (HiRes mode - assume the low 8 bits are zeroed
> * in low-power mode(?) )
> - * => +/-2G => 4 / 2^16 * 9,80665 * 10^6 (to scale to micro)
> - * => +/-2G - 598.550415
> - * +/-4G - 1197.10083
> - * +/-8G - 2394.20166
> - * +/-16G - 4788.40332
> + * => +/-2G => 4 / 2^16 * 9,80665
> + * => +/-2G - 0.000598550415
> + * +/-4G - 0.00119710083
> + * +/-8G - 0.00239420166
> + * +/-16G - 0.00478840332
> */
> static const int kx022a_scale_table[][2] = {
> - { 598, 550415 },
> - { 1197, 100830 },
> - { 2394, 201660 },
> - { 4788, 403320 },
> + { 0, 598550 },
> + { 0, 1197101 },
> + { 0, 2394202 },
> + { 0, 4788403 },
> };
>
> static int kx022a_read_avail(struct iio_dev *indio_dev,
> @@ -302,7 +302,7 @@ static int kx022a_read_avail(struct iio_dev *indio_dev,
> *vals = (const int *)kx022a_scale_table;
> *length = ARRAY_SIZE(kx022a_scale_table) *
> ARRAY_SIZE(kx022a_scale_table[0]);
> - *type = IIO_VAL_INT_PLUS_MICRO;
> + *type = IIO_VAL_INT_PLUS_NANO;
> return IIO_AVAIL_LIST;
> default:
> return -EINVAL;
> @@ -366,6 +366,20 @@ static int kx022a_turn_on_unlock(struct kx022a_data *data)
> return ret;
> }
>
> +static int kx022a_write_raw_get_fmt(struct iio_dev *idev,
> + struct iio_chan_spec const *chan,
> + long mask)
> +{
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + return IIO_VAL_INT_PLUS_NANO;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return IIO_VAL_INT_PLUS_MICRO;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> static int kx022a_write_raw(struct iio_dev *idev,
> struct iio_chan_spec const *chan,
> int val, int val2, long mask)
> @@ -510,7 +524,7 @@ static int kx022a_read_raw(struct iio_dev *idev,
>
> kx022a_reg2scale(regval, val, val2);
>
> - return IIO_VAL_INT_PLUS_MICRO;
> + return IIO_VAL_INT_PLUS_NANO;
> }
>
> return -EINVAL;
> @@ -712,6 +726,7 @@ static int kx022a_fifo_flush(struct iio_dev *idev, unsigned int samples)
> static const struct iio_info kx022a_info = {
> .read_raw = &kx022a_read_raw,
> .write_raw = &kx022a_write_raw,
> + .write_raw_get_fmt = &kx022a_write_raw_get_fmt,
> .read_avail = &kx022a_read_avail,
>
> .validate_trigger = iio_validate_own_trigger,
On 10/20/23 19:48, Jagath Jog J wrote:
> On Fri, Oct 20, 2023 at 5:39 PM Matti Vaittinen
> <[email protected]> wrote:
>>
>> On 10/19/23 21:21, Jagath Jog J wrote:
>>> Hi Matti,
>>>
>>> On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen
>>> <[email protected]> wrote:
>>>>
>
>>>> I did only very quick testing on KX022A and iio_generic_buffer. After
>>>> the patch the values seemed to be correct order of magnitude. Further
>>>> testing is appreciated :)
>>>
>>> Values are correct with this change, Thank you for fixing.
>>> Tested-by: Jagath Jog J <[email protected]>
>>
>> Thanks a ton for testing! May I ask which component did you use (or did
>> you just use some 'simulated' regster values?)
>
> Hi Matti,
>
> I just simulated with the register values, Should the 'tested-by' tag only be
> provided after hardware testing?
I am not sure TBH. I didn't have a problem with your tag though, I was
merely curious to hear about the IC usage :)
Now that you mentioned the tested-by tag usage, I started to wonder it
as well. From pure SW/driver point of view the register value simulation
is sufficient - but in practice we are not interested in whether the
code works "in theory" - but whether the products do really work. This
is something which includes handling of potential HW quircks and
oddities - which are not always documented or known.
If we assume a case where someone is developing new gizmo and hits a bug
which is in reality caused by some undocumented HW hiccup - then fixes
with "tested-by" tags which are not actually tested on HW having this
hiccup but using SW simulation - may be misleading.
The above is just some overall pondering - I am not too concerned on
your tested-by tag :) Besides, it's cool you did the testing! I
appreciate that! However, I wonder if there is some wider consensus
whether the tests should be ran using real HW when tested-by tag is
given. Jonathan, do you have any educated opinion on this?
> I referred to this driver because it's
> the most recent accelerometer driver that was merged.
Makes sense :) Thanks for replying!
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
On Mon, 23 Oct 2023 09:24:39 +0300
Matti Vaittinen <[email protected]> wrote:
> On 10/20/23 19:48, Jagath Jog J wrote:
> > On Fri, Oct 20, 2023 at 5:39 PM Matti Vaittinen
> > <[email protected]> wrote:
> >>
> >> On 10/19/23 21:21, Jagath Jog J wrote:
> >>> Hi Matti,
> >>>
> >>> On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen
> >>> <[email protected]> wrote:
> >>>>
> >
> >>>> I did only very quick testing on KX022A and iio_generic_buffer. After
> >>>> the patch the values seemed to be correct order of magnitude. Further
> >>>> testing is appreciated :)
> >>>
> >>> Values are correct with this change, Thank you for fixing.
> >>> Tested-by: Jagath Jog J <[email protected]>
> >>
> >> Thanks a ton for testing! May I ask which component did you use (or did
> >> you just use some 'simulated' regster values?)
> >
> > Hi Matti,
> >
> > I just simulated with the register values, Should the 'tested-by' tag only be
> > provided after hardware testing?
>
> I am not sure TBH. I didn't have a problem with your tag though, I was
> merely curious to hear about the IC usage :)
>
> Now that you mentioned the tested-by tag usage, I started to wonder it
> as well. From pure SW/driver point of view the register value simulation
> is sufficient - but in practice we are not interested in whether the
> code works "in theory" - but whether the products do really work. This
> is something which includes handling of potential HW quircks and
> oddities - which are not always documented or known.
>
> If we assume a case where someone is developing new gizmo and hits a bug
> which is in reality caused by some undocumented HW hiccup - then fixes
> with "tested-by" tags which are not actually tested on HW having this
> hiccup but using SW simulation - may be misleading.
>
> The above is just some overall pondering - I am not too concerned on
> your tested-by tag :) Besides, it's cool you did the testing! I
> appreciate that! However, I wonder if there is some wider consensus
> whether the tests should be ran using real HW when tested-by tag is
> given. Jonathan, do you have any educated opinion on this?
It's fine to add a note. People typically do this if they've tested on
a particular device from a set. So if you want to (entirely optional)
Tested-by .... #Tested by simulate register values
I wouldn't describe that as a particularly educated opinion though :)
Not something I care that much about.
J
>
> > I referred to this driver because it's
> > the most recent accelerometer driver that was merged.
>
> Makes sense :) Thanks for replying!
>
> Yours,
> -- Matti
>