[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per context dynamic (sub)slice power-gating (rev14)

== Series Details == Series: Per context dynamic (sub)slice power-gating (rev14) URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Move RPCS setup to context pin Okay! Commit:

[Intel-gfx] [CI 15/21] drm/i915: Syntatic sugar for using intel_runtime_pm

Frequently, we use intel_runtime_pm_get/_put around a small block. Formalise that usage by providing a macro to define such a block with an automatic closure to scope the intel_runtime_pm wakeref to that block, i.e. macro abuse smelling of python. Signed-off-by: Chris Wilson Cc: Jani Nikula

[Intel-gfx] [CI 03/21] drm/i915: Track GT wakeref

Record the wakeref used for keeping the device awake as the GPU is executing requests and be sure to cancel the tracking upon parking. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem.c | 11

[Intel-gfx] [CI 08/21] drm/i915/pmu: Track rpm wakeref

Track the wakeref used for temporary access to the device, and discard it upon release so that leaks can be identified. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_pmu.c | 26 +- 1 file changed, 17 insertions(+),

Re: [Intel-gfx] [PATCH 18/21] drm/i915: Combined gt.awake/gt.power wakerefs

Chris Wilson writes: > As the GT_IRQ power domain implies a wakeref, we can use it inplace of > our existing redundant rpm grab. > > Signed-off-by: Chris Wilson > Cc: Jani Nikula > --- > drivers/gpu/drm/i915/i915_drv.h | 1 - > drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [CI 04/21] drm/i915: Track the rpm wakerefs for error handling

Keep hold of the local wakeref used in error handling, to cancel the tracking upon release so that leaks can be identified. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_irq.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

[Intel-gfx] [CI 09/21] drm/i915/guc: Track the rpm wakeref

Keep track of our acquired wakeref for interacting with the guc, so that we can cancel it upon release and so clearly identify leaks. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_guc_log.c | 15 +--

[Intel-gfx] [CI 21/21] drm/i915: Mark up Ironlake ips with rpm wakerefs

Currently Ironlake operates under the assumption that rpm awake (and its error checking is disabled). As such, we have missed a few places where we access registers without taking the rpm wakeref and thus trigger warnings. intel_ips being one culprit. As this involved adding a potentially

[Intel-gfx] [CI 06/21] drm/i915: Mark up debugfs with rpm wakeref tracking

As debugfs has a simple pattern of taking a rpm wakeref around the user access, we can track the local reference and drop it as soon as possible. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debugfs.c | 135 +---

[Intel-gfx] [CI 02/21] drm/i915: Markup paired operations on wakerefs

The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various

[Intel-gfx] [CI 10/21] drm/i915/gem: Track the rpm wakerefs

Keep track of the temporary rpm wakerefs used for user access to the device, so that we can cancel them upon release and clearly identify any leaks. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem.c| 47

[Intel-gfx] [CI 11/21] drm/i915/fb: Track rpm wakerefs

Keep track of the rpm wakeref used for framebuffer access so that we can cancel upon release and so more clearly identify leaks. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_display.c | 5 +++-- drivers/gpu/drm/i915/intel_fbdev.c | 9

[Intel-gfx] [CI 14/21] drm/i915/selftests: Mark up rpm wakerefs

Track the temporary wakerefs used within the selftests so that leaks are clear. v2: Add a couple of coarse annotations for mock selftests as we now loudly warn about the errors. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala ---

Re: [Intel-gfx] [PATCH 21/21] drm/i915: Mark up Ironlake ips with rpm wakerefs

Chris Wilson writes: > Currently Ironlake operates under the assumption that rpm awake (and its > error checking is disabled). As such, we have missed a few places where we > access registers without taking the rpm wakeref and thus trigger > warnings. intel_ips being one culprit. > > As this

Re: [Intel-gfx] [PATCH 21/21] drm/i915: Mark up Ironlake ips with rpm wakerefs

Quoting Mika Kuoppala (2019-01-14 15:01:59) > Chris Wilson writes: > > unsigned long i915_chipset_val(struct drm_i915_private *dev_priv) > > { > > - unsigned long val; > > + intel_wakeref_t wakeref; > > + unsigned long val = 0; > > > > if (!IS_GEN(dev_priv, 5)) > >

[Intel-gfx] ✓ Fi.CI.BAT: success for Per context dynamic (sub)slice power-gating (rev14)

== Series Details == Series: Per context dynamic (sub)slice power-gating (rev14) URL : https://patchwork.freedesktop.org/series/48194/ State : success == Summary == CI Bug Log - changes from CI_DRM_5415 -> Patchwork_11289 Summary ---

Re: [Intel-gfx] [CI 20/21] drm/i915: Combined gt.awake/gt.power wakerefs

Chris Wilson writes: > As the GT_IRQ power domain implies a wakeref, we can use it inplace of > our existing redundant rpm grab. > > v2: Drop papering over forgetting to take the runtime wakeref in > selftests > > Signed-off-by: Chris Wilson > Cc: Jani Nikula Reviewed-by: Mika Kuoppala >

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Split the gamma/csc enable bits from the plane_ctl() function

On Fri, Jan 11, 2019 at 04:41:37PM -0800, Matt Roper wrote: > On Fri, Jan 11, 2019 at 07:08:12PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > On g4x+ the pipe gamma enable bit for the primary plane affects > > the pipe bottom color as well. The same for the pipe csc enable > > bit

[Intel-gfx] [CI 01/21] drm/i915: Track all held rpm wakerefs

Everytime we take a wakeref, record the stack trace of where it was taken; clearing the set if we ever drop back to no owners. For debugging a rpm leak, we can look at all the current wakerefs and check if they have a matching rpm_put. v2: Use skip=0 for unwinding the stack as it appears our

[Intel-gfx] [CI 07/21] drm/i915/perf: Track the rpm wakeref

Keep track of our wakeref used to keep the device awake so we can catch any leak. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_perf.c | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-)

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,01/21] drm/i915: Track all held rpm wakerefs

