Computes and forwards the device timestamp according to the
specification.
Many devices use a 16-bit timestamp field, with a resolution
of 100us, therefore rolling around very frequently (every
6.5 seconds). To make sure there is no ambiguity, the
timestamp reported to the input stack reset to 0 whenever
the time between 2 received events is greater than
MAX_TIMESTAMP_INTERVAL (1 second).
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---
Inspired from Benjamin Tissoires's patch here: https://patchwork.kernel.org/patch/1742181/, and changing the
logic to resynchronize the timestamps to use received time
instead of a potentially more fragile difference between
the 2 deltas.
On Tue, 22 Aug 2017, Nicolas Boichat wrote:
Computes and forwards the device timestamp according to the
specification.
Many devices use a 16-bit timestamp field, with a resolution
of 100us, therefore rolling around very frequently (every
6.5 seconds). To make sure there is no ambiguity, the
timestamp reported to the input stack reset to 0 whenever
the time between 2 received events is greater than
MAX_TIMESTAMP_INTERVAL (1 second).
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---
Inspired from Benjamin Tissoires's patch here: https://patchwork.kernel.org/patch/1742181/, and changing the
logic to resynchronize the timestamps to use received time
instead of a potentially more fragile difference between
the 2 deltas.
Benjamin, any objections on merging this one for 4.15? I like it.
Thanks,
--
Jiri Kosina
SUSE Labs
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 242:25:23 |
Calls: | 6,624 |
Files: | 12,175 |
Messages: | 5,320,202 |