From: Satyam Gupta <sgsatyam@google.com>
To: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: Benson Leung <bleung@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
Gwendal Grignou <gwendal@chromium.org>,
Scott Collyer <scollyer@google.com>,
chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org,
Satyam Gupta <sgsatyam@google.com>
Subject: [PATCH v6 4/7] platform/chrome: cros_ec_sensorhub: Clamp clock drift slope to MAX_DRIFT_PPM
Date: Thu, 29 Oct 2026 09:28:43 +0000 [thread overview]
Message-ID: <20261029092846.1567475-5-sgsatyam@google.com> (raw)
In-Reply-To: <20261029092846.1567475-1-sgsatyam@google.com>
From: Scott Collyer <scollyer@google.com>
Interrupt jitter can produce slopes between consecutive IRQ timestamp
pairs that are far larger than any real clock drift between the EC and
the AP. When such outliers dominate the history, they corrupt the median
filter used to convert EC timestamps to the AP timebase and lead to Out
Of Order (OOO) sensor events.
Clamp the slope to +/- MAX_DRIFT_PPM Parts Per Million (PPM). The slope
is computed from a time delta in ns over a time delta in us, so it is
1000 times the unitless drift; take that into account when converting
the limit to fixed point.
Set the limit to 5000 PPM. The drift measured between the AP and the
sensor hub is about 16 PPM on a device with sensors behind the Intel ISH,
but about 2900 PPM on a MediaTek-based device with sensors behind a
standalone EC.
Signed-off-by: Scott Collyer <scollyer@google.com>
Signed-off-by: Satyam Gupta <sgsatyam@google.com>
---
drivers/platform/chrome/cros_ec_sensorhub_ring.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_sensorhub_ring.c b/drivers/platform/chrome/cros_ec_sensorhub_ring.c
index c5331d9..46f44c6 100644
--- a/drivers/platform/chrome/cros_ec_sensorhub_ring.c
+++ b/drivers/platform/chrome/cros_ec_sensorhub_ring.c
@@ -23,6 +23,14 @@
/* Precision of fixed point for the m values from the filter */
#define M_PRECISION BIT(23)
+/*
+ * Maximum clock drift between the EC and the AP, in Parts Per Million
+ * (PPM). m is computed from a time delta in ns over a time delta in us,
+ * so it is 1000 times the unitless drift: 1 PPM is M_PRECISION / 1000.
+ */
+#define MAX_DRIFT_PPM 5000LL
+#define MAX_M ((s64)(MAX_DRIFT_PPM * M_PRECISION / 1000))
+
/* Only activate the filter once we have at least this many elements. */
#define TS_HISTORY_THRESHOLD 8
@@ -289,6 +297,12 @@ cros_ec_sensor_ring_ts_filter_update(struct cros_ec_sensors_ts_filter_state
return; /* we already have this irq in the history */
dy = (state->y_history[0] + state->y_offset) - y;
m = div64_s64(dy * M_PRECISION, dx);
+ /*
+ * Clamp the slope to the maximum expected clock drift. Interrupt
+ * jitter can produce slopes much larger than any real clock drift,
+ * which would otherwise corrupt the median filter history.
+ */
+ m = clamp(m, -MAX_M, MAX_M);
/* Empty filter if we haven't seen any action in a while. */
if (-dx > TS_HISTORY_BORED_US)
--
2.56.0.307.g5fe7bd680c-goog
next prev parent reply other threads:[~2026-10-29 9:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 9:28 [PATCH v6 0/7] platform/chrome: cros_ec_sensorhub: Timestamp wrap and drift filter fixes Satyam Gupta
2026-10-29 9:28 ` [PATCH v6 1/7] platform/chrome: cros_ec_sensorhub: Unwrap sample TS relative to FIFO TS Satyam Gupta
2026-10-29 9:28 ` [PATCH v6 2/7] platform/chrome: cros_ec_sensorhub: Reset TS filter on EC/AP time mismatch Satyam Gupta
2026-10-29 9:28 ` [PATCH v6 3/7] platform/chrome: cros_ec_sensorhub: Fix TS filter history shift index Satyam Gupta
2026-10-29 9:28 ` Satyam Gupta [this message]
2026-10-29 9:28 ` [PATCH v6 5/7] platform/chrome: cros_ec_sensorhub: Reset TS filter on ODR or mode changes Satyam Gupta
2026-10-29 9:28 ` [PATCH v6 6/7] platform/chrome: cros_ec_sensorhub: Increase TS_HISTORY_BORED_US to 2s Satyam Gupta
2026-10-29 9:28 ` [PATCH v6 7/7] platform/chrome: cros_ec_sensorhub: Drop sensor samples with past timestamps Satyam Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261029092846.1567475-5-sgsatyam@google.com \
--to=sgsatyam@google.com \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=groeck@chromium.org \
--cc=gwendal@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scollyer@google.com \
--cc=tzungbi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®