On 2021-01-08 11:55, John Stultz wrote:
On Thu, Jan 7, 2021 at 12:53 AM Veera Sundaram Sankaran
<veeras@xxxxxxxxxxxxxx> 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 for the comments. Sure, let me add more information in the
commit-text about the HW timestamp conversion to kernel time-domain.
Will explicitly mention the timestamp domain expected as part of the
new dma_fence_signal_timestamp api documentation, since that would
be the only place the timestamp would be set externally from drivers.
On top of it, do suggest if still documentation on dma_fence struct
would be required.
Thanks,
Veera
thanks
-john
