[Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging

[Gustavo Padovan]

Hi John,

2016-01-14 John Harrison <John.C.Harrison at Intel.com>:

> On 13/01/2016 19:00, Gustavo Padovan wrote:
> >Hi John,
> >
> >2016-01-13 John.C.Harrison at Intel.com <John.C.Harrison at Intel.com>:
> >
> >>From: John Harrison <John.C.Harrison at Intel.com>
> >>
> >>The sync framework is now used by the i915 driver. Therefore it can be
> >>moved out of staging and into the regular tree. Also, the public
> >>interfaces can actually be made public and exported.
> >I also have been working on de-staging the sync framework, but I've
> >taken the approach of cleaning up the sync framework first. e.g., I got
> >rid of sync_pt and use struct fence directly, also sync_timeline is now
> >fence_timeline and its ops are gone in favor of fence_ops. My current
> >work is here:
> >
> >https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync
> >
> >My current plan is clean up patches, add commits messages and document
> >the changes I've made and then it should be ready for a RFC.
> >
> >	Gustavo
> Hello,
> 
> Sounds good. I did note in my cover letter that these patches were only
> being posted to let people review the i915 side of the changes on a complete
> and working tree. Once we found out you were working on the de-stage the
> decision was to let you get on with it and not duplicate the effort here :).
> Note that patches four and five of this series are enhancements to the sync
> code rather than just de-staging it. Would they still be applicable to your
> new and improved version?

Yes, with a small rework we can surely apply them on top of my changes.

> Do you have an expected time scale for when your patches will land?

I hope to send a RFC sometime next week, after that it will depend on
how many comments and iterations I get from upstream.

> Also, do you have any sort of overview document explaining what externally
> visible changes you are making and what the implications are for other
> drivers that are using the API?

Not yet. But I'll write one. In short: SW_SYNC didn't change from API
point of view. And I replaced sync_timeline with fence_timeline and
sync_pt with fence changing the respective functions name, e.g.,
sync_timeline_create is now fence_timeline_create.

> 
> Re the SW_SYNC_USER bits, we were just using that for a user land test
> program. The idea was to create an timeline external to the i915 driver and
> pass sync points in to i915 to be waited on and check that the i915 work
> itself only happens after the test signals the timeline appropriately. If
> this interface is going away, is there a plan to replace it with any other
> mechanism for doing similar? Or do we have to create some kind of dummy
> kernel module in order to get a testing timeline?

I've moved it to debugfs. You just need to point your test program to
<debugfs>/sync/sw_sync and everything will continue to work.

	Gustavo