Fence, timeline and android sync points

[Rob Clark]

On Thu, Aug 14, 2014 at 10:12 AM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Thu, Aug 14, 2014 at 09:16:02AM -0400, Rob Clark wrote:
>> On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
>> > So this is fundamentaly different, fence as they are now allow random driver
>> > callback and this is bound to get ugly this is bound to lead to one driver
>> > doing something that seems innocuous but turn out to break heavoc when call
>> > from some other driver function.
>>
>>
>> tbh, that seems solvable by some strict rules about what you can do in
>> the callback.. ie. don't do anything you couldn't do in atomic, and
>> don't signal another fence.. off the top of my head that seems
>> sufficient.
>>
>> If the driver getting the callback needs to do more, then it can
>> always schedule a worker..
>>
>> But I could certainly see the case where the driver waiting on fence
>> sets everything up before installing the cb and then just needs to
>> write one or a couple regs from the cb.
>
> Yes sane code will do sane things, sadly i fear we can not enforce sane
> code everywhere especialy with out of tree driver and i would rather
> force there hand to only allow sane implementation. Providing call back
> api obviously allows them to do crazy stuff.

callback's hard, let's go shopping..

But seriously, we've solved problems like this w/ various kernel debug
features before.  I am pretty sure we could make lock debugging, and
maybe some new fence debugging option, catch a lot of things.  There
is probably a better way, but a dummy spinlock around the callback, or
maybe preempt_enable()/disable() around the callback?  And we should
be able to come up with a way to catch signalling a fence from cb..

A bit of extra rope with a warning sign not to hang yourself and debug
features to tell people when they are hanging themselves seems like
the better option to me.

BR,
-R

>>
>> BR,
>> -R