restart syncobj timeline changes

[Christian König]

Ok that turned out to be more problematic than I ever thought it would be.

Taking a closer look I've found that the previous timeline implementation not only had a number of implementation bugs, but also some fundamental design problems.

Especially we can't enforce that fences are added in the correct order, e.g. when a new timeline fence is added it can in theory be that another one was added in the meantime and we can't guarantee the correct order any more.

So this new set of patches does a conservative approach on handling those kinds of errors. When userspace does something broken it can keep the pieces, but the kernel will always make sure that it does the right thing (e.g. not leak memory, crash, corrupt data, etc....).

What I've did to the implementation is to split up the patch into smaller pieces and move out most of the logic into a new dma-fence-chain container.

This way we can make sure that we don't run into resource management problems (the container is garbage collected) and at the same time minimize the changes to the existing drm_syncobj implementation to make sure not to regress any existing users.

The whole set is only barely smoke tested, cause I wanted to get feedback as early as possible on this. But as far as I can see at least this approach should work in general.

Please comment and/or review,
Christian.