From: Gustavo Padovan <gustavo.padovan@collabora.com>
To: "Chris Wilson" <chris@chris-wilson.co.uk>,
"Gustavo Padovan" <gustavo@padovan.org>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Daniel Stone" <daniels@collabora.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Rob Clark" <robdclark@gmail.com>,
"Greg Hackmann" <ghackmann@google.com>,
"John Harrison" <John.C.Harrison@Intel.com>,
laurent.pinchart@ideasonboard.com, seanpaul@google.com,
marcheu@google.com, m.chehab@samsung.com,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [RFC v2 3/3] dma-buf/sync_file: rework fence storage in struct file
Date: Tue, 28 Jun 2016 11:25:00 -0300 [thread overview]
Message-ID: <20160628142500.GK2508@joana> (raw)
In-Reply-To: <20160628080221.GB25424@nuc-i3427.alporthouse.com>
2016-06-28 Chris Wilson <chris@chris-wilson.co.uk>:
> On Mon, Jun 27, 2016 at 04:29:22PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > Create sync_file->fence to abstract the type of fence we are using for
> > each sync_file. If only one fence is present we use a normal struct fence
> > but if there is more fences to be added to the sync_file a fence_array
> > is created.
> >
> > This change cleans up sync_file a bit. We don't need to have sync_file_cb
> > array anymore. Instead, as we always have one fence, only one fence
> > callback is registered per sync_file.
> >
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > ---
> > @@ -76,21 +76,19 @@ struct sync_file *sync_file_create(struct fence *fence)
> > {
> > struct sync_file *sync_file;
> >
> > - sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]));
> > + sync_file = sync_file_alloc();
> > if (!sync_file)
> > return NULL;
> >
> > - sync_file->num_fences = 1;
> > + sync_file->fence = fence;
> > +
> > atomic_set(&sync_file->status, 1);
>
> sync_file->status => fence_is_signaled(sync_file->fence);
>
> Both should just be an atomic read, except fence_is_signaled() will then
> do a secondary poll.
Not sure I follow. I set it to 1 here, but below when we call
fence_add_callback() and the fence is already signalled atomic_dec sets
sync_file->status to 0.
>
> > snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
> > fence->ops->get_driver_name(fence),
> > fence->ops->get_timeline_name(fence), fence->context,
> > fence->seqno);
> >
> > - sync_file->cbs[0].fence = fence;
> > - sync_file->cbs[0].sync_file = sync_file;
> > - if (fence_add_callback(fence, &sync_file->cbs[0].cb,
> > - fence_check_cb_func))
> > + if (fence_add_callback(fence, &sync_file->cb, fence_check_cb_func))
> > atomic_dec(&sync_file->status);
> >
> > return sync_file;
> > @@ -121,14 +119,42 @@ err:
> > return NULL;
> > }
> >
> > -static void sync_file_add_pt(struct sync_file *sync_file, int *i,
> > - struct fence *fence)
> > +static int sync_file_set_fence(struct sync_file *sync_file,
> > + struct fence **fences, int num_fences)
> > {
> > - sync_file->cbs[*i].fence = fence;
> > - sync_file->cbs[*i].sync_file = sync_file;
> > + struct fence_array *array;
> > +
> > + if (num_fences == 1) {
> > + sync_file->fence = fences[0];
>
> This steals the references.
>
> > + } else {
> > + array = fence_array_create(num_fences, fences,
> > + fence_context_alloc(1), 1, false);
>
> This creates a reference.
>
> When we call fence_put(sync_fence->fence) we release a reference we
> never owned if num_fences == 1.
No, sync_file_merge() gets a new reference for each fence it is going to
add to the new fence. So for num_fences == 1 when sync_file->fence is
set we already hold a reference to it, so no matter if it is a fence or
a array we own a reference.
>
> > + struct fence **fences, **a_fences, **b_fences;
> > + int i, i_a, i_b, num_fences, a_num_fences, b_num_fences;
> >
> > + a_fences = get_fences(a, &a_num_fences);
> > + b_fences = get_fences(b, &b_num_fences);
> > + num_fences = a_num_fences + b_num_fences;
> > +
> > + fences = kcalloc(num_fences, sizeof(**fences), GFP_KERNEL);
>
> Just sizeof(*fences) (you want to allocate an array of pointers, not an
> array of fence structs).
Okay.
Gustavo
next prev parent reply other threads:[~2016-06-28 14:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-27 19:29 [RFC v2 0/3] dma-buf/sync_file: rework fences on struct sync_file Gustavo Padovan
2016-06-27 19:29 ` Gustavo Padovan
2016-06-27 19:29 ` [RFC v2 1/3] dma-buf/fence-array: add fence_is_array() Gustavo Padovan
2016-06-27 19:29 ` Gustavo Padovan
2016-06-27 19:29 ` [RFC v2 2/3] dma-buf/fence-array: add fence_array_teardown() Gustavo Padovan
2016-06-28 9:56 ` Christian König
2016-06-28 9:56 ` Christian König
2016-06-28 14:17 ` Gustavo Padovan
2016-06-28 15:05 ` Christian König
2016-06-28 15:05 ` Christian König
2016-06-28 15:17 ` Gustavo Padovan
2016-06-27 19:29 ` [RFC v2 3/3] dma-buf/sync_file: rework fence storage in struct file Gustavo Padovan
2016-06-27 19:29 ` Gustavo Padovan
2016-06-28 8:02 ` Chris Wilson
2016-06-28 8:02 ` Chris Wilson
2016-06-28 14:25 ` Gustavo Padovan [this message]
2016-06-28 15:09 ` Chris Wilson
2016-06-28 15:09 ` Chris Wilson
2016-06-28 15:27 ` 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=20160628142500.GK2508@joana \
--to=gustavo.padovan@collabora.com \
--cc=John.C.Harrison@Intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ghackmann@google.com \
--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=maarten.lankhorst@linux.intel.com \
--cc=marcheu@google.com \
--cc=robdclark@gmail.com \
--cc=seanpaul@google.com \
--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 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.