== Series Details == Series: series starting with [CI,01/21] drm/i915: Track all held rpm wakerefs URL : https://patchwork.freedesktop.org/series/55181/ State : failure == Summary == Applying: drm/i915: Markup paired operations on wakerefs Using index info to reconstruct a base tree... M

[Intel-gfx] [PATCH i-g-t] i915/gem_cpu_reloc: Use a self-modifying chained batch

Use another sensitive CPU reloc to emit a chained batch from inside the updated buffer to reduce the workload on slow machines to fit within the CI timeout. References: https://bugs.freedesktop.org/show_bug.cgi?id=108248 Signed-off-by: Chris Wilson --- tests/i915/gem_cpu_reloc.c | 347

[Intel-gfx] [CI 20/21] drm/i915: Combined gt.awake/gt.power wakerefs

As the GT_IRQ power domain implies a wakeref, we can use it inplace of our existing redundant rpm grab. v2: Drop papering over forgetting to take the runtime wakeref in selftests Signed-off-by: Chris Wilson Cc: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 1 -

[Intel-gfx] [CI 13/21] drm/i915/panel: Track temporary rpm wakeref

Keep track of the temporary rpm wakeref used for panel backlight access, so that we can cancel it immediately upon release and so more clearly identify leaks. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_panel.c | 5 +++-- 1 file

[Intel-gfx] [CI 12/21] drm/i915/hotplug: Track temporary rpm wakeref

Keep track of the temporary rpm wakeref inside hotplug detection, so that we can cancel it immediately upon release and so clearly identify leaks. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_hotplug.c | 5 +++-- 1 file changed, 3

[Intel-gfx] [CI 17/21] drm/i915: Track the wakeref used to initialise display power domains

On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and transfer them to the runtime-pm code. We can use our wakeref tracking to verify that the wakeref is indeed passed from init to enable, and disable to fini; and across suspend. Signed-off-by: Chris Wilson Cc: Jani Nikula

[Intel-gfx] [CI 18/21] drm/i915/dp: Markup pps lock power well

Track where and when we acquire and release the power well for pps access along the dp aux link, with a view to detecting if we leak any wakerefs. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: John Harrison --- drivers/gpu/drm/i915/intel_dp.c | 231 +---

[Intel-gfx] [CI 19/21] drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice

