Message-ID: <CAK-9PRD6FH=5g0SrVcw+81Witpo8zRfvnsmGaePaA4swjHWkSw@mail.gmail.com>
Date:	Wed, 22 Aug 2012 22:24:10 +0530
From:	Chinmay V S <cvs268@...il.com>
To:	"AnilKumar, Chimata" <anilkumar@...com>, carmine.iascone@...com
Cc:	Arnd Bergmann <arnd@...db.de>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"eric.piel@...mplin-utc.net" <eric.piel@...mplin-utc.net>,
	"jic23@....ac.uk" <jic23@....ac.uk>,
	"greg@...ah.com" <greg@...ah.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer

> Look at this application note which talks about the outdata values
> for 2G range (page 12/31) http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf

Had been through the application note earlier. The table5 (on page 12)
that you refer to, does NOT contradict either 12/16bit, as in all the
examples the lower 4 bits are zero. So i don't see how one can assume
from these examples that for +/-2G they one should consider 12/16bits.
A nice side-effect of using 12|13|14bits for +/-2|4|8G is that the
values returned by the driver are in mG in all the 3 modes.

> Corresponding to the 4G and 8G I got the details form older
> patches (SHIFT_ADJ_4G and SHIFT_ADJ_8G).
> http://driverdev.linuxdriverproject.org/pipermail/devel/2010-November/009685.html
>
> We can easily interpret number of bits for 4G and 8G from 2G
> information.

Going through the code of this driver i can see what you are talking
about. Depending on the full-scale-range the device is being
configured for, the number of bits used to represent acceleration in
the driver is changed.

Again judging from the code, the driver is always returning
acceleration at a constant accuracy i.e. 1mG in all the 3 modes
(+/-2|4|8G)i.e.
+/-2G is mode means value can be anywhere from +/-2048mG,
(requiring 12bits.)
+/-4G in the range of +/-4096mG, requiring 13bits.
+/-8G i.e. +/-8192mG, requiring 14bits.

Was this done...

a. ...because LIS331DLH's theoretical MAX accuracy is ~1mG
If yes, then using 12bits is fine.

-OR-

b. ...so that the driver will report values at a constant
scale(i.e.mG) regardless of the mode?
If yes, then maybe we could consider using the additional bits to
obtain the maximum possible accuracy the LIS331DLH supports rather
than choosing to discard the LSBits.

(Can anyone please confirm the above?)

Going through the datasheet of LIS331DLH,
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00213470.pdf
we see that accuracy/sensitivity of the device as per Table 2.1
(page9/38) is 1|2|4mG in +/-2|4|8Gmodes respectively. It is mentioned
in the footnotes that the readings were taken at 12bit resolution(a
point in favour of using 12bits ourselves). But its is still NOT clear
whether the accuracy/sensitivity are the LIS331DLH's physical limits
or whether they stem from the fact that ONLY 12bits were used during
the rating tests.

I hope i'm not being too much of a PIA. My sole intention is to see
that we do NOT unintentionally lose track of the device capabilities
in the midst of all these driver iterations. Thank you for your
patience.

PS: One more nitpick
> LIS3331DLH spec says 1LSBs(...)
LIS3331DLH --> LIS331DLH

-- 
regards
ChinmayVS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists