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] ✓ 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

[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

[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 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

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 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] ✓ 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

[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.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] [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: 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] [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] [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 ---

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] ✓ 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

[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] ✗ 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] [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

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 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

[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

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] [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 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 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] 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] [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] [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 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 |

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] ✗ 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] 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 |

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.

[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] [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 >

[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] ✗ 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 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

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

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 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

[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

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 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 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] [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

[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] ✗ 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 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

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] [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

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 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

[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

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] ✓ 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 ---

[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] [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(-)

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 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(+),

[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 ---

[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

[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 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 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 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] [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] ✗ 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] ✗ Fi.CI.CHECKPATCH: 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 checkpatch origin/drm-tip bef4bdb66bef drm/i915/execlists: Move RPCS setup to context pin 495ee6ca200b drm/i915: Record

[Intel-gfx] [PATCH 6/6] drm/i915/selftests: Context SSEU reconfiguration tests

From: Tvrtko Ursulin Exercise the context image reconfiguration logic for idle and busy contexts, with the resets thrown into the mix as well. Free from the uAPI restrictions this test runs on all Gen9+ platforms with slice power gating. v2: * Rename some helpers for clarity. * Include

[Intel-gfx] [PATCH 4/6] drm/i915: Add timeline barrier support

From: Tvrtko Ursulin Timeline barrier allows serialization between different timelines. After calling i915_timeline_set_barrier with a request, all following submissions on this timeline will be set up as depending on this request, or barrier. Once the barrier has been completed it

[Intel-gfx] [PATCH 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

[Intel-gfx] [PATCH 1/6] drm/i915/execlists: Move RPCS setup to context pin

From: Tvrtko Ursulin Configuring RPCS in context image just before pin is sufficient and will come extra handy in one of the following patches. v2: * Split image setup a bit differently. (Chris Wilson) v3: * Update context image after reset as well - otherwise the application of pinned

[Intel-gfx] [PATCH 0/6] Per context dynamic (sub)slice power-gating

From: Tvrtko Ursulin Changes since last version: * Rebase for drm-tip changes. Test-with: 20190114102955.10721-1-tvrtko.ursu...@linux.intel.com Lionel Landwerlin (2): drm/i915: Record the sseu configuration per-context & engine drm/i915/perf: lock powergating configuration to default when

[Intel-gfx] [PATCH 3/6] drm/i915/perf: lock powergating configuration to default when active

From: Lionel Landwerlin If some of the contexts submitting workloads to the GPU have been configured to shutdown slices/subslices, we might loose the NOA configurations written in the NOA muxes. One possible solution to this problem is to reprogram the NOA muxes when we switch to a new context.

[Intel-gfx] [PATCH 2/6] drm/i915: Record the sseu configuration per-context & engine

From: Lionel Landwerlin We want to expose the ability to reconfigure the slices, subslice and eu per context and per engine. To facilitate that, store the current configuration on the context for each engine, which is initially set to the device default upon creation. v2: record sseu

[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 &

[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

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.CHECKPATCH: warning 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 : warning == Summary == $ dim checkpatch origin/drm-tip 57a47732f5af drm: annotate drm_core_check_feature() dev arg.

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

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 expected because IGT will take > the first

[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 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

  1   2   >