[Intel-gfx] [drm-intel:for-linux-next 4/7] drivers/gpu/drm/i915/selftests/../i915_gpu_error.h:317:6: error: conflicting types for 'i915_vma_compress_prepare'

tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: 1a8585bd774c4058038ad827c9e93847ff509cf3 commit: 742379c0c4001fd2a6e02005c1ffa1ff611b28fa [4/7] drm/i915: Start chopping up the GPU error capture config: x86_64-randconfig-s1-20200111 (attached as .config) compiler: gcc-4.9

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Add additional pcode status values

== Series Details == Series: drm/i915/gen11: Add additional pcode status values URL : https://patchwork.freedesktop.org/series/71915/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16064 Summary ---

[Intel-gfx] [PATCH] drm/i915/gen11: Add additional pcode status values

I don't think we've ever hit these new error codes, but they're documented in the gen11 pcode document, so we might as well add them to the handler. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_sideband.c | 4 2 files changed, 6

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER

== Series Details == Series: drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER URL : https://patchwork.freedesktop.org/series/71912/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16063 Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp/tgl+: Update combo phy vswing tables

== Series Details == Series: drm/i915/dp/tgl+: Update combo phy vswing tables URL : https://patchwork.freedesktop.org/series/71909/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16062 Summary ---

Re: [Intel-gfx] [PATCH] drm/i915/dp/tgl+: Update combo phy vswing tables

On Fri, Jan 10, 2020 at 03:39:02PM -0800, José Roberto de Souza wrote: > TGL has now a table for RBR and HBR and another table for HBR2 over > combo phys. The HBR2 one has some small changes comparing to the ICL > one, so adding two new tables and adding a function to return TGL > combo phy

[Intel-gfx] [PATCH] drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER

Renaming to match the BSpec and struct name. BSpec: 20150 Cc: Jani Nikula Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_bios.c | 2 +- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for Add ops to intel_uc (rev4)

== Series Details == Series: Add ops to intel_uc (rev4) URL : https://patchwork.freedesktop.org/series/70716/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16061 Summary --- **SUCCESS** No

Re: [Intel-gfx] [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

On Fri, 10 Jan 2020 13:45:31 -0300 Arnaldo Carvalho de Melo wrote: > Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu: > > On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra > > wrote: > > > Again, this only allows attaching to previously created kprobes, it does > > > not

[Intel-gfx] [PATCH] drm/i915/dp/tgl+: Update combo phy vswing tables

TGL has now a table for RBR and HBR and another table for HBR2 over combo phys. The HBR2 one has some small changes comparing to the ICL one, so adding two new tables and adding a function to return TGL combo phy tables. v2: - reordered the tgl_combo_phy_ddi_translations_dp_hbr2 to reduce diff

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add ops to intel_uc (rev4)

== Series Details == Series: Add ops to intel_uc (rev4) URL : https://patchwork.freedesktop.org/series/70716/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2e1f188d8ce3 drm/i915/uc: Add ops to intel_uc -:147: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev4)

== Series Details == Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev4) URL : https://patchwork.freedesktop.org/series/71760/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16060 Summary

Re: [Intel-gfx] [PATCH 14/14] drm/i915/execlists: Offline error capture

. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-gt-Push-context-state-allocation-earlier/20200110-090110 base

[Intel-gfx] ✓ Fi.CI.BAT: success for Add ops to intel_uc (rev3)

== Series Details == Series: Add ops to intel_uc (rev3) URL : https://patchwork.freedesktop.org/series/70716/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16059 Summary --- **SUCCESS** No

[Intel-gfx] [CI v4 4/4] drm/i915/uc: Add sanitize to to intel_uc_ops

uC sanitization is only meaningful if we are running with uC present or enabled. Make this function part of the uc_ops. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10

[Intel-gfx] [CI v4 1/4] drm/i915/uc: Add ops to intel_uc