As we only release each power well once, we assume that each transcoder maps to a different domain. Complain if this is not so. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_display.c | 6 ++ 1 file changed, 6 insertions(+) diff

[Intel-gfx] [CI 05/21] drm/i915: Mark up sysfs with rpm wakeref tracking

As sysfs has a simple pattern of taking a rpm wakeref around the user access, we can track the local reference and drop it as soon as possible. Signed-off-by: Chris Wilson Cc: Jani Nikula Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_sysfs.c | 24 ++-- 1 file

[Intel-gfx] [CI 16/21] drm/i915: Markup paired operations on display power domains

The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,01/21] drm/i915: Track all held rpm wakerefs

Quoting Patchwork (2019-01-14 14:29:32) > == Series Details == > > Series: series starting with [CI,01/21] drm/i915: Track all held rpm wakerefs > URL : https://patchwork.freedesktop.org/series/55181/ > State : failure > > == Summary == > > Applying: drm/i915: Markup paired operations on

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_whipser: Pass early exit onto check_bo

If we break out of the test loop early, we may not have filled all dwords, so be careful to only check as far as we completed. Fixes: d9cd03c887a5 ("i915/gem_exec_whisper: Limit to a maximum of 150s") Signed-off-by: Chris Wilson --- tests/i915/gem_exec_whisper.c | 12 ++-- 1 file

[Intel-gfx] [PATCH 2/3] snd/hda: Track the display_power_status using a cookie

drm/i915 is tracking all wakeref owners with a cookie in order to identify leaks. To that end, each rpm acquisition ops->get_power is assigned a cookie which should be passed to ops->put_power to signify its release (and removal from the list of wakeref owners). As snd/hda is already using a bool

[Intel-gfx] [PATCH 1/3] drm/i915/audio: Track temporary rpm wakerefs

Track the temporary rpm wakerefs used within audio so that they may be marked as complete and the tracking cancelled upon release. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_audio.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 3/3] snd/hda: Protect concurrent display_power_status with a mutex

On Mon, 14 Jan 2019 18:37:53 +0100, Chris Wilson wrote: > > Just in case the audio linkage is swapped between components during the > runtime pm sequence, we need to protect the rpm tracking with a mutex. It's not clear to me how does this happens. Could you elaborate a bit more the scenario?

Re: [Intel-gfx] [PATCH 3/3] snd/hda: Protect concurrent display_power_status with a mutex

On Mon, 14 Jan 2019 18:51:31 +0100, Chris Wilson wrote: > > Quoting Takashi Iwai (2019-01-14 17:46:57) > > On Mon, 14 Jan 2019 18:37:53 +0100, > > Chris Wilson wrote: > > > > > > Just in case the audio linkage is swapped between components during the > > > runtime pm sequence, we need to protect

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/audio: Track temporary rpm wakerefs

== Series Details == Series: series starting with [1/3] drm/i915/audio: Track temporary rpm wakerefs URL : https://patchwork.freedesktop.org/series/55194/ State : warning == Summary == $ dim checkpatch origin/drm-tip b531f8b4dca8 drm/i915/audio: Track temporary rpm wakerefs c78a3bd63af7

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_whipser: Pass early exit onto check_bo

On 14/01/2019 16:34, Chris Wilson wrote: If we break out of the test loop early, we may not have filled all dwords, so be careful to only check as far as we completed. Fixes: d9cd03c887a5 ("i915/gem_exec_whisper: Limit to a maximum of 150s") Signed-off-by: Chris Wilson ---

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm: annotate drm_core_check_feature() dev arg. as const

== Series Details == Series: series starting with [v2,1/2] drm: annotate drm_core_check_feature() dev arg. as const URL : https://patchwork.freedesktop.org/series/55154/ State : success == Summary == CI Bug Log - changes from CI_DRM_5414_full -> Patchwork_11287_full

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/audio: Track temporary rpm wakerefs

== Series Details == Series: series starting with [1/3] drm/i915/audio: Track temporary rpm wakerefs URL : https://patchwork.freedesktop.org/series/55194/ State : success == Summary == CI Bug Log - changes from CI_DRM_5417 -> Patchwork_11291

