summaryrefslogtreecommitdiff
path: root/driver/accelgyro_lsm6dsm.h
diff options
context:
space:
mode:
authorEnrico Granata <egranata@chromium.org>2019-03-07 14:31:50 -0800
committerchrome-bot <chrome-bot@chromium.org>2019-03-21 08:07:25 -0700
commit2a6a9ca09a8d8766b24cd1ba3bc54f2ddc7deaae (patch)
tree7024c4a748246ed30f5b9078f29d4659cc59247c /driver/accelgyro_lsm6dsm.h
parentc272044163c0ca42f4b6649178a015b93ac4307d (diff)
downloadchrome-ec-2a6a9ca09a8d8766b24cd1ba3bc54f2ddc7deaae.tar.gz
driver: lsm6dsm: Fix race condition and sensor labeling issues
This commit fixes two issues with the LSM6DSM driver: - it fixes a race condition in load_fifo() which could lead to samples being labeled at the wrong timestamp if the FIFO was cleared, and a new interrupt occurred, between reading the last sample, and pushing it to the motion sense queue - it drops samples even when the ODR is changed to the same final normalized rate, since the sensor is turned off/on regardless of this condition; additionally, it adds one more sample to the number of samples to be discarded, since I was experimentally seeing occasional spurious data in the first sample after a rate change. BUG=b:124085261 TEST=on Meep with magnetometer stuffed, and CL:1470775 enabled, run CTS sensor test cases Change-Id: I9701d90fa4e86488840b776e2c7afe4dd89570e7 Signed-off-by: Enrico Granata <egranata@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1509718 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org>
Diffstat (limited to 'driver/accelgyro_lsm6dsm.h')
-rw-r--r--driver/accelgyro_lsm6dsm.h4
1 files changed, 2 insertions, 2 deletions
diff --git a/driver/accelgyro_lsm6dsm.h b/driver/accelgyro_lsm6dsm.h
index 1f76195339..f9a4deff59 100644
--- a/driver/accelgyro_lsm6dsm.h
+++ b/driver/accelgyro_lsm6dsm.h
@@ -351,10 +351,10 @@ struct lsm6dsm_data {
/*
* Note: The specific number of samples to discard depends on the filters
* configured for the chip, as well as the ODR being set. For most of our
- * allowed ODRs, 4 should suffice.
+ * allowed ODRs, 5 should suffice.
* See: ST's LSM6DSM application notes (AN4987) Tables 17 and 19 for details
*/
-#define LSM6DSM_DISCARD_SAMPLES 4
+#define LSM6DSM_DISCARD_SAMPLES 5
#define LSM6DSM_ST_DATA(g, type) (&(&(g))->st_data[(type)])