Message ID | ZTEt7NqfDHPOkm8j@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2010:b0:403:3b70:6f57 with SMTP id fe16csp380766vqb; Thu, 19 Oct 2023 06:24:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG3P071PiOwEm0o+DynQeosYU1S4szCjKBUdsfpXV3U1fDvQCLbHWzLSC8SSU9gjzHZXALY X-Received: by 2002:a05:6a00:2d91:b0:6ba:4f2e:33ca with SMTP id fb17-20020a056a002d9100b006ba4f2e33camr2254895pfb.2.1697721868928; Thu, 19 Oct 2023 06:24:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697721868; cv=none; d=google.com; s=arc-20160816; b=AhNibt5ULRrrVL1HUXeR5as/JCTLvQiIJ0mDDI2tG7gNTo2dgUoReVAhEVar3sUX+J IV5jqPPLlQU4morhI2IQuqoMyHBSk2020LW8taqqHyR2DzofM8UhqKb42PBnNaFL0KJ1 ZavmZR9rlM243PgKNEk2CuwHHgcVd+R6bkt460Njc9hAkkBpezH3sdYQjEzcmF0mK6aL lpO5Y+6jOFoGxXd1Og/dZIE0hyCX/TSmJR0MW121oyFrtFQfcKO2MiLUv41fNUxtpPRd cRnIJ8EzwWdJstr6hKTegapzyZQI6lrntKAofwwsy0YtPLpC4gOgLJwcNILitmgqlzU9 DGLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature; bh=6XTlMS7+GX23qRM9fgW0oBkKi4/d88mo4TG26yVCQlU=; fh=7knu26UtHvx/0f6H4hf03vezi5EZieRM9n6uqblPSL4=; b=tAkBZqq3zjllyxdBxALY1RTAcYh0nu0nATPe9XI09kI3S9AwcZC8MQxKwDKwehtq+M 7gXPKEjgfchJTwVKAIyRSe6RhcfpQ2glgf02nAO+TxPSgmsP53frYTZda4uLR4wdrhcY A3hjQr9jFpj4YzuiAdXtNPPrwKh4b2FnQLodZTKWNnsKyxKAee49M6DO+0Fxj4xkKxOI 0mVbWx8XU9IvI7BDku4trEJQpqAm5rV5xbuKqaet4JHbuCjJ5Qxr6b7BSAKmMsYNTaKH QuXa1Y58PVZar5zfIE3YD4IX6lRh9MRKcE5i9QMoS3HfYdhs25sHneQ8C9/f4vyR9D+m cE2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MVRxRbVe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id k8-20020aa79d08000000b006be3679b485si886309pfp.396.2023.10.19.06.24.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Oct 2023 06:24:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MVRxRbVe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 67E798236258; Thu, 19 Oct 2023 06:24:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345908AbjJSNYL (ORCPT <rfc822;lkml4gm@gmail.com> + 25 others); Thu, 19 Oct 2023 09:24:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345858AbjJSNYK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 19 Oct 2023 09:24:10 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C863112; Thu, 19 Oct 2023 06:24:08 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-507c50b7c36so3350522e87.3; Thu, 19 Oct 2023 06:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697721846; x=1698326646; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=6XTlMS7+GX23qRM9fgW0oBkKi4/d88mo4TG26yVCQlU=; b=MVRxRbVeDptSZdxE499zyIqIDCoR66BglmR1rlG0rlBuoUxEdWWg3OOTm5Jh1KgMnj PZ7T1uCBoBVzpOdvx52lyDlwKcx2hD2kPwJ+KTkb8uuL6JkDEJyfIFxaTuBG6JCE3DSN dpEwZ1Qu1edWFO7b/stBhXfLNV3W4Wj2uydGnZDYqbTc4ROHCrMsehlfZc235DJxVJoE 9QX0fRTxa6DURqYfA1OoeCYGjSCKM4te2J+0gTG/S9kTW0Ukt+tXO763QZppis5f6UBq gEUi7hOduMWzzbXMbC3pfrzOv3UEIMxYVULdEe8VKeOq/EzU349bfkZMVFhI7MN/9WfK J5pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697721846; x=1698326646; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6XTlMS7+GX23qRM9fgW0oBkKi4/d88mo4TG26yVCQlU=; b=q/263Jx7uqD3FZ/Tua/1IO4KwOlCzupYB5Q24vacqbG8/3dHTR+C8qIiDzdFK+niLC 0+FNXu8DW6W1aGwwA6duflsePXJGJ72EwM3O4njg+HIBrjtOGmyV1uwwII2gdO4AG9Qu JgKb4oAK+BL71jVVITrtb4TgnQZpkPRbKRVPfX8Xux1IgJgXC998kMx/z8p6Arja2HpA W/FTrIoFbcKgIATGXFx9K6a/sYFa5W/7/Pz4cennCrNl2+cU8WDUcxpBFUsRq7D14Ncb 8tIL0ClfaOoWmddGrpm00MBpbUHTnGG1/ww+GYDr214B7qN0XED9nreU8N9vpg1pMJfF 7ZOw== X-Gm-Message-State: AOJu0YzSCr5a+pS+59o9/vSvufSITAV1ntscOUCBLTZzYOPJ/Soqde9V ZysXJzfZwwOgPO3xu6aV87U= X-Received: by 2002:ac2:5a1e:0:b0:507:9701:2700 with SMTP id q30-20020ac25a1e000000b0050797012700mr1399666lfn.20.1697721846098; Thu, 19 Oct 2023 06:24:06 -0700 (PDT) Received: from dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi (dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi. [2001:14ba:16f8:1500::7]) by smtp.gmail.com with ESMTPSA id h9-20020a197009000000b005030cef433esm1088538lfc.94.2023.10.19.06.24.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Oct 2023 06:24:05 -0700 (PDT) Date: Thu, 19 Oct 2023 16:23:56 +0300 From: Matti Vaittinen <mazziesaccount@gmail.com> To: Matti Vaittinen <mazziesaccount@gmail.com>, Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Cc: Matti Vaittinen <mazziesaccount@gmail.com>, Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Jagath Jog J <jagathjog1996@gmail.com>, Mehdi Djait <mehdi.djait.k@gmail.com>, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] iio: kx022a: Fix acceleration value scaling Message-ID: <ZTEt7NqfDHPOkm8j@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BRC617NORhFtqw3Q" Content-Disposition: inline X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 19 Oct 2023 06:24:26 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780190406410349088 X-GMAIL-MSGID: 1780190406410349088 |
Series |
iio: kx022a: Fix acceleration value scaling
|
|
Commit Message
Matti Vaittinen
Oct. 19, 2023, 1:23 p.m. UTC
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 <mazziesaccount@gmail.com>
Reported-by: Jagath Jog J <jagathjog1996@gmail.com>
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(-)
Comments
Hi Matti, On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen <mazziesaccount@gmail.com> 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 <mazziesaccount@gmail.com> > Reported-by: Jagath Jog J <jagathjog1996@gmail.com> > 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 <jagathjog1996@gmail.com> 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 > <mazziesaccount@gmail.com> 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 <mazziesaccount@gmail.com> >> Reported-by: Jagath Jog J <jagathjog1996@gmail.com> >> 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 <jagathjog1996@gmail.com> Thanks a ton for testing! May I ask which component did you use (or did you just use some 'simulated' regster values?) Yours, -- Matti
On Fri, Oct 20, 2023 at 5:39 PM Matti Vaittinen <mazziesaccount@gmail.com> wrote: > > On 10/19/23 21:21, Jagath Jog J wrote: > > Hi Matti, > > > > On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen > > <mazziesaccount@gmail.com> 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 <jagathjog1996@gmail.com> > > 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 <mazziesaccount@gmail.com> 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 <mazziesaccount@gmail.com> > Reported-by: Jagath Jog J <jagathjog1996@gmail.com> > 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 > <mazziesaccount@gmail.com> wrote: >> >> On 10/19/23 21:21, Jagath Jog J wrote: >>> Hi Matti, >>> >>> On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen >>> <mazziesaccount@gmail.com> 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 <jagathjog1996@gmail.com> >> >> 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
On Mon, 23 Oct 2023 09:24:39 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On 10/20/23 19:48, Jagath Jog J wrote: > > On Fri, Oct 20, 2023 at 5:39 PM Matti Vaittinen > > <mazziesaccount@gmail.com> wrote: > >> > >> On 10/19/23 21:21, Jagath Jog J wrote: > >>> Hi Matti, > >>> > >>> On Thu, Oct 19, 2023 at 6:54 PM Matti Vaittinen > >>> <mazziesaccount@gmail.com> 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 <jagathjog1996@gmail.com> > >> > >> 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 >
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,