Re: [Intel-gfx] drm/i915: Fix the static code analysis warning in debugfs

On Wed, Jan 09, 2019 at 01:14:14PM -0800, Radhakrishna Sripada wrote: > intel_dp->dsc_dpcd is defined as an array making the if check redundant. > > Cc: Rodrigo Vivi > Signed-off-by: Radhakrishna Sripada This fixes a Clang warning I saw after the patch that added this hit linux-next.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,01/21] drm/i915: Track all held rpm wakerefs

Quoting Chris Wilson (2019-01-14 14:32:35) > Quoting Patchwork (2019-01-14 14:29:32) > > == Series Details == > > > > Series: series starting with [CI,01/21] drm/i915: Track all held rpm > > wakerefs > > URL : https://patchwork.freedesktop.org/series/55181/ > > State : failure > > > > ==

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_whipser: Pass early exit onto check_bo

Quoting Tvrtko Ursulin (2019-01-14 17:43:17) > > On 14/01/2019 16:34, Chris Wilson wrote: > > If we break out of the test loop early, we may not have filled all > > dwords, so be careful to only check as far as we completed. > > > > Fixes: d9cd03c887a5 ("i915/gem_exec_whisper: Limit to a maximum

Re: [Intel-gfx] [PATCH 2/3] snd/hda: Track the display_power_status using a cookie

On Mon, 14 Jan 2019 18:37:52 +0100, Chris Wilson wrote: > > drm/i915 is tracking all wakeref owners with a cookie in order to > identify leaks. To that end, each rpm acquisition ops->get_power is > assigned a cookie which should be passed to ops->put_power to signify > its release (and removal

Re: [Intel-gfx] [PATCH 1/3] drm/i915/audio: Track temporary rpm wakerefs

On 1/14/2019 09:37, Chris Wilson wrote: Track the temporary rpm wakerefs used within audio so that they may be marked as complete and the tracking cancelled upon release. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_audio.c | 10 ++ 1 file changed, 6 insertions(+), 4

[Intel-gfx] [PULL] drm-intel-next

Hi Dave and Daniel, Here goes first pull request targeting 5.1 made out of 2 tags: drm-intel-next-2019-01-10: - Unwind failure on pinning the gen7 PPGTT (Chris) - Fastset updates to make sure DRRS and PSR are properly enabled (Hans) - Header include clean-up (Brajeswar, Jani) - Improvements and

[Intel-gfx] [PATCH 3/3] snd/hda: Protect concurrent display_power_status with a mutex

Just in case the audio linkage is swapped between components during the runtime pm sequence, we need to protect the rpm tracking with a mutex. Signed-off-by: Chris Wilson Cc: Takashi Iwai Cc: Jani Nikula --- include/sound/hdaudio.h| 1 + sound/hda/hdac_component.c | 7 +++ 2 files

Re: [Intel-gfx] [PATCH 3/3] snd/hda: Protect concurrent display_power_status with a mutex

Quoting Takashi Iwai (2019-01-14 17:46:57) > On Mon, 14 Jan 2019 18:37:53 +0100, > Chris Wilson wrote: > > > > Just in case the audio linkage is swapped between components during the > > runtime pm sequence, we need to protect the rpm tracking with a mutex. > > It's not clear to me how does this

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Split the gamma/csc enable bits from the plane_ctl() function

On Mon, Jan 14, 2019 at 07:11:10PM +0200, Ville Syrjälä wrote: > On Fri, Jan 11, 2019 at 04:41:37PM -0800, Matt Roper wrote: > > On Fri, Jan 11, 2019 at 07:08:12PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > On g4x+ the pipe gamma enable bit for the primary plane affects >

Re: [Intel-gfx] [PATCH] drm/i915: Fix ILK-IVB primary plane enable delays

On Thu, Dec 20, 2018 at 01:26:08PM +0200, Juha-Pekka Heikkila wrote: > Primary and sprite plane enable on ILK-IVB may take two frames to complete > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103925 > Signed-off-by: Juha-Pekka Heikkila > --- > drivers/gpu/drm/i915/intel_display.c |

[Intel-gfx] ✗ Fi.CI.IGT: failure for Per context dynamic (sub)slice power-gating (rev14)

== Series Details == Series: Per context dynamic (sub)slice power-gating (rev14) URL : https://patchwork.freedesktop.org/series/48194/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5415_full -> Patchwork_11289_full Summary

Re: [Intel-gfx] [PATCH 2/3] snd/hda: Track the display_power_status using a cookie

Quoting Takashi Iwai (2019-01-14 17:54:08) > On Mon, 14 Jan 2019 18:37:52 +0100, > Chris Wilson wrote: > > diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h > > index b4fa1c775251..39761120ee76 100644 > > --- a/include/sound/hdaudio.h > > +++ b/include/sound/hdaudio.h > > @@ -366,8

[Intel-gfx] [CI] drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex

We have two classes of VM, global GTT and per-process GTT. In order to allow ourselves the freedom to mix both along call chains, distinguish the two classes with regards to their mutex and lockdep maps. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex (rev3)

== Series Details == Series: drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex (rev3) URL : https://patchwork.freedesktop.org/series/46547/ State : success == Summary == CI Bug Log - changes from CI_DRM_5418 -> Patchwork_11294

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Pass down rc in intel_encoder->compute_config()

== Series Details == Series: drm/i915: Pass down rc in intel_encoder->compute_config() URL : https://patchwork.freedesktop.org/series/55203/ State : warning == Summary == $ dim checkpatch origin/drm-tip ee32ce9c3146 drm/i915: Pass down rc in intel_encoder->compute_config() -:353:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Pass down rc in intel_encoder->compute_config()

== Series Details == Series: drm/i915: Pass down rc in intel_encoder->compute_config() URL : https://patchwork.freedesktop.org/series/55203/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Pass down rc in intel_encoder->compute_config()

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/audio: Track temporary rpm wakerefs

== Series Details == Series: series starting with [1/3] drm/i915/audio: Track temporary rpm wakerefs URL : https://patchwork.freedesktop.org/series/55194/ State : success == Summary == CI Bug Log - changes from CI_DRM_5417_full -> Patchwork_11291_full

[Intel-gfx] [PATCH 8/8] drm/i915: Issue engine resets onto idle engines

Always perform the requested reset, even if we believe the engine is idle. Presumably there was a reason the caller wanted the reset, and in the near future we lose the easy tracking for whether the engine is idle. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_reset.c |

[Intel-gfx] [PATCH 1/8] drm/i915: Serialise concurrent calls to i915_gem_set_wedged()

Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more consistently if called concurrently. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem.c | 32 ++- drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-

[Intel-gfx] [PATCH 3/8] drm/i915: Pull all the reset functionality together into i915_reset.c

Currently the code to reset the GPU and our state is spread widely across a few files. Pull the logic together into a common file. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Makefile |3 +- drivers/gpu/drm/i915/i915_debugfs.c |2 +

[Intel-gfx] [PATCH 7/8] drm/i915/selftests: Trim struct_mutex duration for set-wedged selftest

Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged() as a reminder that it must be callable without struct_mutex held. Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Mika Kuoppala --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++--- 1 file changed, 3

[Intel-gfx] Mika's reward

In preparation for relaxing the conditions under which we wait to allow waiting on the GPU from any context (e.g. holding nearly any other mutex) is to remove taking struct_mutex from inside GPU reset. The issue being that any mutex required for GPU reset is required to avoid indefinite waits

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Prevent concurrent GGTT update and use on Braswell (again)

== Series Details == Series: series starting with [1/3] drm/i915: Prevent concurrent GGTT update and use on Braswell (again) URL : https://patchwork.freedesktop.org/series/55201/ State : success == Summary == CI Bug Log - changes from CI_DRM_5418 -> Patchwork_11293

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/8] drm/i915: Serialise concurrent calls to i915_gem_set_wedged()

Quoting Patchwork (2019-01-14 21:26:32) > == Series Details == > > Series: series starting with [1/8] drm/i915: Serialise concurrent calls to > i915_gem_set_wedged() > URL : https://patchwork.freedesktop.org/series/55200/ > State : failure > > == Summary == > > Applying: drm/i915: Serialise

[Intel-gfx] [PATCH i-g-t] intel-ci: Drop gem_ctx_switch/heavy

Th heavy variant of gem_ctx_switch does little more than provide an alternate timing for the basic gem_ctx_switch; the timing only effects the HW and does not stress the driver any differently. As such, including gem_ctx_switch/heavy provides no more basic coverage for BAT over and above the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Pass down rc in intel_encoder->compute_config()

== Series Details == Series: drm/i915: Pass down rc in intel_encoder->compute_config() URL : https://patchwork.freedesktop.org/series/55203/ State : success == Summary == CI Bug Log - changes from CI_DRM_5418 -> Patchwork_11295 Summary

Re: [Intel-gfx] [PATCH 3/3] snd/hda: Protect concurrent display_power_status with a mutex

Quoting Takashi Iwai (2019-01-14 18:00:02) > On Mon, 14 Jan 2019 18:51:31 +0100, > Chris Wilson wrote: > > > > Quoting Takashi Iwai (2019-01-14 17:46:57) > > > On Mon, 14 Jan 2019 18:37:53 +0100, > > > Chris Wilson wrote: > > > > > > > > Just in case the audio linkage is swapped between

[Intel-gfx] [PATCH 4/8] drm/i915: Make all GPU resets atomic

In preparation for the next few commits, make resetting the GPU atomic. Currently, we have prepared gen6+ for atomic resetting of individual engines, but now there is a requirement to perform the whole device level reset (just the register poking) from inside an atomic context. Signed-off-by:

[Intel-gfx] [PATCH 6/8] drm/i915: Remove GPU reset dependence on struct_mutex

Now that the submission backends are controlled via their own spinlocks, with a wave of a magic wand we can lift the struct_mutex requirement around GPU reset. That is we allow the submission frontend (userspace) to keep on submitting while we process the GPU reset as we can suspend the backend

[Intel-gfx] [PATCH 5/8] drm/i915/guc: Disable global reset

The guc (and huc) currently inexcruitably depend on struct_mutex for device reinitialisation from inside the reset, and indeed taking any mutex here is verboten (as we must be able to reset from underneath any of our mutexes). That makes recovering the guc unviable without, for example, reserving

[Intel-gfx] [PATCH 2/8] drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex

We have two classes of VM, global GTT and per-process GTT. In order to allow ourselves the freedom to mix both along call chains, distinguish the two classes with regards to their mutex and lockdep maps. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH 2/3] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start

Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers") we have been able to report failure from mmu_invalidate_range_start which allows us to use a trylock on the struct_mutex to avoid potential recursion and report -EBUSY instead. Furthermore, this allows us to pull

