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

[John Harrison]

On 14/01/2016 13:42, Gustavo Padovan wrote:
> 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.
Make sure to CC myself and hopefully I should be able to do some 
testing/reviewing for you.

>> 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.
Okay, that sounds easy enough :).

Daniel Vetter, do you see any issues with using this in an IGT test?


>
> 	Gustavo