From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <rob.clark@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>,
sumit.semwal@linaro.org, linaro-mm-sig@lists.linaro.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-media@vger.kernel.org
Subject: Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
Date: Sat, 11 Aug 2012 21:22:47 +0200 [thread overview]
Message-ID: <20120811192247.GB5132@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGvzaJmVmnZmEp0QBfja8Vzb0mpLa_2J6bdUZj=fgDAHVg@mail.gmail.com>
On Sat, Aug 11, 2012 at 10:14:40AM -0500, Rob Clark wrote:
> On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
> >> +
> >> + if (!ret) {
> >> + cb->base.flags = 0;
> >> + cb->base.func = __dma_fence_wake_func;
> >> + cb->base.private = priv;
> >> + cb->fence = fence;
> >> + cb->func = func;
> >> + __add_wait_queue(&fence->event_queue, &cb->base);
> >> + }
> >> + spin_unlock_irqrestore(&fence->event_queue.lock, flags);
> >> +
> >> + return ret;
> >> +}
> >> +EXPORT_SYMBOL_GPL(dma_fence_add_callback);
> >
> > I think for api completenes we should also have a
> > dma_fence_remove_callback function.
>
> We did originally but Maarten found it was difficult to deal with
> properly when the gpu's hang. I think his alternative was just to
> require the hung driver to signal the fence. I had kicked around the
> idea of a dma_fence_cancel() alternative to signal that could pass an
> error thru to the waiting driver.. although not sure if the other
> driver could really do anything differently at that point.
Well, the idea is not to cancel all callbacks, but just a single one, in
case a driver wants to somehow abort the wait. E.g. when the own gpu dies
I guess we should clear all these fence callbacks so that they can't
clobber the hw state after the reset.
> >> +
> >> +/**
> >> + * dma_fence_wait - wait for a fence to be signaled
> >> + *
> >> + * @fence: [in] The fence to wait on
> >> + * @intr: [in] if true, do an interruptible wait
> >> + * @timeout: [in] absolute time for timeout, in jiffies.
> >
> > I don't quite like this, I think we should keep the styl of all other
> > wait_*_timeout functions and pass the arg as timeout in jiffies (and also
> > the same return semantics). Otherwise well have funny code that needs to
> > handle return values differently depending upon whether it waits upon a
> > dma_fence or a native object (where it would us the wait_*_timeout
> > functions directly).
>
> We did start out this way, but there was an ugly jiffies roll-over
> problem that was difficult to deal with properly. Using an absolute
> time avoided the problem.
Well, as-is the api works differently than all the other _timeout apis
I've seen in the kernel, which makes it confusing. Also, I don't quite see
what jiffies wraparound issue there is?
> > Also, I think we should add the non-_timeout variants, too, just for
> > completeness.
This request here has the same reasons, essentially: If we offer a
dma_fence wait api that matches the usual wait apis closely, it's harder
to get their usage wrong. I know that i915 has some major cludge for a
wait_seqno interface internally, but that's no reason to copy that
approach ;-)
Cheers, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-08-11 19:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-10 14:57 [PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER Maarten Lankhorst
2012-08-10 14:57 ` [PATCH 2/4] dma-fence: dma-buf synchronization (v8 ) Maarten Lankhorst
2012-08-10 20:29 ` [Linaro-mm-sig] " Daniel Vetter
2012-08-11 15:14 ` Rob Clark
2012-08-11 16:00 ` Maarten Lankhorst
2012-08-11 19:39 ` Daniel Vetter
2012-08-13 12:43 ` Maarten Lankhorst
2012-08-11 19:22 ` Daniel Vetter [this message]
2012-08-11 20:50 ` Rob Clark
2012-08-12 9:34 ` Daniel Vetter
2012-08-29 17:49 ` Francesco Lavra
2012-08-10 14:57 ` [PATCH 3/4] dma-seqno-fence: Hardware dma-buf implementation of fencing (v2) Maarten Lankhorst
2012-08-10 19:57 ` [Linaro-mm-sig] " Daniel Vetter
2012-08-11 16:05 ` Maarten Lankhorst
2012-08-10 14:58 ` [PATCH 4/4] dma-buf-mgr: multiple dma-buf synchronization (v3) Maarten Lankhorst
2012-08-15 23:12 ` [Linaro-mm-sig] " Daniel Vetter
2012-08-22 11:50 ` [RFC patch 4/4] " Maarten Lankhorst
2012-08-22 12:52 ` Thomas Hellstrom
2012-08-22 13:32 ` Maarten Lankhorst
2012-08-22 14:12 ` Thomas Hellstrom
2012-08-22 15:13 ` Daniel Vetter
2012-08-10 19:32 ` [Linaro-mm-sig] [PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER Daniel Vetter
2012-08-11 15:17 ` Rob Clark
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=20120811192247.GB5132@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@canonical.com \
--cc=rob.clark@linaro.org \
--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).