summaryrefslogtreecommitdiffstats
path: root/net/rds/Kconfig
diff options
context:
space:
mode:
authorGwendal Grignou <gwendal@chromium.org>2020-07-28 11:13:55 +0200
committerEnric Balletbo i Serra <enric.balletbo@collabora.com>2020-07-31 11:52:43 +0200
commit7f4784f1881cbf7d3e6367e1c4341c1ab2ccdb5b (patch)
tree13089e7fed21ed739d50f173c4357961bf91dafa /net/rds/Kconfig
parentplatform/chrome: cros_ec_proto: Do not export cros_ec_cmd_xfer() (diff)
downloadlinux-7f4784f1881cbf7d3e6367e1c4341c1ab2ccdb5b.tar.xz
linux-7f4784f1881cbf7d3e6367e1c4341c1ab2ccdb5b.zip
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>
Diffstat (limited to 'net/rds/Kconfig')
0 files changed, 0 insertions, 0 deletions