[PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp

[veeras at codeaurora.org]

On 2021-01-08 11:55, John Stultz wrote:
> On Thu, Jan 7, 2021 at 12:53 AM Veera Sundaram Sankaran
> <veeras at 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 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