Instead of spreading multiple conditionals across the uC code to find out current mode of uC operation, start using predefined set of function pointers that reflect that mode. Begin with pair of init_hw/fini_hw functions that are responsible for uC hardware initialization and cleanup. v2: drop

[Intel-gfx] [CI v4 0/4] Add ops to intel_uc

Instead of spreading multiple conditionals across the uC code to find out current mode of uC operation, start using predefined set of function pointers that reflect that mode. v2: rebased, using macro to generate ops helpers v3: reuse __uc_check_hw to avoid redundant comment v4: forward declare

[Intel-gfx] [CI v4 3/4] drm/i915/uc: Add init/fini to to intel_uc_ops

uC preparation and cleanup steps are only meaningful if we are running with uC enabled. Make these functions part of the uc_ops. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Reviewed-by: Chris Wilson ---

[Intel-gfx] [CI v4 2/4] drm/i915/uc: Add init_fw/fini_fw to to intel_uc_ops

Firmware fetching and cleanup steps are only meaningful if we are running with uC enabled. Make these functions part of the uc_ops. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Reviewed-by: Chris Wilson ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add ops to intel_uc (rev3)

== Series Details == Series: Add ops to intel_uc (rev3) URL : https://patchwork.freedesktop.org/series/70716/ State : warning == Summary == $ dim checkpatch origin/drm-tip bb5e4aea2877 drm/i915/uc: Add ops to intel_uc -:142: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Make a copy of the ggtt view for slave plane

== Series Details == Series: series starting with [1/6] drm/i915: Make a copy of the ggtt view for slave plane URL : https://patchwork.freedesktop.org/series/71896/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16058

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev3)

== Series Details == Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev3) URL : https://patchwork.freedesktop.org/series/71760/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16045_full

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (rev3)

== Series Details == Series: drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (rev3) URL : https://patchwork.freedesktop.org/series/71581/ State : failure == Summary == Applying: drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3) Using index info

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Validation rotated vma bounds are within the object (rev2)

== Series Details == Series: drm/i915/gt: Validation rotated vma bounds are within the object (rev2) URL : https://patchwork.freedesktop.org/series/71827/ State : success == Summary == CI Bug Log - changes from CI_DRM_7720 -> Patchwork_16056

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Validation rotated vma bounds are within the object (rev2)

== Series Details == Series: drm/i915/gt: Validation rotated vma bounds are within the object (rev2) URL : https://patchwork.freedesktop.org/series/71827/ State : warning == Summary == $ dim checkpatch origin/drm-tip 933176d41e65 drm/i915/gt: Validate rotated vma bounds are within the object

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex

== Series Details == Series: drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex URL : https://patchwork.freedesktop.org/series/71889/ State : success == Summary == CI Bug Log - changes from CI_DRM_7720 -> Patchwork_16054 Summary

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: ggtt: include asm/smp.h

== Series Details == Series: i915: ggtt: include asm/smp.h URL : https://patchwork.freedesktop.org/series/71892/ State : failure == Summary == Applying: i915: ggtt: include asm/smp.h Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_ggtt.c Falling back to

Re: [Intel-gfx] [PATCH 4/6] drm/i915: s/intel_state/state/ in intel_{prepare, cleanup}_plane_fb()

Quoting Ville Syrjala (2020-01-10 18:32:26) > From: Ville Syrjälä > > Drop the redundant intel_ prefix from our atomic state variable. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_display.c | 22 ++-- > 1 file changed, 11 insertions(+), 11

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Stop looking at plane->state in intel_prepare_plane_fb()

Quoting Ville Syrjala (2020-01-10 18:32:25) > From: Ville Syrjälä > > Switch over to using explicit old/new planes states instead of > digging the old state out via plane->state. The main issue is that > plane->state will point to the uapi state which we generally don't > even want to look at. >

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/uc: Add sanitize to to intel_uc_ops

