Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1313274

Re: [RFC 00/29] De-stage android's sync framework

Show all headers | View raw

Op 20-01-16 om 15:32 schreef Gustavo Padovan:
> 2016-01-20 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
>
>> Hey,
>>
>> Op 15-01-16 om 15:55 schreef Gustavo Padovan:
>>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>>>
>>> This patch series de-stage the sync framework, and in order to accomplish that
>>> a bunch of cleanups/improvements on the sync and fence were made.
>>>
>>> The sync framework contained some abstractions around struct fence and those
>>> were removed in the de-staging process among other changes:
>>>
>>> Userspace visible changes
>>> -------------------------
>>>
>>>  * The sw_sync file was moved from /dev/sw_sync to <debugfs>/sync/sw_sync. No
>>>  other change.
>>>
>>> Kernel API changes
>>> ------------------
>>>
>>>  * struct sync_timeline is now struct fence_timeline
>>>  * sync_timeline_ops is now fence_timeline_ops and they now carry struct
>>>  fence as parameter instead of struct sync_pt
>>>  * a .cleanup() fence op was added to allow sync_fence to run a cleanup when
>>>  the fence_timeline is destroyed
>>>  * added fence_add_used_data() to pass a private point to struct fence. This
>>>  pointer is sent back on the .cleanup op.
>>>  * The sync timeline function were moved to be fence_timeline functions:
>>> 	 - sync_timeline_create()	-> fence_timeline_create()
>>> 	 - sync_timeline_get()		-> fence_timeline_get()
>>> 	 - sync_timeline_put()		-> fence_timeline_put()
>>> 	 - sync_timeline_destroy()	-> fence_timeline_destroy()
>>> 	 - sync_timeline_signal()	-> fence_timeline_signal()
>>>
>>>   * sync_pt_create() was replaced be fence_create_on_timeline()
>>>
>>> Internal changes
>>> ----------------
>>>
>>>  * fence_timeline_ops was removed in favor of direct use fence_ops
>>>  * fence default functions were created for fence_ops
>>>  * removed structs sync_pt, sw_sync_timeline and sw_sync_pt
>>>
>>> Gustavo Padovan (29):
>>>   staging/android: fix sync framework documentation
>>>   staging/android: fix checkpatch warning
>>>   staging/android: rename sync_fence_release
>>>   staging/android: rename 'android_fence' to 'sync_fence'
>>>   staging/android: remove not used sync_timeline ops
>>>   staging/android: create a 'sync' dir for debugfs information
>>>   staging/android: move sw_sync file to debugfs file
>>>   staging/android: Remove WARN_ON_ONCE when releasing sync_fence
>>>   staging/android: rename struct sync_fence's variables to 'sync_fence'
>>>   staging/android: rename 'sync_pt' to 'fence' in struct sync_fence_cb
>>>   dma-buf/fence: move sync_timeline to fence_timeline
>>>   staging/android: remove struct sync_pt
>>>   dma-buf/fence: create fence_default_enable_signaling()
>>>   dma-buf/fence: create fence_default_release()
>>>   dma-buf/fence: create fence_default_get_driver_name()
>>>   dma-buf/fence: create fence_default_timeline_name()
>> This is misleading. I think timeline_fence prefix would be more appropriate here.
> Why? These fence_default_.. functions are fence_ops and not related to
> fence_timeline in any way.
Because they're using fence_parent, which should probably be renamed to fence_to_timeline()

The name makes it sound as if they could apply to all type of fences, I don't think this is the case.
>> I also believe this should be done in multiple series. First series should de-stage the userspace fence framework. The next series should fix up android_fence and maybe rename it to timeline_fence since sync_fence is already used for the userspace fd, which would add more confusion?
> Sure. I've been thinking on how to split this properly. I'm trying to
> add a bunch of clean up/renaming first, eg the sync_fence rename to
> sync_file that Daniel Vetter and I discussed. 
>
> Next my plan would be move sync_timeline to fence_timeline, add the
> fence_default.. fence_ops, clean up sw_sync and finally merge
> fence_context and fence_timeline.
>
> Looking at how sync and fence It looks easier to me to de-stage sync_timeline first than userspace
> fence.
There's already code to add a sync_fence_create_dma export [1][2]. So if you want to de-stage it then there will be users for it.

