Re: [PATCH v3] platform/chrome: cros_ec_sensorhub: Modify clock drift estimation
From: Tzung-Bi Shih
Date: Tue Jul 28 2026 - 06:34:22 EST
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@xxxxxxxxxx>
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@xxxxxxxxxx