[Intel-gfx] [PATCH 1/3] drm/i915: Prevent concurrent GGTT update and use on Braswell (again)

On Braswell, under heavy stress, if we update the GGTT while simultaneously accessing another region inside the GTT, we are returned the wrong values. To prevent this we stop the machine to update the GGTT entries so that no memory traffic can occur at the same time. This was first spotted in

Re: [Intel-gfx] [PATCH 3/3] snd/hda: Protect concurrent display_power_status with a mutex

On Mon, 14 Jan 2019 21:57:15 +0100, Chris Wilson wrote: > > Quoting Takashi Iwai (2019-01-14 18:00:02) > > On Mon, 14 Jan 2019 18:51:31 +0100, > > Chris Wilson wrote: > > > > > > Quoting Takashi Iwai (2019-01-14 17:46:57) > > > > On Mon, 14 Jan 2019 18:37:53 +0100, > > > > Chris Wilson wrote: >

[Intel-gfx] [PATCH 3/3] drm/i915/userptr: Probe vma range before gup

We want to exclude any GGTT objects from being present on our internal lists to avoid the deadlock we may run into with our requirement for struct_mutex during invalidate. However, if the gup_fast fails, we put the userptr onto the workqueue and mark it as active, so that we remember to serialise

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/8] drm/i915: Serialise concurrent calls to i915_gem_set_wedged()

