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
prev parent reply other threads:[~2021-01-09 11:47 UTC|newest]
Thread overview: 5+ 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 ` [PATCH RESEND v2 2/2] drm/drm_vblank: set the dma-fence timestamp during send_vblank_event Veera Sundaram Sankaran
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-09 0:00 ` veeras [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox