srinivasa...@intel.com writes:
> From: Srinivasan S
>
> drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within
> kernel
>
> This patch sets improves GPU power consumption on Linux kernel based OS such
> as
> Chromium OS, Ubuntu, etc. Following are the power savings.
>
>
Replace the use of printk based drm logging macros with the struct
drm_device based logging macros.
Note that this converts DRM_DEBUG_DRIVER() to drm_dbg().
References:
https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga
---
Replace the use of the printk based drm logging macros with the struct
drm_device based logging macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c
Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros.
Note that this converts DRM_DEBUG_DRIVER() to drm_dbg() but does not
convert DRM_DEBUG() due to the lack of an analogous drm_device based
macro.
References:
Replace the use of the printk based drm logging macros with the struct
drm_device based logging macros in i915/gt/intel_rps.c. This also
involves extracting the drm_i915_private device pointer from various
intel types.
This converts the instances of DRM_DEBUG_DRIVER to drm_dbg() while not
Replace the use of printk based drm logging macros to the struct
drm_device based logging macros in i915/gt/intel_ring_submission.c.
This was done using the following semantic patch that transforms based
on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@
fn(...) {
...
struct
This patchset continues the conversion of printk based macros to use
the struct drm_device based drm logging macros focused on the i915/gt
folder.
These patches were achieved using both coccinelle and manually.
Wambui Karuga (7):
drm/i915/ggtt: convert to drm_device based logging macros.
Converts various instances of the printk based drm logging macros to use
the struct drm_device logging macros. This also involves extracting the
drm_i915_private device from intel types in some cases.
Note that this converts DRM_DEBUG_DRIVER() to drm_dbg().
References:
Converts various instances of the printk based drm logging macros to use
the struct drm_device based logging macros in i915/gt/intel_ggtt.c.
This change was done using the following coccinelle script that matches
based on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@
fn(...)
Make the GT responsible for restoring its fence when it wakes up from
suspend.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_gem.c
Since the number of fence regs can vary dramactically between platforms,
allocate the array on demand so we don't waste as much space.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 --
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 10 ++
If we must revoke the fence because the VMA is no longer present, or
because the fence no longer applies, ensure that we do and convert it
into an error if we try but cannot.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 20 +++-
Since we always reload the fence register state on runtime resume,
having it explicitly in the S0ix resume code is redundant. Indeed, it
is not even being used!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git
Make a copy of the object tiling parameters at the point of grabbing the
fence.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 18 ++
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 2 ++
2 files changed, 12 insertions(+), 8 deletions(-)
diff
Since the fence registers control HW detiling throught the GGTT
aperture, make them a part of the intel_ggtt under gt/
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
.../intel_ggtt_fencing.c}
Only GPU activity via the GGTT fence is asynchronous, we know that we
control the CPU access directly, so we only need to wait for the GPU to
stop using the fence before we relinquish it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 12
On 13/03/2020 17:26, Tvrtko Ursulin wrote:
On 13/03/2020 14:34, Lionel Landwerlin wrote:
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the
A little bit of history :
Back when i915-perf was introduced (4.13), there was no way to
dynamically add new OA configurations to i915. Only the generated
configs baked in at build time were allowed.
It quickly became obvious that we would need to allow applications
to upload
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As
The caller of i915_oa_init_reg_state() already sets this.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index
20 matches
Mail list logo