== Series Details == Series: series starting with [1/8] drm/i915: Serialise concurrent calls to i915_gem_set_wedged() URL : https://patchwork.freedesktop.org/series/55200/ State : failure == Summary == Applying: drm/i915: Serialise concurrent calls to i915_gem_set_wedged() Applying:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Prevent concurrent GGTT update and use on Braswell (again)

== Series Details == Series: series starting with [1/3] drm/i915: Prevent concurrent GGTT update and use on Braswell (again) URL : https://patchwork.freedesktop.org/series/55201/ State : warning == Summary == $ dim checkpatch origin/drm-tip 071bbd0707df drm/i915: Prevent concurrent GGTT

[Intel-gfx] [PATCH] drm/i915: Pass down rc in intel_encoder->compute_config()

Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock.

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Prevent concurrent GGTT update and use on Braswell (again)

== Series Details == Series: series starting with [1/3] drm/i915: Prevent concurrent GGTT update and use on Braswell (again) URL : https://patchwork.freedesktop.org/series/55201/ State : success == Summary == CI Bug Log - changes from CI_DRM_5418_full -> Patchwork_11293_full

Re: [Intel-gfx] [PATCH 43/46] drm/i915: Allocate a status page for each timeline

On 1/7/2019 03:55, Chris Wilson wrote: Allocate a page for use as a status page by a group of timelines, as we only need a dword of storage for each (rounded up to the cacheline for safety) we can pack multiple timelines into the same page. Each timeline will then be able to track its own HW

