[Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging
John Harrison
John.C.Harrison at Intel.com
Thu Jan 14 03:31:34 PST 2016
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?
Do you have an expected time scale for when your patches will land?
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?
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?
Thanks,
John.
More information about the Intel-gfx
mailing list