sync_pt otoh has no upstream in-kernel users. It was a wrapper to keep android drivers api compatible with the fence api.

[1] https://patchwork.freedesktop.org/patch/67845/
[2] https://patchwork.freedesktop.org/patch/67846/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC 00/29] De-stage android's sync framework Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:00 +0100
  [RFC 19/29] dma-buf/fence: create fence_default_fill_driver_data() Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:00 +0100
  [RFC 15/29] dma-buf/fence: create fence_default_get_driver_name() Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:00 +0100
  [RFC 29/29] dma-buf/fence: de-stage sync framework Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:00 +0100
  [RFC 26/29] dma-buf/fence: remove pointless fence_timeline_signal at destroy phase Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:00 +0100
    Re: [RFC 26/29] dma-buf/fence: remove pointless fence_timeline_signal  at destroy phase John Harrison <John.C.Harrison@Intel.com> - 2016-01-15 18:50 +0100
      Re: [RFC 26/29] dma-buf/fence: remove pointless  fence_timeline_signal at destroy phase Gustavo Padovan <gustavo.padovan@collabora.co.uk> - 2016-01-15 19:10 +0100
        Re: [RFC 26/29] dma-buf/fence: remove pointless fence_timeline_signal  at destroy phase Greg Hackmann <ghackmann@google.com> - 2016-01-16 00:50 +0100
  [RFC 08/29] staging/android: Remove WARN_ON_ONCE when releasing sync_fence Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:10 +0100
  [RFC 02/29] staging/android: fix checkpatch warning Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:10 +0100
  [RFC 11/29] dma-buf/fence: move sync_timeline to fence_timeline Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:10 +0100
    Re: [RFC 11/29] dma-buf/fence: move sync_timeline to fence_timeline Greg Hackmann <ghackmann@google.com> - 2016-01-20 02:00 +0100
  [RFC 13/29] dma-buf/fence: create fence_default_enable_signaling() Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:10 +0100
  [RFC 05/29] staging/android: remove not used sync_timeline ops Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:10 +0100
  [RFC 14/29] dma-buf/fence: create fence_default_release() Gustavo Padovan <gustavo@padovan.org> - 2016-01-15 16:10 +0100
  Re: [RFC 00/29] De-stage android's sync framework Joe Perches <joe@perches.com> - 2016-01-15 20:20 +0100
  Re: [RFC 00/29] De-stage android's sync framework Daniel Vetter <daniel@ffwll.ch> - 2016-01-19 12:10 +0100
    Re: [RFC 00/29] De-stage android's sync framework Gustavo Padovan <gustavo@padovan.org> - 2016-01-19 16:30 +0100
      Re: [RFC 00/29] De-stage android's sync framework John Harrison <John.C.Harrison@Intel.com> - 2016-01-19 17:20 +0100
        Re: [RFC 00/29] De-stage android's sync framework Gustavo Padovan <gustavo@padovan.org> - 2016-01-19 19:00 +0100
          Re: [RFC 00/29] De-stage android's sync framework Daniel Vetter <daniel@ffwll.ch> - 2016-01-19 19:10 +0100
            Re: [RFC 00/29] De-stage android's sync framework Gustavo Padovan <gustavo@padovan.org> - 2016-01-19 19:20 +0100
    Re: [RFC 00/29] De-stage android's sync framework Gustavo Padovan <gustavo@padovan.org> - 2016-01-19 21:20 +0100
      Re: [RFC 00/29] De-stage android's sync framework Daniel Vetter <daniel@ffwll.ch> - 2016-01-19 21:40 +0100
  Re: [RFC 00/29] De-stage android's sync framework Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-01-20 11:30 +0100
    Re: [RFC 00/29] De-stage android's sync framework Gustavo Padovan <gustavo@padovan.org> - 2016-01-20 15:40 +0100
      Re: [RFC 00/29] De-stage android's sync framework Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-01-20 16:10 +0100
        Re: [RFC 00/29] De-stage android's sync framework Daniel Vetter <daniel@ffwll.ch> - 2016-01-20 17:30 +0100
        Re: [RFC 00/29] De-stage android's sync framework Gustavo Padovan <gustavo@padovan.org> - 2016-01-20 19:30 +0100

csiph-web