On Thu, Jan 7, 2021 at 12:53 AM Veera Sundaram Sankaran veeras@codeaurora.org wrote:
Some drivers have hardware capability to get the precise timestamp of certain events based on which the fences are triggered. This allows it to set accurate timestamp factoring out any software and IRQ latencies. Add a timestamp variant of fence signal function, dma_fence_signal_timestamp to allow drivers to update the precise timestamp for fences.
So, on quick review, this seems mostly sane. Though, it might be good to add some more detail about how the hardware timestamping fits into the kernel's CLOCK_MONOTONIC time domain.
I just want to make sure this interface isn't abused to jam raw hardware-domain timestamps into the fence->timestamp, causing the meaning or time-domain of the fence->timestamp to be unclear or inconsistent.
It may be useful to add an additional patch to the documentation around the dma_fence structure to make the timestamp field semantics more explicit and avoid confusion?
thanks -john