On 13/01/2016 19:00, Gustavo Padovan wrote:
Hi John,
2016-01-13 John.C.Harrison@xxxxxxxxx <John.C.Harrison@xxxxxxxxx>:
From: John Harrison <John.C.Harrison@xxxxxxxxx>
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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
