On Thu, Aug 04, 2016 at 06:18:53PM -0300, Gustavo Padovan wrote:
2016-08-03 Chris Wilson chris@chris-wilson.co.uk:
On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.padovan@collabora.co.uk
Signalling doesn't need to be enabled at sync_file creation, it is only required if userspace waiting the fence to signal through poll().
Thus we delay fence_add_callback() until poll is called. It only adds the callback the first time poll() is called. This avoid re-adding the same callback multiple times.
v2: rebase and update to work with new fence support for sync_file
v3: use atomic operation to set enabled and protect fence_add_callback()
There's actually a spare bit in fence->flags you can use for this.
#define POLL_ENABLED FENCE_FLAG_USER_BITS
Wouldn't it be better to add a new bit to fence_flags_bit?
sync_file is a user of struct fence, so it should claim one of the bits already reserved for users. Those reserved bits are meant only for the owner of the fence, if we did indeed need to share that bit with other consumers of the sync_file->fence_array then adding it to fence_flags_bits make sense. I don't see any reason at present why it should be anything other than a private bit to sync_file atm.
Promoting it later (from private to shared) would also not be an issue. -Chris