platform/chrome: cros_ec_sensorhub: Simplify legacy timestamp spreading
authorGwendal Grignou <gwendal@chromium.org>
Tue, 28 Jul 2020 09:13:55 +0000 (02:13 -0700)
committerEnric Balletbo i Serra <enric.balletbo@collabora.com>
Fri, 31 Jul 2020 09:52:43 +0000 (11:52 +0200)
commit7f4784f1881cbf7d3e6367e1c4341c1ab2ccdb5b
tree13089e7fed21ed739d50f173c4357961bf91dafa
parentc1e18d4fb9590268105e724444792656fcb3927d
platform/chrome: cros_ec_sensorhub: Simplify legacy timestamp spreading

On some machines (nami), interrupt latency cause samples to appear
to be from the future and are pegged to the current time.
We would see samples with this pattern:

[t, t + ~5ms, t + ~10ms, t + ~10ms + 100us, t + ~10ms + 200us],
                             (current now)      (current now)
(t is the last timestamp time)

Last 2 samples would be barely spread, causing applications to
complain.

We now spread the entire sequence. This is not great: in the example
the sensor was supposed to send samples every 5ms, it now appears to
send one every 2.5ms, but it is slightly closer to reality:

sampling time in the example above
At sensor level

1             2             3             4            5
+-----5ms-----+-----5ms-----+-----5ms-----+----5ms-----+---> t

Before, at host level
                       1             2             3 4 5
--interrupt delay------+-----5ms-----+-----5ms-----+-+-+---> t

Afer, at host level
                       1       2       3       4       5
--interrupt delay------+-2.5ms-+-2.5ms-+-2.5ms-+-2.5ms-+---> t

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
drivers/platform/chrome/cros_ec_sensorhub_ring.c