2021-01-23 03:29:04 +08:00
|
|
|
/* SPDX-License-Identifier: MIT */
|
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
|
|
|
/*
|
|
|
|
|
* Copyright © 2019 Intel Corporation
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef INTEL_GT_PM_H
|
|
|
|
|
#define INTEL_GT_PM_H
|
|
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
|
2019-08-02 07:36:16 +08:00
|
|
|
#include "intel_gt_types.h"
|
|
|
|
|
#include "intel_wakeref.h"
|
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
|
|
|
|
2019-08-09 04:27:58 +08:00
|
|
|
static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
return intel_wakeref_is_active(>->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void intel_gt_pm_get(struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
intel_wakeref_get(>->wakeref);
|
|
|
|
|
}
|
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
|
|
|
|
2019-11-21 21:05:28 +08:00
|
|
|
static inline void __intel_gt_pm_get(struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
__intel_wakeref_get(>->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-02 07:36:16 +08:00
|
|
|
static inline bool intel_gt_pm_get_if_awake(struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
return intel_wakeref_get_if_active(>->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-15 01:19:43 +08:00
|
|
|
static inline void intel_gt_pm_might_get(struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
intel_wakeref_might_get(>->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-09 04:27:58 +08:00
|
|
|
static inline void intel_gt_pm_put(struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
intel_wakeref_put(>->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-20 20:54:33 +08:00
|
|
|
static inline void intel_gt_pm_put_async(struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
intel_wakeref_put_async(>->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-15 01:19:43 +08:00
|
|
|
static inline void intel_gt_pm_might_put(struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
intel_wakeref_might_put(>->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-15 01:19:42 +08:00
|
|
|
#define with_intel_gt_pm(gt, tmp) \
|
|
|
|
|
for (tmp = 1, intel_gt_pm_get(gt); tmp; \
|
|
|
|
|
intel_gt_pm_put(gt), tmp = 0)
|
|
|
|
|
|
2019-08-09 04:27:58 +08:00
|
|
|
static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
|
|
|
|
|
{
|
|
|
|
|
return intel_wakeref_wait_for_idle(>->wakeref);
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-21 15:07:43 +08:00
|
|
|
void intel_gt_pm_init_early(struct intel_gt *gt);
|
2019-09-27 19:08:49 +08:00
|
|
|
void intel_gt_pm_init(struct intel_gt *gt);
|
|
|
|
|
void intel_gt_pm_fini(struct intel_gt *gt);
|
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
|
|
|
|
2019-11-01 22:10:09 +08:00
|
|
|
void intel_gt_suspend_prepare(struct intel_gt *gt);
|
|
|
|
|
void intel_gt_suspend_late(struct intel_gt *gt);
|
2019-06-26 23:45:49 +08:00
|
|
|
int intel_gt_resume(struct intel_gt *gt);
|
2019-09-27 19:08:49 +08:00
|
|
|
|
2019-08-01 08:57:09 +08:00
|
|
|
void intel_gt_runtime_suspend(struct intel_gt *gt);
|
|
|
|
|
int intel_gt_runtime_resume(struct intel_gt *gt);
|
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
|
|
|
|
2020-12-15 23:44:56 +08:00
|
|
|
ktime_t intel_gt_get_awake_time(const struct intel_gt *gt);
|
|
|
|
|
|
2019-09-27 19:08:49 +08:00
|
|
|
static inline bool is_mock_gt(const struct intel_gt *gt)
|
|
|
|
|
{
|
2019-09-28 05:17:48 +08:00
|
|
|
return I915_SELFTEST_ONLY(gt->awake == -ENODEV);
|
2019-09-27 19:08:49 +08:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
#endif /* INTEL_GT_PM_H */
|