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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox