On 11/09/2020 07:44, Lucas De Marchi wrote:
On Fri, Sep 04, 2020 at 01:59:28PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it fr
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2:
* Don't bother supporting selftests contexts from debugfs. (Chris)
v3:
* Trivial rebase.
On 11/09/2020 07:44, Lucas De Marchi wrote:
On Fri, Sep 04, 2020 at 01:59:28PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it fr
On Fri, Sep 04, 2020 at 01:59:28PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2:
* Don't bother supporting
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2:
* Don't bother supporting selftests contexts from debugfs. (Chris)
v3:
* Trivial rebase.
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2:
* Don't bother supporting selftests contexts from debugfs. (Chris)
Signed-off-by: Tvrtko U
