drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 04:07:17 +08:00
|
|
|
/*
|
|
|
|
|
* SPDX-License-Identifier: MIT
|
|
|
|
|
*
|
|
|
|
|
* Copyright © 2019 Intel Corporation
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "i915_drv.h"
|
|
|
|
|
|
|
|
|
|
#include "intel_engine.h"
|
|
|
|
|
#include "intel_engine_pm.h"
|
|
|
|
|
#include "intel_gt_pm.h"
|
|
|
|
|
|
2019-05-03 16:09:42 +08:00
|
|
|
static int __engine_unpark(struct intel_wakeref *wf)
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 04:07:17 +08:00
|
|
|
{
|
|
|
|
|
struct intel_engine_cs *engine =
|
|
|
|
|
container_of(wf, typeof(*engine), wakeref);
|
|
|
|
|
void *map;
|
|
|
|
|
|
|
|
|
|
GEM_TRACE("%s\n", engine->name);
|
|
|
|
|
|
|
|
|
|
intel_gt_pm_get(engine->i915);
|
|
|
|
|
|
|
|
|
|
/* Pin the default state for fast resets from atomic context. */
|
|
|
|
|
map = NULL;
|
|
|
|
|
if (engine->default_state)
|
|
|
|
|
map = i915_gem_object_pin_map(engine->default_state,
|
|
|
|
|
I915_MAP_WB);
|
|
|
|
|
if (!IS_ERR_OR_NULL(map))
|
|
|
|
|
engine->pinned_default_state = map;
|
|
|
|
|
|
|
|
|
|
if (engine->unpark)
|
|
|
|
|
engine->unpark(engine);
|
|
|
|
|
|
|
|
|
|
intel_engine_init_hangcheck(engine);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void intel_engine_pm_get(struct intel_engine_cs *engine)
|
|
|
|
|
{
|
2019-06-14 07:21:56 +08:00
|
|
|
intel_wakeref_get(&engine->i915->runtime_pm, &engine->wakeref, __engine_unpark);
|
2019-05-03 16:09:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void intel_engine_park(struct intel_engine_cs *engine)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* We are committed now to parking this engine, make sure there
|
|
|
|
|
* will be no more interrupts arriving later and the engine
|
|
|
|
|
* is truly idle.
|
|
|
|
|
*/
|
|
|
|
|
if (wait_for(intel_engine_is_idle(engine), 10)) {
|
|
|
|
|
struct drm_printer p = drm_debug_printer(__func__);
|
|
|
|
|
|
|
|
|
|
dev_err(engine->i915->drm.dev,
|
|
|
|
|
"%s is not idle before parking\n",
|
|
|
|
|
engine->name);
|
|
|
|
|
intel_engine_dump(engine, &p, NULL);
|
|
|
|
|
}
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 04:07:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool switch_to_kernel_context(struct intel_engine_cs *engine)
|
|
|
|
|
{
|
|
|
|
|
struct i915_request *rq;
|
|
|
|
|
|
|
|
|
|
/* Already inside the kernel context, safe to power down. */
|
|
|
|
|
if (engine->wakeref_serial == engine->serial)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
/* GPU is pointing to the void, as good as in the kernel context. */
|
|
|
|
|
if (i915_reset_failed(engine->i915))
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Note, we do this without taking the timeline->mutex. We cannot
|
|
|
|
|
* as we may be called while retiring the kernel context and so
|
|
|
|
|
* already underneath the timeline->mutex. Instead we rely on the
|
2019-05-03 16:09:42 +08:00
|
|
|
* exclusive property of the __engine_park that prevents anyone
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 04:07:17 +08:00
|
|
|
* else from creating a request on this engine. This also requires
|
|
|
|
|
* that the ring is empty and we avoid any waits while constructing
|
|
|
|
|
* the context, as they assume protection by the timeline->mutex.
|
|
|
|
|
* This should hold true as we can only park the engine after
|
|
|
|
|
* retiring the last request, thus all rings should be empty and
|
|
|
|
|
* all timelines idle.
|
|
|
|
|
*/
|
|
|
|
|
rq = __i915_request_create(engine->kernel_context, GFP_NOWAIT);
|
|
|
|
|
if (IS_ERR(rq))
|
|
|
|
|
/* Context switch failed, hope for the best! Maybe reset? */
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
/* Check again on the next retirement. */
|
|
|
|
|
engine->wakeref_serial = engine->serial + 1;
|
|
|
|
|
__i915_request_commit(rq);
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-03 16:09:42 +08:00
|
|
|
static int __engine_park(struct intel_wakeref *wf)
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 04:07:17 +08:00
|
|
|
{
|
|
|
|
|
struct intel_engine_cs *engine =
|
|
|
|
|
container_of(wf, typeof(*engine), wakeref);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If one and only one request is completed between pm events,
|
|
|
|
|
* we know that we are inside the kernel context and it is
|
|
|
|
|
* safe to power down. (We are paranoid in case that runtime
|
|
|
|
|
* suspend causes corruption to the active context image, and
|
|
|
|
|
* want to avoid that impacting userspace.)
|
|
|
|
|
*/
|
|
|
|
|
if (!switch_to_kernel_context(engine))
|
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
|
|
GEM_TRACE("%s\n", engine->name);
|
|
|
|
|
|
|
|
|
|
intel_engine_disarm_breadcrumbs(engine);
|
|
|
|
|
|
|
|
|
|
/* Must be reset upon idling, or we may miss the busy wakeup. */
|
|
|
|
|
GEM_BUG_ON(engine->execlists.queue_priority_hint != INT_MIN);
|
|
|
|
|
|
|
|
|
|
if (engine->park)
|
|
|
|
|
engine->park(engine);
|
|
|
|
|
|
|
|
|
|
if (engine->pinned_default_state) {
|
|
|
|
|
i915_gem_object_unpin_map(engine->default_state);
|
|
|
|
|
engine->pinned_default_state = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
engine->execlists.no_priolist = false;
|
|
|
|
|
|
|
|
|
|
intel_gt_pm_put(engine->i915);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void intel_engine_pm_put(struct intel_engine_cs *engine)
|
|
|
|
|
{
|
2019-06-14 07:21:56 +08:00
|
|
|
intel_wakeref_put(&engine->i915->runtime_pm, &engine->wakeref, __engine_park);
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 04:07:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void intel_engine_init__pm(struct intel_engine_cs *engine)
|
|
|
|
|
{
|
|
|
|
|
intel_wakeref_init(&engine->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int intel_engines_resume(struct drm_i915_private *i915)
|
|
|
|
|
{
|
|
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
|
enum intel_engine_id id;
|
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
|
|
intel_gt_pm_get(i915);
|
|
|
|
|
for_each_engine(engine, i915, id) {
|
|
|
|
|
intel_engine_pm_get(engine);
|
|
|
|
|
engine->serial++; /* kernel context lost */
|
|
|
|
|
err = engine->resume(engine);
|
|
|
|
|
intel_engine_pm_put(engine);
|
|
|
|
|
if (err) {
|
|
|
|
|
dev_err(i915->drm.dev,
|
|
|
|
|
"Failed to restart %s (%d)\n",
|
|
|
|
|
engine->name, err);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
intel_gt_pm_put(i915);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|