Hi Matti,
On Sun, Mar 19, 2023 at 09:43:19AM +0200, Matti Vaittinen wrote:
Hi Mehdi,
Things have been piling up for me during last two weeks... I will do proper
review during next week.
On 3/17/23 01:48, Mehdi Djait wrote:
KX132 accelerometer is a sensor which:
- supports G-ranges of (+/-) 2, 4, 8, and 16G
- can be connected to I2C or SPI
- has internal HW FIFO buffer
- supports various ODRs (output data rates)
The KX132 accelerometer is very similair to the KX022A.
One key difference is number of bits to report the number of data bytes that
have been stored in the sample buffer: 8 bits for KX022A vs 10 bits for KX132.
The KX022A has 16bits of data in HiRes mode. This is the default for kx022a
driver.
I am talking here about "Buffer Sample Level number of bits":
8 bits: just BUF_STATUS_1 to report the status of the buffer. kx132 uses
BUF_STATUS_1 and the Bit0, Bit1 of BUF_STATUS_2.
That's the reason for adding the kx022a_get_fifo_bytes function.
A complete list of differences is listed in [1]
[1] https://kionixfs.azureedge.net/en/document/AN112-Transitioning-to-KX132-1211-Accelerometer.pdf1
This document is somewhat misleading. It does not contain KX022A but the
older KX022. Kionix has the somewhat confusing habit of having very similar
names for models with - occasionally significant - differences. (My own
opinion).
Yes, I am aware that it does not contain KX022A, but from my
understanding of your code, the document can be used to highlight the
difference I mentioned
Finally, AFAIK the key "thing" in KX132 is the "ADP" (Advanced Data Path)
feature which allows filtering the data "in sensor". Unfortunately, I am not
really familiar with this feature. Do you think this is something that might
get configured only once at start-up depending on the purpose of the board?
If yes, this might be something that will end-up having properties in
device-tree. If yes, then it might be a good idea to have own binding doc
for KX132. Currently it seems Ok to have them in the same binding doc
though.
Correct me if I am wrong: the Devicetree is a description of the
hardware
and the transitioning document states:
"From a hardware perspective, all these sensors
have an identical pad/pin layouts and identical pin functionality"
I was thinking about adding an advanced_data_path boolean to the chip_info
struct and providing different driver callbacks depending on the value.
Something like in the bmc150-accel-core: iio_info for bmc150_accel_info
and iio_info for bmc150_accel_info_fifo