Re: [Intel-gfx] [PATCH 41/46] drm/i915: Introduce concept of per-timeline (context) HWSP

On 1/7/2019 03:55, Chris Wilson wrote: Supplement the per-engine HWSP with a per-timeline HWSP. That is a per-request pointer through which we can check a local seqno, abstracting away the presumption of a global seqno. In this first step, we point each request back into the engine's HWSP so

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex (rev3)

== Series Details == Series: drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex (rev3) URL : https://patchwork.freedesktop.org/series/46547/ State : success == Summary == CI Bug Log - changes from CI_DRM_5418_full -> Patchwork_11294_full

Re: [Intel-gfx] [PATCH 06/13] drm/i915: Split color mgmt based on single vs. double buffered registers

On Fri, Jan 11, 2019 at 07:08:16PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Split the color managemnt hooks along the single vs. double > buffered registers line. Of the currently progammed registers > GAMMA_MODE and the ilk+ pipe CSC are double buffered, the > LUTS and CHV CGM

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Pass down rc in intel_encoder->compute_config()

== Series Details == Series: drm/i915: Pass down rc in intel_encoder->compute_config() URL : https://patchwork.freedesktop.org/series/55203/ State : success == Summary == CI Bug Log - changes from CI_DRM_5418_full -> Patchwork_11295_full

Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

Quoting Sripada, Radhakrishna (2019-01-09 22:38:36) > Looks good to me. There is already conclusion in the other thread that this should NOT be merged. Regards, Joonas > > > -Original Message- > > From: Souza, Jose > > Sent: Friday, January 4, 2019 9:37 AM > > To:

[Intel-gfx] [PATCH v2 1/2] drm: annotate drm_core_check_feature() dev arg. as const

From: Emil Velikov This static inline function doesn't modify any state. Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter --- include/drm/drm_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_drv.h

[Intel-gfx] [PATCH v2 2/2] drm: allow render capable master with DRM_AUTH ioctls

From: Emil Velikov There are cases (in mesa and applications) where one would open the primary node without properly authenticating the client. Sometimes we don't check if the authentication succeeds, but there's also cases we simply forget to do it. The former was a case for Mesa where it did

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_limit: Limit to a maximum of 120s

Each individual pass is as effective at spotting an error using the Chinese whisper as any other, so the effectiveness of adding more passes rapidly diminishes. To keep the tests bounded within time, limit a subtest to a mere 150s! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108592

[Intel-gfx] [PATCH v25 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)

From: Tvrtko Ursulin We want to allow userspace to reconfigure the subslice configuration on a per context basis. This is required for the functional requirement of shutting down non-VME enabled sub-slices on Gen11 parts. To do so, we expose a context parameter to allow adjustment of the RPCS

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_limit: Limit to a maximum of 120s

