[Intel-gfx] [PATCH 2/5] drm/i915: Introduce i915_timeline.mutex

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-03-01 11:38:11)
> 
> On 01/03/2019 11:05, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c b/drivers/gpu/drm/i915/selftests/mock_timeline.c
> > index d2de9ece2118..416d85233263 100644
> > --- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
> > +++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
> > @@ -14,6 +14,7 @@ void mock_timeline_init(struct i915_timeline *timeline, u64 context)
> >       timeline->fence_context = context;
> >   
> >       spin_lock_init(&timeline->lock);
> > +     mutex_init(&timeline->mutex);
> >   
> >       INIT_ACTIVE_REQUEST(&timeline->barrier);
> >       INIT_ACTIVE_REQUEST(&timeline->last_request);
> > 
> 
> So hard to predict if this will be okay in the future and keep a mental 
> image of the endgame in ones head.

Yeah, it'll change anyway as soon as we meet the enemy.

At the moment, it seems a fundamental mutex that we can't avoid, the
timeline must be serialised (for access to the ring and seqno, request
construct must be sequential) and from there we extend it to cover
retirement and activity tracking. It may be that we can split the mutex
further (allow for parallel construction and retirement? but that seems
an unlikely win since timeline == client and so we expect to parcel work
up into timeline/client bundles), but for now timeline->mutex seems like
a solid plan of action. (At least it gets us as far as allowing clients
to submit requests independently, after that my crystal ball is cloudy.)
-Chris