Quoting Michal Wajdeczko (2020-01-10 16:29:30) > uC sanitization is only meaningful if we are running with uC present > or enabled. Make this function part of the uc_ops. > > Signed-off-by: Michal Wajdeczko > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Daniele Ceraolo Spurio Series is

[Intel-gfx] [PATCH v3 1/4] drm/i915/uc: Add ops to intel_uc

Instead of spreading multiple conditionals across the uC code to find out current mode of uC operation, start using predefined set of function pointers that reflect that mode. Begin with pair of init_hw/fini_hw functions that are responsible for uC hardware initialization and cleanup. v2: drop

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/uc: Add ops to intel_uc

Quoting Michal Wajdeczko (2020-01-10 18:47:50) > On Fri, 10 Jan 2020 17:57:22 +0100, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2020-01-10 16:29:27) > >> Instead of spreading multiple conditionals across the uC code > >> to find out current mode of uC operation, start using

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Make a copy of the ggtt view for slave plane

Quoting Ville Syrjala (2020-01-10 18:32:23) > From: Ville Syrjälä > > intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever > it is present. We copy that from the master plane to the slave plane, > but we fail to copy the corresponding ggtt view. Thus when it comes time > to pin

Re: [Intel-gfx] [PATCH] drm/i915: add Wa_14010594013: icl,ehl

On Fri, Jan 10, 2020 at 02:33:04PM +0530, Anshuamn Gupta wrote: > On 2020-01-10 at 03:51:49 -0500, Matt Atwood wrote: > > The bspec tells us we need to set this bit to avoid potential underruns. > > > > Bspec: 33450 > > Bspec: 33451 > > Bspec: 33452 > It would be nice to add index 7386 which is

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/uc: Add ops to intel_uc

On Fri, 10 Jan 2020 17:57:22 +0100, Chris Wilson wrote: Quoting Michal Wajdeczko (2020-01-10 16:29:27) Instead of spreading multiple conditionals across the uC code to find out current mode of uC operation, start using predefined set of function pointers that reflect that mode. Begin with

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Balance prepare_fb/cleanup_fb

Quoting Ville Syrjala (2020-01-10 18:32:27) > From: Ville Syrjälä > > intel_prepare_plane_fb() bails early if there is no fb (or rather > no obj, which is the same thing). intel_cleanup_plane_fb() does not. > This means the steps performed by intel_cleanup_plane_fb() aren't > balanced with with

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix MST disable sequence

On Wed, 2020-01-08 at 18:20 +0200, Ville Syrjälä wrote: > On Wed, Jan 08, 2020 at 04:09:31PM +, Souza, Jose wrote: > > On Wed, 2020-01-08 at 16:45 +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > When moving the pipe disable & co. function calls from > > >

Re: [Intel-gfx] [PATCH] drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)

On Fri, Jan 10, 2020 at 10:11:23AM -0800, Vivek Kasireddy wrote: > Parsing the i2c element is mainly done to transfer the payload from the > MIPI sequence block to the relevant slave device. In some cases, the > commands that are part of the payload can be used to turn on the backlight. > > This

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Cleanup properly if the implicit fence setup fails

Quoting Ville Syrjala (2020-01-10 18:32:28) > From: Ville Syrjälä > > We've already pinned the vma and fence by the time we try to > deal with implicit fencing. Properly unpin the vma and fence > if the fence setup fails instead of just bailing straight out > from .prepare_fb(). As can be

[Intel-gfx] [PATCH 3/6] drm/i915: Stop looking at plane->state in intel_prepare_plane_fb()

From: Ville Syrjälä Switch over to using explicit old/new planes states instead of digging the old state out via plane->state. The main issue is that plane->state will point to the uapi state which we generally don't even want to look at. Also it sets a bad example as using plane->state during

[Intel-gfx] [PATCH 4/6] drm/i915: s/intel_state/state/ in intel_{prepare, cleanup}_plane_fb()

From: Ville Syrjälä Drop the redundant intel_ prefix from our atomic state variable. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 22 ++-- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git