On 14/01/2019 09:16, Chris Wilson wrote: Each individual pass is as effective at spotting an error using the Chinese whisper as any other, so the effectiveness of adding more passes rapidly diminishes. To keep the tests bounded within time, limit a subtest to a mere 150s! Bugzilla:

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_limit: Limit to a maximum of 120s

Quoting Tvrtko Ursulin (2019-01-14 09:42:55) > > On 14/01/2019 09:16, Chris Wilson wrote: > > + > > + if (++pass == 1024) > > + break; > > } > > } > > igt_info("Number of migrations

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add a new "remapped" gtt_view

On 11/01/2019 19:46, Ville Syrjala wrote: From: Ville Syrjälä To overcome display engine stride limits we'll want to remap the pages in the GTT. To that end we need a new gtt_view type which is just like the "rotated" type except not rotated. I think I asked this before, so sorry if you

Re: [Intel-gfx] [PATCH i-g-t] Make force work with multiple drivers available

On 01/14, Petri Latvala wrote: > On Fri, Jan 11, 2019 at 11:13:37AM -0200, Rodrigo Siqueira wrote: > > The force option allows users to specify which driver they want that IGT > > uses. Nonetheless, if the user has two or more loaded drivers in his > > system, the force option will not work as

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm: annotate drm_core_check_feature() dev arg. as const

== Series Details == Series: series starting with [v2,1/2] drm: annotate drm_core_check_feature() dev arg. as const URL : https://patchwork.freedesktop.org/series/55154/ State : success == Summary == CI Bug Log - changes from CI_DRM_5414 -> Patchwork_11287

[Intel-gfx] [PATCH i-g-t 1/4] headers: bump

From: Tvrtko Ursulin Sync with latest drm headers from drm-tip. Acked-by: Chris Wilson --- include/drm-uapi/drm_fourcc.h | 2 +- include/drm-uapi/drm_mode.h | 19 +++ include/drm-uapi/i915_drm.h | 64 +++ include/drm-uapi/msm_drm.h| 25

[Intel-gfx] [PATCH i-g-t 2/4] tests/gem_ctx_sseu: Dynamic (sub)slice programming tests

From: Lionel Landwerlin Verify that the per-context dynamic SSEU uAPI works as expected. v2: Add subslice tests (Lionel) Use MI_SET_PREDICATE for further verification when available (Lionel) v3: Rename to gem_ctx_rpcs (Lionel) v4: Update kernel API (Lionel) Add 0 value test (Lionel)

[Intel-gfx] [PATCH i-g-t 0/4] Per context dynamic (sub)slice power-gating

From: Tvrtko Ursulin New in this version: * Updated for engine_class/engine_instance uAPI rename. Lionel Landwerlin (1): tests/gem_ctx_sseu: Dynamic (sub)slice programming tests Tony Ye (2): tests/gem_media_vme: Simple test to exercise the VME block tests/gem_media_vme: Shut down half

[Intel-gfx] [PATCH i-g-t 4/4] tests/gem_media_vme: Shut down half of subslices to avoid gpu hang on ICL

From: Tony Ye On Icelake we need to turn off subslices not containing the VME block or the VME kernel will hang. v2: (Tvrtko Ursulin) * Remove libdrm usage for setting context param. * Cleanup bitmask operation. * Only apply the workaround for ICL. v3: (Tvrtko Ursulin) * Added hang

[Intel-gfx] [PATCH i-g-t 3/4] tests/gem_media_vme: Simple test to exercise the VME block

From: Tony Ye Simple test which exercises the VME fixed function block. v2: (Tvrtko Ursulin) * Small cleanups like copyright date, tabs, remove unused bits. v3: (Tony Ye) * Added curbe data entry for dst surface. * Read the dst surface after the VME kernel being executed. v4: (Tony Ye) *

[Intel-gfx] ✗ Fi.CI.BAT: failure for Per context dynamic (sub)slice power-gating (rev13)

== Series Details == Series: Per context dynamic (sub)slice power-gating (rev13) URL : https://patchwork.freedesktop.org/series/48194/ State : failure == Summary == Applying: drm/i915/execlists: Move RPCS setup to context pin Applying: drm/i915: Record the sseu configuration per-context &

  1   2   >