From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Satyam Gupta <sgsatyam@google.com>
Cc: Scott Collyer <scollyer@google.com>,
Benson Leung <bleung@chromium.org>,
Gwendal Grignou <gwendal@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] platform/chrome: cros_ec_sensorhub: Modify clock drift estimation
Date: Wed, 14 Oct 2026 06:48:54 +0000 [thread overview]
Message-ID: <as8l1oKtNsIwNHWr@google.com> (raw)
In-Reply-To: <20261013105713.1369546-1-sgsatyam@google.com>
On Tue, Oct 13, 2026 at 10:56:50AM +0000, Satyam Gupta wrote:
> On Tue, Jul 28, 2026 at 10:15:52AM +0000, Tzung-Bi Shih 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?
>
> Although the v3 commit description listed the adjustments as 5 bullet points,
> they are tightly coupled parts of a single fix to support sensor batching in
> the timestamp filter without breaking intermediate states:
>
> - Extending TS_HISTORY_BORED_US from 0.5s to 2.0s so the filter survives 1-2s
> batch flush intervals requires the 10x dx ODR/mode-change reset and slope
> clamping; otherwise, transitions between active streaming and batching (which
> previously exceeded the 0.5s timeout) mix into the same filter history.
> - The 10x dx check (which reads state->x_history[1] when history_len > 1)
> depends directly on the loop start index fix: previously, with
> `i = state->history_len - 1`, the loop did not run when `history_len == 1`,
> leaving `x_history[1]` unpopulated when `history_len` became 2.
> - Dropping strictly past timestamps instead of clamping them to `last_ts`
> prevents post-reset backward ticks from being mistaken for same-timestamp
> batches by `cros_ec_sensor_ring_spread_add()`.
>
> I have reworded the commit message in v4 to explain how these pieces work
> together as a single cohesive change rather than a numbered list of unrelated
> items.
I'm not convinced. I think they should still separate into 5 patches and
form a series.
> > On a related note, is [1] still relevant? Should we disregard it?
> >
> > [1] https://lore.kernel.org/all/20260720110405.2127011-1-sgsatyam@google.com
>
> Yes, [1] ("platform/chrome: cros_ec_sensorhub: Fix AP/EC TS wrap") is still
> relevant — it addresses 32-bit EC timestamp rollover across deep AP suspend.
Please resend or include it in the same series.
next prev parent reply other threads:[~2026-10-14 6:48 UTC|newest]
Thread overview: 7+ 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
2026-10-13 10:56 ` Satyam Gupta
2026-10-14 6:48 ` Tzung-Bi Shih [this message]
2026-10-14 7:42 ` 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=as8l1oKtNsIwNHWr@google.com \
--to=tzungbi@kernel.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.