All of lore.kernel.org
 help / color / mirror / Atom feed
From: veeras@codeaurora.org
To: John Stultz <john.stultz@linaro.org>
Cc: David Airlie <airlied@linux.ie>,
	Gustavo Padovan <gustavo@padovan.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	pdhaval@codeaurora.org, abhinavk@codeaurora.org,
	Sean Paul <sean@poorly.run>,
	linux-media <linux-media@vger.kernel.org>
Subject: Re: [PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp
Date: Fri, 08 Jan 2021 16:00:54 -0800	[thread overview]
Message-ID: <5a4f9d51cd07e8a533446e1f093ab4a7@codeaurora.org> (raw)
In-Reply-To: <CALAqxLVyCuQmEKYh+TBo7k5igP8piz8mAsFt4cChF9q=qmh8XQ@mail.gmail.com>

On 2021-01-08 11:55, John Stultz wrote:
> 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 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: veeras@codeaurora.org
To: John Stultz <john.stultz@linaro.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	linux-media <linux-media@vger.kernel.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Gustavo Padovan <gustavo@padovan.org>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	abhinavk@codeaurora.org, pdhaval@codeaurora.org,
	Sean Paul <sean@poorly.run>
Subject: Re: [PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp
Date: Fri, 08 Jan 2021 16:00:54 -0800	[thread overview]
Message-ID: <5a4f9d51cd07e8a533446e1f093ab4a7@codeaurora.org> (raw)
In-Reply-To: <CALAqxLVyCuQmEKYh+TBo7k5igP8piz8mAsFt4cChF9q=qmh8XQ@mail.gmail.com>

On 2021-01-08 11:55, John Stultz wrote:
> 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 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

  reply	other threads:[~2021-01-09 11:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 19:49 [PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp Veera Sundaram Sankaran
2021-01-06 19:49 ` Veera Sundaram Sankaran
2021-01-06 19:49 ` [PATCH RESEND v2 2/2] drm/drm_vblank: set the dma-fence timestamp during send_vblank_event Veera Sundaram Sankaran
2021-01-06 19:49   ` Veera Sundaram Sankaran
2021-01-08 20:06   ` John Stultz
2021-01-08 20:06     ` John Stultz
2021-01-08 19:55 ` [PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp John Stultz
2021-01-08 19:55   ` John Stultz
2021-01-09  0:00   ` veeras [this message]
2021-01-09  0:00     ` veeras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a4f9d51cd07e8a533446e1f093ab4a7@codeaurora.org \
    --to=veeras@codeaurora.org \
    --cc=abhinavk@codeaurora.org \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=pdhaval@codeaurora.org \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.