From: veeras@codeaurora.org
To: Daniel Vetter <daniel@ffwll.ch>,
dri-devel <dri-devel@lists.freedesktop.org>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>,
Sumit Semwal <sumit.semwal@linaro.org>,
Gustavo Padovan <gustavo@padovan.org>,
Dave Airlie <airlied@linux.ie>
Cc: ostedt@goodmis.org, "Clark, Rob" <robdclark@gmail.com>,
Sean Paul <sean@poorly.run>,
pdhaval@codeaurora.org, Abhinav Kumar <abhinavk@codeaurora.org>,
Jeykumar Sankaran <jsanka@codeaurora.org>
Subject: Re: [PATCH RESEND 1/2] dma-fence: allow signaling drivers to set fence timestamp
Date: Wed, 02 Dec 2020 17:14:26 -0800 [thread overview]
Message-ID: <c356da0d7b5a945e415620585073e40c@codeaurora.org> (raw)
In-Reply-To: <CAKMK7uEaYQmu6zBR5rYj=O1DdhzO2q_bMhntwxEuqbMqh_E9aQ@mail.gmail.com>
On 2020-11-19 03:58, Daniel Vetter wrote:
> On Thu, Nov 12, 2020 at 7:27 PM 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.
>> Move the timestamp parameter out of union in dma_fence struct to allow
>> signaling drivers to set it. If the parameter is not set, ktime_get is
>> used to set the current time to fence timestamp during
>> dma_fence_signal.
>>
>> Signed-off-by: Veera Sundaram Sankaran <veeras@codeaurora.org>
>
> So with they "why?" question fully resolved, I think this is a bit too
> much a hack. I think much better if we pass the timestamp explicitly,
> in a new dma_fence_signal_timestamp variant. That means a bit more
> work, but I think it will handle this special case cleaner.
>
> Also means we need to wire the timestamp through the entire call stack
> on the drm side too. So we need a drm_send_event_locked_timestamp
> variant too for send_vblank_event.
> -Daniel
>
@Sumit Semwal, @Gustavo Padovan, @Steven Rostedt
Can you please help in getting review for the v2 patches.
I have addressed the earlier comments from Daniel Vetter.
https://patchwork.kernel.org/project/dri-devel/list/?series=388881&archive=both
Thanks,
Veera
>> ---
>> drivers/dma-buf/dma-fence.c | 18 ++++++++++--------
>> include/linux/dma-fence.h | 15 +++------------
>> 2 files changed, 13 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 43624b4..7cef49a 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -4,6 +4,7 @@
>> *
>> * Copyright (C) 2012 Canonical Ltd
>> * Copyright (C) 2012 Texas Instruments
>> + * Copyright (c) 2020 The Linux Foundation. All rights reserved.
>> *
>> * Authors:
>> * Rob Clark <robdclark@gmail.com>
>> @@ -329,7 +330,6 @@ void __dma_fence_might_wait(void)
>> int dma_fence_signal_locked(struct dma_fence *fence)
>> {
>> struct dma_fence_cb *cur, *tmp;
>> - struct list_head cb_list;
>>
>> lockdep_assert_held(fence->lock);
>>
>> @@ -337,16 +337,18 @@ int dma_fence_signal_locked(struct dma_fence
>> *fence)
>> &fence->flags)))
>> return -EINVAL;
>>
>> - /* Stash the cb_list before replacing it with the timestamp */
>> - list_replace(&fence->cb_list, &cb_list);
>> -
>> - fence->timestamp = ktime_get();
>> + /* set current time, if not set by signaling driver */
>> + if (!fence->timestamp)
>> + fence->timestamp = ktime_get();
>> set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
>> trace_dma_fence_signaled(fence);
>>
>> - list_for_each_entry_safe(cur, tmp, &cb_list, node) {
>> - INIT_LIST_HEAD(&cur->node);
>> - cur->func(fence, cur);
>> + if (!list_empty(&fence->cb_list)) {
>> + list_for_each_entry_safe(cur, tmp, &fence->cb_list,
>> node) {
>> + INIT_LIST_HEAD(&cur->node);
>> + cur->func(fence, cur);
>> + }
>> + INIT_LIST_HEAD(&fence->cb_list);
>> }
>>
>> return 0;
>> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
>> index 09e23ad..a9eebaf 100644
>> --- a/include/linux/dma-fence.h
>> +++ b/include/linux/dma-fence.h
>> @@ -4,6 +4,7 @@
>> *
>> * Copyright (C) 2012 Canonical Ltd
>> * Copyright (C) 2012 Texas Instruments
>> + * Copyright (c) 2020 The Linux Foundation. All rights reserved.
>> *
>> * Authors:
>> * Rob Clark <robdclark@gmail.com>
>> @@ -70,26 +71,16 @@ struct dma_fence {
>> * release the fence it is unused. No one should be adding to
>> the
>> * cb_list that they don't themselves hold a reference for.
>> *
>> - * The lifetime of the timestamp is similarly tied to both the
>> - * rcu freelist and the cb_list. The timestamp is only set
>> upon
>> - * signaling while simultaneously notifying the cb_list. Ergo,
>> we
>> - * only use either the cb_list of timestamp. Upon destruction,
>> - * neither are accessible, and so we can use the rcu. This
>> means
>> - * that the cb_list is *only* valid until the signal bit is
>> set,
>> - * and to read either you *must* hold a reference to the
>> fence,
>> - * and not just the rcu_read_lock.
>> - *
>> * Listed in chronological order.
>> */
>> union {
>> struct list_head cb_list;
>> - /* @cb_list replaced by @timestamp on
>> dma_fence_signal() */
>> - ktime_t timestamp;
>> - /* @timestamp replaced by @rcu on dma_fence_release()
>> */
>> + /* @cb_list replaced by @rcu on dma_fence_release() */
>> struct rcu_head rcu;
>> };
>> u64 context;
>> u64 seqno;
>> + ktime_t timestamp;
>> unsigned long flags;
>> struct kref refcount;
>> int error;
>> --
>> 2.7.4
>>
prev parent reply other threads:[~2020-12-03 1:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 18:27 [PATCH RESEND 1/2] dma-fence: allow signaling drivers to set fence timestamp Veera Sundaram Sankaran
2020-11-12 18:27 ` [PATCH RESEND 2/2] drm/drm_vblank: set the dma-fence timestamp during send_vblank_event Veera Sundaram Sankaran
2020-11-13 20:45 ` Daniel Vetter
2020-11-19 1:26 ` veeras
2020-11-19 11:50 ` Daniel Vetter
2020-11-18 20:27 ` [PATCH RESEND 1/2] dma-fence: allow signaling drivers to set fence timestamp veeras
2020-11-18 20:45 ` Daniel Vetter
2020-11-19 11:58 ` Daniel Vetter
2020-12-03 1:14 ` 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=c356da0d7b5a945e415620585073e40c@codeaurora.org \
--to=veeras@codeaurora.org \
--cc=abhinavk@codeaurora.org \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo@padovan.org \
--cc=jsanka@codeaurora.org \
--cc=linux-media@vger.kernel.org \
--cc=ostedt@goodmis.org \
--cc=pdhaval@codeaurora.org \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=sumit.semwal@linaro.org \
/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;
as well as URLs for NNTP newsgroup(s).