From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Satyam Gupta <sgsatyam@google.com>
Cc: bleung@chromium.org, groeck@chromium.org,
chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org,
scollyer@google.com
Subject: Re: [PATCH v3] platform/chrome: cros_ec_sensorhub: Modify clock drift estimation
Date: Tue, 28 Jul 2026 10:15:49 +0000 [thread overview]
Message-ID: <amiBVdd1KvxbW5Ul@google.com> (raw)
In-Reply-To: <20260723163838.1698125-1-sgsatyam@google.com>
On Thu, Jul 23, 2026 at 04:38:38PM +0000, Satyam Gupta wrote:
> This CL makes 5 specific changes to the clock drift estimation algorithm
Since these are 5 distinct logical changes, shouldn't they be separated into
a 5-patch series?
> and timestamp filtering to resolve monotonic backward skews and OOO errors
^^^
Please spell out the acronym (i.e., Out Of Order) for clarity.
> during batching:
>
> 1. Clamp the calculated drift slope (m) to a realistic maximum bound
> (+/- 200 PPM). Huge jitter spikes previously produced astronomical
Same here: P..? Per Million?
> Signed-off-by: SATYAM GUPTA <sgsatyam@google.com>
Please fix the capitalization of your name to match the author line.
> /*
> * If we don't have any history entries for this long, empty the filter to
> - * make sure there are no big discontinuities.
> + * make sure there are no big discontinuities (e.g. after suspend or long idle).
> + *
> + * This is set to 2 seconds to accommodate normal batching flush intervals
> + * (which can be up to 1-2 seconds) without constantly resetting the filter,
> + * while still ensuring a reset occurs during actual long gaps or suspend.
> */
> -#define TS_HISTORY_BORED_US 500000
> +#define TS_HISTORY_BORED_US 2000000 // 2 seconds
^^^^^^^^^^^^
The inline comment is redundant.
> /* Move everything over, also update offset to all absolute coords .*/
> - for (i = state->history_len - 1; i >= 1; i--) {
> + start = (state->history_len == CROS_EC_SENSORHUB_TS_HISTORY_SIZE) ?
> + state->history_len - 1 : state->history_len;
How about:
min_t(int, state->history_len, CROS_EC_SENSORHUB_TS_HISTORY_SIZE - 1);
> -static void
> +static bool
> cros_ec_sensor_ring_check_for_past_timestamp(struct cros_ec_sensorhub
> *sensorhub,
> struct cros_ec_sensors_ring_sample
It'd be better to rename the function to make its intent clear. E.g.:
cros_ec_sensor_ring_is_past_timestamp()
And have it return true if it's a past timestamp, adjusting the caller
logic accordingly.
---
On a related note, is [1] still relevant? Should we disregard it?
[1] https://lore.kernel.org/all/20260720110405.2127011-1-sgsatyam@google.com
prev parent reply other threads:[~2026-07-28 10:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 12:48 [PATCH] platform/chrome: cros_ec_sensorhub: Modify clock drift estimation Satyam Gupta
2026-07-23 16:36 ` [PATCH v2] framework/chrome: " Satyam Gupta
2026-07-23 16:38 ` [PATCH v3] platform/chrome: " Satyam Gupta
2026-07-28 10:15 ` Tzung-Bi Shih [this message]
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=amiBVdd1KvxbW5Ul@google.com \
--to=tzungbi@kernel.org \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=groeck@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scollyer@google.com \
--cc=sgsatyam@google.com \
/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