From: Chris Wilson <chris@chris-wilson.co.uk>
To: Gustavo Padovan <gustavo@padovan.org>
Cc: dri-devel@lists.freedesktop.org, marcheu@google.com,
Daniel Stone <daniels@collabora.com>,
seanpaul@google.com, Daniel Vetter <daniel.vetter@ffwll.ch>,
linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com,
Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
John Harrison <John.C.Harrison@Intel.com>,
m.chehab@samsung.com
Subject: Re: [RFC 5/5] dma-buf/sync_file: rework fence storage in struct file
Date: Thu, 23 Jun 2016 22:27:24 +0100 [thread overview]
Message-ID: <20160623212724.GD1086@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <1466695790-2833-6-git-send-email-gustavo@padovan.org>
On Thu, Jun 23, 2016 at 12:29:50PM -0300, Gustavo Padovan wrote:
> -static void sync_file_add_pt(struct sync_file *sync_file, int *i,
> +static int sync_file_set_fence(struct sync_file *sync_file,
> + struct fence **fences)
> +{
> + struct fence_array *array;
> +
> + if (sync_file->num_fences == 1) {
> + sync_file->fence = fences[0];
Straightforward pointer assignment.
> + } else {
> + array = fence_array_create(sync_file->num_fences, fences,
> + fence_context_alloc(1), 1, false);
> + if (!array)
> + return -ENOMEM;
> +
> + sync_file->fence = &array->base;
New reference.
Imbalance will promptly go bang after we release the single fence[0].
Would fence_array_create(1, fence) returning fence_get(fence) be too
much of a hack?
I would suggest dropping the exported fence_get_fences() and use a local
instead that could avoid the copy, e.g.
static struct fence *get_fences(struct fence **fence,
unsigned int *num_fences)
{
if (fence_is_array(*fence)) {
struct fence_array *array = to_fence_array(*fence);
*num_fences = array->num_fences;
return array->fences;
} else {
*num_fences = 1;
return fence;
}
}
sync_file_merge() {
int num_fences, num_a_fences, num_b_fences;
struct fence **fences, **a_fences, **b_fences;
a_fences = get_fences(&a, &num_a_fences);
b_fences = get_fences(&b, &num_b_fences);
num_fences = num_a_fences + num_b_fences;
> static void sync_file_free(struct kref *kref)
> {
> struct sync_file *sync_file = container_of(kref, struct sync_file,
> kref);
> - int i;
> -
> - for (i = 0; i < sync_file->num_fences; ++i) {
> - fence_remove_callback(sync_file->cbs[i].fence,
> - &sync_file->cbs[i].cb);
> - fence_put(sync_file->cbs[i].fence);
> - }
>
> + fence_remove_callback(sync_file->fence, &sync_file->cb);
> + fence_teardown(sync_file->fence);
Hmm. Could we detect the removal of the last callback and propagate that
to the fence_array? (Rather then introduce a manual call to
fence_teardown.)
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2016-06-23 21:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-23 15:29 [RFC 0/5] rework fences on struct sync_file Gustavo Padovan
2016-06-23 15:29 ` [RFC 1/5] dma-buf/fence: add .teardown() ops Gustavo Padovan
2016-06-23 20:48 ` Chris Wilson
2016-06-24 13:19 ` Gustavo Padovan
2016-07-12 10:51 ` Daniel Vetter
2016-06-23 15:29 ` [RFC 2/5] dma-buf/fence-array: add fence_array_teardown() Gustavo Padovan
2016-06-23 15:29 ` [RFC 3/5] dma-buf/fence: add .get_fences() ops Gustavo Padovan
2016-06-23 20:40 ` Chris Wilson
2016-07-12 10:52 ` Daniel Vetter
2016-06-23 15:29 ` [RFC 4/5] dma-buf/fence-array: add fence_array_get_fences() Gustavo Padovan
2016-06-23 20:35 ` Chris Wilson
2016-06-23 15:29 ` [RFC 5/5] dma-buf/sync_file: rework fence storage in struct file Gustavo Padovan
2016-06-23 21:27 ` Chris Wilson [this message]
2016-06-24 13:23 ` Gustavo Padovan
2016-06-24 9:27 ` [RFC 0/5] rework fences on struct sync_file Christian König
2016-06-24 13:17 ` Gustavo Padovan
2016-06-24 14:14 ` Christian König
2016-06-24 14:59 ` Gustavo Padovan
2016-06-24 15:09 ` Christian König
2016-06-24 15:19 ` Gustavo Padovan
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=20160623212724.GD1086@nuc-i3427.alporthouse.com \
--to=chris@chris-wilson.co.uk \
--cc=John.C.Harrison@Intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo.padovan@collabora.co.uk \
--cc=gustavo@padovan.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=marcheu@google.com \
--cc=seanpaul@google.com \
/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
all inboxes | Powered by JetHome®