Re: [RFC 3/9] staging/android/sync: Move sync framework out of staging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14/01/2016 13:42, Gustavo Padovan wrote:
Hi John,

2016-01-14 John Harrison <John.C.Harrison@xxxxxxxxx>:

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?
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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux