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

From: John Harrison <John.C.Harrison@Intel.com>
To: Gustavo Padovan <gustavo@padovan.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	Intel-GFX@Lists.FreeDesktop.Org,
	"Arve Hjønnevåg" <arve@android.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"Riley Andrews" <riandrews@android.com>
Subject: Re: [RFC 3/9] staging/android/sync: Move sync framework out of staging
Date: Thu, 14 Jan 2016 11:31:34 +0000	[thread overview]
Message-ID: <56978716.30409@Intel.com> (raw)
In-Reply-To: <20160113190000.GA29496@joana>

On 13/01/2016 19:00, Gustavo Padovan wrote:
> Hi John,
>
> 2016-01-13 John.C.Harrison@Intel.com <John.C.Harrison@Intel.com>:
>
>> From: John Harrison <John.C.Harrison@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.

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