[Intel-gfx] [PATCH v3 0/3] improve handling of the driver's internal (default) context

[Dave Gordon]

During startup, the driver creates a unique "intel_context" that will
provide a home for orphan requests (i.e. those generated by the driver
internally, not associated with user batchbuffers).

However, one of the infelicities of the current code is that the driver
keeps a per-engine pointer to the default context for that engine (this
is probably from a decision made early in execlists implementation,
when it was thought that a context was engine-specific, and not revised
when it was decided that an "intel_context" represents a multiplex of
engine-level contexts). All these per-engine pointers actually end up
pointing to the same unique object.

To compound this, the refcounting is bogus; the driver holds just one
reference to the default context, even though there are multiple pointers
to it (RCS is considered to hold this "on behalf of" the other engines,
but this can lead to problems during unload as it makes the code sensitive
to the order of engine teardown -- RCS should be done last, but it isn't).

Also, some of the execlists batch submission code treats the default
context differently from any other; testing for it by comparing against
the per-engine pointer is quite clumsy, especially in debugfs where
contexts are enumerated from a global list and therefore not automatically
known to be associated with a particular engine.

Therefore, we should replace the per-engine pointers with a single
driver-wide reference, which will make the refcounting sane and simplify
the code that uses this context for non-user-related requests.

THIS patchset does NOT address the execlists code's special handling of
the default context, but it will simplify the planned future cleanup of
that code.

v3: don't flag the context created during startup (and fully instantiated
on all engines) for driver-internal purposes as "is_global_default",
1448630935-27377-1-git-send-email-chris at chris-wilson.co.uk notwithstanding.
[Chris Wilson] (We now call it "the kernel context", and compare against
the device-wide pointer).