[Intel-gfx] [PATCH 6/6] drm/i915: Cleanup properly if the implicit fence setup fails

From: Ville Syrjälä We've already pinned the vma and fence by the time we try to deal with implicit fencing. Properly unpin the vma and fence if the fence setup fails instead of just bailing straight out from .prepare_fb(). As can be expected drm_atomic_helper_prepare_planes() will not call

[Intel-gfx] [PATCH 5/6] drm/i915: Balance prepare_fb/cleanup_fb

From: Ville Syrjälä intel_prepare_plane_fb() bails early if there is no fb (or rather no obj, which is the same thing). intel_cleanup_plane_fb() does not. This means the steps performed by intel_cleanup_plane_fb() aren't balanced with with what was done intel_prepare_plane_fb() if there is no fb

[Intel-gfx] [PATCH 2/6] drm/i915: Clear old hw.fb & co. from slave plane's state

From: Ville Syrjälä Let's do the intel_plane_copy_uapi_to_hw_state() before we bail out due to both old and new uapi.crtc being NULL. This will drop the reference to the old hw.fb for planes that are transitioning from being a slave plane to simply being disabled. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 1/6] drm/i915: Make a copy of the ggtt view for slave plane

From: Ville Syrjälä intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever it is present. We copy that from the master plane to the slave plane, but we fail to copy the corresponding ggtt view. Thus when it comes time to pin the slave plane's fb we use some stale ggtt view left

[Intel-gfx] [PATCH] drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)

Parsing the i2c element is mainly done to transfer the payload from the MIPI sequence block to the relevant slave device. In some cases, the commands that are part of the payload can be used to turn on the backlight. This patch is actually a refactored version of this old patch:

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 09, 2020 at 04:26:19PM -0500, Harry Wentland wrote: > > > On 2020-01-09 4:04 p.m., Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher > > wrote: > > > > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner > >

Re: [Intel-gfx] [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu: > On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra > wrote: > > Again, this only allows attaching to previously created kprobes, it does > > not allow creating kprobes, right? > > That is; I don't think CAP_SYS_PERFMON should

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On 2020-01-09 4:04 p.m., Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher > wrote: > > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner > mailto:mario.kleiner...@gmail.com>> > wrote: > > > > On Thu, Jan 9, 2020 at 4:40 PM Alex

Re: [Intel-gfx] [PATCH 0/5] drm/i915: conversion to new drm logging macros.

On Fri, 10 Jan 2020, Jani Nikula wrote: On Tue, 07 Jan 2020, Wambui Karuga wrote: This series begins the conversion to using the new struct drm_device based logging macros in drm/i915. Wambui Karuga (5): drm/i915: convert to using the drm_dbg_kms() macro. drm/i915: use new struct

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: update HDCP CP property as per port authentication state

== Series Details == Series: drm/i915/hdcp: update HDCP CP property as per port authentication state URL : https://patchwork.freedesktop.org/series/71887/ State : success == Summary == CI Bug Log - changes from CI_DRM_7718 -> Patchwork_16053

Re: [Intel-gfx] [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

On 10.01.2020 17:02, Peter Zijlstra wrote: > On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote: >> On 08.01.2020 19:07, Peter Zijlstra wrote: >>> On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote: > diff --git a/kernel/events/core.c b/kernel/events/core.c

Re: [Intel-gfx] [PATCH] drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex

On Fri, 10 Jan 2020 at 14:44, Chris Wilson wrote: > > We need to hold the runtime-pm wakeref to update the global PTEs (as > they exist behind a PCI BAR). However, some systems invoke ACPI during > runtime resume and so require allocations, which is verboten inside the > vm->mutex. Ergo, we must

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/uc: Add ops to intel_uc

Quoting Michal Wajdeczko (2020-01-10 16:29:27) > Instead of spreading multiple conditionals across the uC code > to find out current mode of uC operation, start using predefined > set of function pointers that reflect that mode. > > Begin with pair of init_hw/fini_hw functions that are

[Intel-gfx] ✓ Fi.CI.BAT: success for Per client engine busyness (rev3)

== Series Details == Series: Per client engine busyness (rev3) URL : https://patchwork.freedesktop.org/series/70977/ State : success == Summary == CI Bug Log - changes from CI_DRM_7718 -> Patchwork_16052 Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

On 10.01.2020 17:02, Peter Zijlstra wrote: > On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote: >> On 08.01.2020 19:07, Peter Zijlstra wrote: >>> On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote: > diff --git a/kernel/events/core.c b/kernel/events/core.c

[Intel-gfx] [PATCH v2 0/4] Add ops to intel_uc

Instead of spreading multiple conditionals across the uC code to find out current mode of uC operation, start using predefined set of function pointers that reflect that mode. v2: rebased, using macro to generate ops helpers Michal Wajdeczko (4): drm/i915/uc: Add ops to intel_uc

[Intel-gfx] [PATCH v2 2/4] drm/i915/uc: Add init_fw/fini_fw to to intel_uc_ops

Firmware fetching and cleanup steps are only meaningful if we are running with uC enabled. Make these functions part of the uc_ops. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 12

[Intel-gfx] [PATCH v2 3/4] drm/i915/uc: Add init/fini to to intel_uc_ops

uC preparation and cleanup steps are only meaningful if we are running with uC enabled. Make these functions part of the uc_ops. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 12 +++-

[Intel-gfx] [PATCH v2 1/4] drm/i915/uc: Add ops to intel_uc

Instead of spreading multiple conditionals across the uC code to find out current mode of uC operation, start using predefined set of function pointers that reflect that mode. Begin with pair of init_hw/fini_hw functions that are responsible for uC hardware initialization and cleanup. v2: drop

[Intel-gfx] [PATCH v2 4/4] drm/i915/uc: Add sanitize to to intel_uc_ops

uC sanitization is only meaningful if we are running with uC present or enabled. Make this function part of the uc_ops. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 ++

Re: [Intel-gfx] [PATCH i-g-t] test/i915_pm_rc6_residency: Check we enter RC6 when mostly idle

Quoting Imre Deak (2020-01-10 16:16:27) > On Thu, Jan 09, 2020 at 10:23:00PM +, Chris Wilson wrote: > > Long ago, we would only approach runtime-suspend if the GPU had been > > idle (no userspace submissions) for a second or two. However, since > > disabling automatic HW RC6 such a relaxed

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per client engine busyness (rev3)

== Series Details == Series: Per client engine busyness (rev3) URL : https://patchwork.freedesktop.org/series/70977/ State : warning == Summary == $ dim checkpatch origin/drm-tip f2a2ab0fb90e drm/i915: Expose list of clients in sysfs -:61: WARNING:FILE_PATH_CHANGES: added, moved or deleted

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Start chopping up the GPU error capture

== Series Details == Series: series starting with [CI,1/4] drm/i915: Start chopping up the GPU error capture URL : https://patchwork.freedesktop.org/series/71885/ State : success == Summary == CI Bug Log - changes from CI_DRM_7718 -> Patchwork_16051

Re: [Intel-gfx] [PATCH i-g-t] test/i915_pm_rc6_residency: Check we enter RC6 when mostly idle

On Thu, Jan 09, 2020 at 10:23:00PM +, Chris Wilson wrote: > Long ago, we would only approach runtime-suspend if the GPU had been > idle (no userspace submissions) for a second or two. However, since > disabling automatic HW RC6 such a relaxed approach to runtime-suspend > caused us to never

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland wrote: > > > On 2020-01-09 4:04 p.m., Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher wrote: > >> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner >> wrote: >> > >> > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher >> wrote: >> >>

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Validate rotated vma bounds are within the object

Quoting Chris Wilson (2020-01-10 15:53:34) > Quite understandably, we bug out when asked to find a page that doesn't > belong to the object. However, we should report the error back to the > user long before we attempt the out-of-bound access! In this case, it is > insufficient validation on the

[Intel-gfx] [PATCH v2] drm/i915/gt: Validate rotated vma bounds are within the object

Quite understandably, we bug out when asked to find a page that doesn't belong to the object. However, we should report the error back to the user long before we attempt the out-of-bound access! In this case, it is insufficient validation on the rotated vma, with the simplest/cheapest point for us

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915: Start chopping up the GPU error capture

== Series Details == Series: series starting with [CI,1/4] drm/i915: Start chopping up the GPU error capture URL : https://patchwork.freedesktop.org/series/71885/ State : warning == Summary == $ dim checkpatch origin/drm-tip d117616075ef drm/i915: Start chopping up the GPU error capture

Re: [Intel-gfx] [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra wrote: > On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote: > > On 08.01.2020 19:07, Peter Zijlstra wrote: > > > On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote: > > > >> diff --git a/kernel/events/core.c

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Fri, Jan 10, 2020 at 2:32 PM Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 09:19:07PM +0100, Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä < > ville.syrj...@linux.intel.com> > > wrote: > > > > > On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote: > > > > On

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Do not use colon characters in PMU names (rev2)

== Series Details == Series: drm/i915/pmu: Do not use colon characters in PMU names (rev2) URL : https://patchwork.freedesktop.org/series/71878/ State : success == Summary == CI Bug Log - changes from CI_DRM_7718 -> Patchwork_16050 Summary

Re: [Intel-gfx] [PATCH 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()

On Fri, Jan 10, 2020 at 03:56:06PM +0200, Jani Nikula wrote: > On Fri, 10 Jan 2020, Thomas Zimmermann wrote: > > Hi > > > > Am 10.01.20 um 12:59 schrieb Jani Nikula: > >> On Fri, 10 Jan 2020, Thomas Zimmermann wrote: > >>> The callback struct drm_driver.get_scanout_position() is deprecated in >

Re: [Intel-gfx] [PATCH] i915: ggtt: include asm/smp.h

Quoting Arnd Bergmann (2020-01-10 15:17:54) > Splitting up the i915_gem_gtt caused a build failure in some configurations: > > drivers/gpu/drm/i915/gt/intel_ggtt.c: In function 'ggtt_restore_mappings': > drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of > function

[Intel-gfx] [PATCH] i915: ggtt: include asm/smp.h

Splitting up the i915_gem_gtt caused a build failure in some configurations: drivers/gpu/drm/i915/gt/intel_ggtt.c: In function 'ggtt_restore_mappings': drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of function 'wbinvd_on_all_cpus'; did you mean 'wrmsr_on_cpus'?

Re: [Intel-gfx] [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote: > On 08.01.2020 19:07, Peter Zijlstra wrote: > > On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote: > >> diff --git a/kernel/events/core.c b/kernel/events/core.c > >> index 059ee7116008..d9db414f2197 100644 > >> ---

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Skip trying to unbind in restore_ggtt_mappings

On Fri, 10 Jan 2020 at 11:04, Chris Wilson wrote: > > Currently we first to try to unbind the VMA (and lazily rebind on next > use) as an optimisation during restore_ggtt_mappings. Ideally, the only > objects in the GGTT upon resume are the pinned kernel objects which > can't be unbound and need

[Intel-gfx] [PATCH] drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex

We need to hold the runtime-pm wakeref to update the global PTEs (as they exist behind a PCI BAR). However, some systems invoke ACPI during runtime resume and so require allocations, which is verboten inside the vm->mutex. Ergo, we must not use intel_runtime_pm_get() inside the mutex, but lift the

Re: [Intel-gfx] [PATCH 03/14] drm/i915/gt: runtime-pm is no longer required for ce->ops->pin()

Chris Wilson writes: > Now that we have moved the runtime-pm management out of > intel_context_acctive_acquire, and that itself out of ce->ops->pin(), > no s/acctive/active > explicit runtime pm wakeref is required in intel_context_pin(). > > Signed-off-by: Chris Wilson Reviewed-by: Mika

Re: [Intel-gfx] [PATCH 0/5] drm/i915: conversion to new drm logging macros.

On Tue, 07 Jan 2020, Wambui Karuga wrote: > This series begins the conversion to using the new struct drm_device > based logging macros in drm/i915. > > Wambui Karuga (5): > drm/i915: convert to using the drm_dbg_kms() macro. > drm/i915: use new struct drm_device logging macros. > drm/i915:

Re: [Intel-gfx] [RFC 6/8] drm/i915: Expose per-engine client busyness

Quoting Tvrtko Ursulin (2020-01-10 14:09:09) > > On 10/01/2020 13:58, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2020-01-10 13:30:47) > >> +static ssize_t > >> +show_client_busy(struct device *kdev, struct device_attribute *attr, char > >> *buf) > >> +{ > >> + struct

Re: [Intel-gfx] [RFC 6/8] drm/i915: Expose per-engine client busyness

On 10/01/2020 13:58, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-01-10 13:30:47) +static ssize_t +show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf) +{ + struct i915_engine_busy_attribute *i915_attr = + container_of(attr,

Re: [Intel-gfx] [RFC 7/8] drm/i915: Track hw reported context runtime

Quoting Tvrtko Ursulin (2020-01-10 13:30:48) > From: Tvrtko Ursulin > > GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP > which will be useful for us in cases when we are not able to track context > busyness ourselves (like with GuC). Keep a copy of this in struct >

Re: [Intel-gfx] [RFC 6/8] drm/i915: Expose per-engine client busyness

Quoting Tvrtko Ursulin (2020-01-10 13:30:47) > +static ssize_t > +show_client_busy(struct device *kdev, struct device_attribute *attr, char > *buf) > +{ > + struct i915_engine_busy_attribute *i915_attr = > + container_of(attr, typeof(*i915_attr), attr); > + struct

[Intel-gfx] [PATCH v3] drm/i915/hdcp: update HDCP CP property as per port authentication state

When port is disabled due to modeset crtc disable sequence or DPMS off, it eventually disables the HDCP encryption keeping its content protection property to CP_ENABLED. Since content protection property left at CP_ENABLED by mistake, HDCP authentication is not attempted at next DDI enable

Re: [Intel-gfx] [PATCH 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()

On Fri, 10 Jan 2020, Thomas Zimmermann wrote: > Hi > > Am 10.01.20 um 12:59 schrieb Jani Nikula: >> On Fri, 10 Jan 2020, Thomas Zimmermann wrote: >>> The callback struct drm_driver.get_scanout_position() is deprecated in >>> favor of struct drm_crtc_helper_funcs.get_scanout_position(). >>> >>>

Re: [Intel-gfx] [RFC 3/8] drm/i915: Track per-context engine busyness

Quoting Tvrtko Ursulin (2020-01-10 13:30:44) > #endif /* __INTEL_CONTEXT_TYPES__ */ > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c > index 825c94e7ca0b..9a346c060469 100644 > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c > +++

Re: [Intel-gfx] [PATCH v4 2/7] drm: always determine branch device with drm_dp_is_branch()

On Thu, 29 Aug 2019, Oleg Vasilev wrote: > The helper should always be used. > > Reviewed-by: Emil Velikov > Signed-off-by: Oleg Vasilev > Cc: Ville Syrjälä > Cc: intel-gfx@lists.freedesktop.org Pushed patches 1-2 to drm-misc-next, thanks for the patches and review. BR, Jani. > --- >

Re: [Intel-gfx] [RFC 5/8] drm/i915: Contexts can use struct pid stored in the client

Quoting Tvrtko Ursulin (2020-01-10 13:30:46) > From: Tvrtko Ursulin > > Now that contexts keep their parent client reference counted, we can > remove separate struct pid reference owned by contexts in favour of the > one already held by the client. > > Signed-off-by: Tvrtko Ursulin > --- >

Re: [Intel-gfx] [RFC 2/8] drm/i915: Update client name on context create

Quoting Tvrtko Ursulin (2020-01-10 13:30:43) > From: Tvrtko Ursulin > > Some clients have the DRM fd passed to them over a socket by the X server. > > Grab the real client and pid when they create their first context and > update the exposed data for more useful enumeration. > > v2: > * Do

Re: [Intel-gfx] [PATCH 18/23] drm/sti: Convert to CRTC VBLANK callbacks

Le ven. 10 janv. 2020 à 10:21, Thomas Zimmermann a écrit : > > VBLANK callbacks in struct drm_driver are deprecated in favor of > their equivalents in struct drm_crtc_funcs. Convert sti over. > Hi Thomas, Since you remove the last calls to sti_crtc functions from sti_drv.c I think that the

Re: [Intel-gfx] [RFC 1/8] drm/i915: Expose list of clients in sysfs

Quoting Tvrtko Ursulin (2020-01-10 13:30:42) > +static ssize_t > +show_client_name(struct device *kdev, struct device_attribute *attr, char > *buf) > +{ > + struct i915_drm_client *client = > + container_of(attr, typeof(*client), attr.name); > + > + return snprintf(buf,

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On Thu, Jan 09, 2020 at 09:19:07PM +0100, Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä > wrote: > > > On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote: > > > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä < > > ville.syrj...@linux.intel.com> > > > wrote: > > > >

[Intel-gfx] [RFC 7/8] drm/i915: Track hw reported context runtime

From: Tvrtko Ursulin GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP which will be useful for us in cases when we are not able to track context busyness ourselves (like with GuC). Keep a copy of this in struct intel_context from where it can be easily read even if the

[Intel-gfx] [RFC 2/8] drm/i915: Update client name on context create

From: Tvrtko Ursulin Some clients have the DRM fd passed to them over a socket by the X server. Grab the real client and pid when they create their first context and update the exposed data for more useful enumeration. v2: * Do not leak the pid reference and borrow context idr_lock. (Chris)

[Intel-gfx] [RFC 6/8] drm/i915: Expose per-engine client busyness

From: Tvrtko Ursulin Expose per-client and per-engine busyness under the previously added sysfs client root. The new files are one per-engine instance and located under the 'busy' directory. Each contains a monotonically increasing nano-second resolution times each client's jobs were executing

[Intel-gfx] [RFC 5/8] drm/i915: Contexts can use struct pid stored in the client

From: Tvrtko Ursulin Now that contexts keep their parent client reference counted, we can remove separate struct pid reference owned by contexts in favour of the one already held by the client. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 13

[Intel-gfx] [RFC 8/8] drm/i915: Fallback to hw context runtime when sw tracking is not available

From: Tvrtko Ursulin In GuC mode we are not receiving the context switch interrupts to be able to accurately track context runtimes. We can fallback to using PPHWSP counter updated by the GPU on context save. QQQ Downsides are: 1) we do not see currently executing batch and 2) with a 12MHz

[Intel-gfx] [RFC 3/8] drm/i915: Track per-context engine busyness

From: Tvrtko Ursulin Some customers want to know how much of the GPU time are their clients using in order to make dynamic load balancing decisions. With the hooks already in place which track the overall engine busyness, we can extend that slightly to split that time between contexts. v2: Fix

[Intel-gfx] [RFC 1/8] drm/i915: Expose list of clients in sysfs

From: Tvrtko Ursulin Expose a list of clients with open file handles in sysfs. This will be a basis for a top-like utility showing per-client and per- engine GPU load. Currently we only expose each client's pid and name under opaque numbered directories in /sys/class/drm/card0/clients/. For

  1   2   >