[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: account for context save/restore removed bits (rev2)

2018-08-10 Thread Patchwork
== Series Details == Series: drm/i915/icl: account for context save/restore removed bits (rev2) URL : https://patchwork.freedesktop.org/series/47976/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4643_full -> Patchwork_9922_full = == Summary - WARNING == Minor unknown

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Christian König
Am 10.08.2018 um 11:21 schrieb Daniel Vetter: [SNIP] Then don't track _any_ of the amdgpu internal fences in the reservation object: - 1 reservation object that you hand to ttm, for use internally within amdgpu - 1 reservation object that you attach to the dma-buf (or get from the imported

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: account for context save/restore removed bits (rev2)

2018-08-10 Thread Patchwork
== Series Details == Series: drm/i915/icl: account for context save/restore removed bits (rev2) URL : https://patchwork.freedesktop.org/series/47976/ State : warning == Summary == $ dim checkpatch origin/drm-tip afe5704847eb drm/i915/icl: account for context save/restore removed bits -:20:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: account for context save/restore removed bits (rev2)

2018-08-10 Thread Patchwork
== Series Details == Series: drm/i915/icl: account for context save/restore removed bits (rev2) URL : https://patchwork.freedesktop.org/series/47976/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4643 -> Patchwork_9922 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Expose retry count to per gen reset logic

2018-08-10 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915: Expose retry count to per gen reset logic URL : https://patchwork.freedesktop.org/series/48019/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4643 -> Patchwork_9921 = == Summary - WARNING == Minor

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: account for context save/restore removed bits

2018-08-10 Thread Patchwork
== Series Details == Series: drm/i915/icl: account for context save/restore removed bits URL : https://patchwork.freedesktop.org/series/47976/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4643_full -> Patchwork_9919_full = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH v5 1/2] drm: Introduce new DRM_FORMAT_XYUV

2018-08-10 Thread Alexandru-Cosmin Gheorghe
Hi Stanislav, FYI, we are trying to add same format under a slightly different name. See https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html On Fri, Aug 10, 2018 at 04:19:03PM +0300, StanLis wrote: > From: Stanislav Lisovskiy > > v5: This is YUV444 packed format same as

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] igt/gem_sync: Exercising waiting while keeping the GPU busy

2018-08-10 Thread Antonio Argenziano
On 10/08/18 10:51, Chris Wilson wrote: Quoting Antonio Argenziano (2018-08-10 18:41:22) On 10/08/18 04:01, Chris Wilson wrote: Normally we wait on the last request, but that overlooks any difficulties in waiting on a request while the next is being qeued. /s/qeued/queued Check those.

[Intel-gfx] [CI] drm/i915/icl: account for context save/restore removed bits

2018-08-10 Thread Chris Wilson
From: Paulo Zanoni The RS_CTX_ENABLE and CTX_SAVE_INHIBIT bits are not present on ICL anymore, but we still try to set them and then check them with GEM_BUG_ON, resulting in a BUG() call. The bug can be reproduced by igt/drv_selftest/live_hangcheck/others-priority and our CI was able to catch

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] igt/gem_sync: Exercising waiting while keeping the GPU busy

2018-08-10 Thread Antonio Argenziano
On 10/08/18 04:01, Chris Wilson wrote: Normally we wait on the last request, but that overlooks any difficulties in waiting on a request while the next is being qeued. /s/qeued/queued Check those. Signed-off-by: Chris Wilson --- tests/gem_sync.c | 72

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Expose retry count to per gen reset logic

2018-08-10 Thread Chris Wilson
Quoting Mika Kuoppala (2018-08-10 15:00:35) > There is a possibility for per gen reset logic to > be more nasty if the softer approach on resetting does > not bear fruit. > > Expose retry count to per gen reset logic if it > wants to take such tough measures. > > Cc: Chris Wilson >

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] igt/gem_sync: Exercising waiting while keeping the GPU busy

2018-08-10 Thread Chris Wilson
Quoting Antonio Argenziano (2018-08-10 18:41:22) > > > On 10/08/18 04:01, Chris Wilson wrote: > > Normally we wait on the last request, but that overlooks any > > difficulties in waiting on a request while the next is being qeued. > > /s/qeued/queued > > > Check those. > > > > Signed-off-by:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit

2018-08-10 Thread Patchwork
== Series Details == Series: drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit URL : https://patchwork.freedesktop.org/series/48048/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4645 -> Patchwork_9923 = == Summary - SUCCESS == No regressions found. External

[Intel-gfx] [PATCH] drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit

2018-08-10 Thread Dhinakaran Pandiyan
We print the last attempted entry and last exit timestamps only when IRQ debug is requested. This check was missed when new debug flags were added in 'commit c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Cc: Maarten Lankhorst Signed-off-by: Dhinakaran Pandiyan

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit

2018-08-10 Thread Patchwork
== Series Details == Series: drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit URL : https://patchwork.freedesktop.org/series/48048/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4645_full -> Patchwork_9923_full = == Summary - WARNING == Minor unknown changes

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Expose retry count to per gen reset logic

2018-08-10 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915: Expose retry count to per gen reset logic URL : https://patchwork.freedesktop.org/series/48019/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4643_full -> Patchwork_9921_full = == Summary - SUCCESS == No

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Christian König
Am 10.08.2018 um 09:51 schrieb Chris Wilson: Quoting Christian König (2018-08-09 15:54:31) Am 09.08.2018 um 16:22 schrieb Daniel Vetter: On Thu, Aug 9, 2018 at 3:58 PM, Christian König wrote: Am 09.08.2018 um 15:38 schrieb Daniel Vetter: On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Daniel Vetter
On Thu, Aug 9, 2018 at 4:54 PM, Christian König wrote: > Am 09.08.2018 um 16:22 schrieb Daniel Vetter: >> >> On Thu, Aug 9, 2018 at 3:58 PM, Christian König >> wrote: >>> >>> Am 09.08.2018 um 15:38 schrieb Daniel Vetter: On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Skip module reloads

2018-08-10 Thread Petri Latvala
On Fri, Aug 10, 2018 at 10:02:46AM +0100, Chris Wilson wrote: > Reloading the module may impact subsequent tests by destabilising the > system. As we do for BAT, if we want to test reloads, it should be > handled explicitly at the end of the run, rather than placed at random > in the middle of the

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Daniel Vetter
On Fri, Aug 10, 2018 at 11:14 AM, Christian König wrote: > Am 10.08.2018 um 10:29 schrieb Daniel Vetter: >> >> [SNIP] >> I'm only interested in the case of shared buffers. And for those you >> _do_ pessimistically assume that all access must be implicitly synced. >> Iirc amdgpu doesn't support

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Skip module reloads

2018-08-10 Thread Chris Wilson
Quoting Petri Latvala (2018-08-10 10:11:29) > On Fri, Aug 10, 2018 at 10:02:46AM +0100, Chris Wilson wrote: > > Reloading the module may impact subsequent tests by destabilising the > > system. As we do for BAT, if we want to test reloads, it should be > > handled explicitly at the end of the run,

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Daniel Vetter
On Fri, Aug 10, 2018 at 11:14 AM, Christian König wrote: > Am 10.08.2018 um 10:29 schrieb Daniel Vetter: >> >> [SNIP] >> I'm only interested in the case of shared buffers. And for those you >> _do_ pessimistically assume that all access must be implicitly synced. >> Iirc amdgpu doesn't support

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Skip module reloads

2018-08-10 Thread Petri Latvala
On Fri, Aug 10, 2018 at 10:21:59AM +0100, Chris Wilson wrote: > Quoting Petri Latvala (2018-08-10 10:11:29) > > On Fri, Aug 10, 2018 at 10:02:46AM +0100, Chris Wilson wrote: > > > Reloading the module may impact subsequent tests by destabilising the > > > system. As we do for BAT, if we want to

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Christian König
Am 10.08.2018 um 10:32 schrieb Daniel Vetter: On Fri, Aug 10, 2018 at 10:24 AM, Christian König wrote: Am 10.08.2018 um 09:51 schrieb Chris Wilson: Quoting Christian König (2018-08-09 15:54:31) Am 09.08.2018 um 16:22 schrieb Daniel Vetter: On Thu, Aug 9, 2018 at 3:58 PM, Christian König

[Intel-gfx] [PATCH i-g-t] intel-ci: Skip module reloads

2018-08-10 Thread Chris Wilson
Reloading the module may impact subsequent tests by destabilising the system. As we do for BAT, if we want to test reloads, it should be handled explicitly at the end of the run, rather than placed at random in the middle of the test list. References:

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Christian König
Am 10.08.2018 um 10:29 schrieb Daniel Vetter: [SNIP] I'm only interested in the case of shared buffers. And for those you _do_ pessimistically assume that all access must be implicitly synced. Iirc amdgpu doesn't support EGL_ANDROID_native_fence_sync, so this makes sense that you don't bother

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Daniel Vetter
On Fri, Aug 10, 2018 at 10:51 AM, Christian König wrote: > Am 10.08.2018 um 10:32 schrieb Daniel Vetter: >> >> On Fri, Aug 10, 2018 at 10:24 AM, Christian König >> wrote: >>> >>> Am 10.08.2018 um 09:51 schrieb Chris Wilson: Quoting Christian König (2018-08-09 15:54:31) > > Am

Re: [Intel-gfx] [PATCH 2/6] dma-buf: add reservation object shared fence accessor

2018-08-10 Thread Huang Rui
On Thu, Aug 09, 2018 at 01:37:09PM +0200, Christian König wrote: > Add a helper to access the shared fences in an reservation object. > > Signed-off-by: Christian König Reviewed-by: Huang Rui > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 ++- >

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Chris Wilson
Quoting Christian König (2018-08-09 15:54:31) > Am 09.08.2018 um 16:22 schrieb Daniel Vetter: > > On Thu, Aug 9, 2018 at 3:58 PM, Christian König > > wrote: > >> Am 09.08.2018 um 15:38 schrieb Daniel Vetter: > >>> On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote: > >>> [SNIP] > >>

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

2018-08-10 Thread Daniel Vetter
On Fri, Aug 10, 2018 at 10:24 AM, Christian König wrote: > Am 10.08.2018 um 09:51 schrieb Chris Wilson: >> >> Quoting Christian König (2018-08-09 15:54:31) >>> >>> Am 09.08.2018 um 16:22 schrieb Daniel Vetter: On Thu, Aug 9, 2018 at 3:58 PM, Christian König wrote: > > Am

[Intel-gfx] [PATCH i-g-t 1/2] intel-ci: Comment on kernel selftest exclusion

2018-08-10 Thread Chris Wilson
The kernel selftests are excluded from the shard lists as those lists are compiled separately. Signed-off-by: Chris Wilson --- tests/intel-ci/blacklist.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index

[Intel-gfx] [PATCH i-g-t 2/2] intel-ci: Skip module reloads

2018-08-10 Thread Chris Wilson
Reloading the module may impact subsequent tests by destabilising the system. As we do for BAT, if we want to test reloads, it should be handled explicitly at the end of the run, rather than placed at random in the middle of the test list. v2: Commentary References:

[Intel-gfx] [PATCH i-g-t 1/2] igt/pm_rpm: Test incomplete(debug) suspends vs rpm

2018-08-10 Thread Chris Wilson
Check that we restore runtime pm around debug suspends and hibernates. v2: Differentiate between external test setup failure and one of interest Signed-off-by: Chris Wilson --- tests/pm_rpm.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/tests/pm_rpm.c

[Intel-gfx] [PATCH i-g-t 2/2] igt/pm_rpm: Test reaquisition of runtime-pm after module reload

2018-08-10 Thread Chris Wilson
It doesn't work right now and desperately needs to be fixed... Signed-off-by: Chris Wilson --- tests/intel-ci/fast-feedback.testlist | 1 + tests/pm_rpm.c| 28 --- 2 files changed, 26 insertions(+), 3 deletions(-) diff --git

Re: [Intel-gfx] [PATCH] dma-buf: Remove requirement for ops->map() from dma_buf_export

2018-08-10 Thread Gerd Hoffmann
On Tue, Aug 07, 2018 at 07:36:47PM +0100, Chris Wilson wrote: > Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function > pointers optional"), the core provides the no-op functions when map and > map_atomic are not provided, so we no longer need assert that are > supplied by a dma-buf

[Intel-gfx] [RFC 3/8] drm/i915: Markup paired operations on wakerefs

2018-08-10 Thread Chris Wilson
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] [RFC 4/8] drm/i915: Syntatic sugar for using intel_runtime_pm

2018-08-10 Thread Chris Wilson
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 ---

[Intel-gfx] [RFC 6/8] drm/i915/dp: Markup pps lock power well

2018-08-10 Thread Chris Wilson
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 --- drivers/gpu/drm/i915/intel_dp.c | 226 +--- 1 file changed, 117 insertions(+), 109

[Intel-gfx] [RFC 1/8] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable

2018-08-10 Thread Chris Wilson
Currently, we cancel the extra wakeref we have for !runtime-pm devices inside power_wells_fini_hw. However, this is not strictly paired with the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may be called on errors paths before we even call runtime_pm_enable). Make the symmetry

[Intel-gfx] [RFC 8/8] drm/i915: Track crtc wakerefs during modesetting

2018-08-10 Thread Chris Wilson
Modesetting is one of the more complex interactions with power wells as it acquires multiple wells to do its business. Fortunately, we do not have to track every one individually as they are all called from the same location and thus will have matching wakerefs (being a hash of its stacktrace).

[Intel-gfx] [RFC 5/8] drm/i915: Markup paired operations on display power domains

2018-08-10 Thread Chris Wilson
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] [RFC 2/8] drm/i915: Track all held rpm wakerefs

2018-08-10 Thread Chris Wilson
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. Signed-off-by: Chris Wilson ---

[Intel-gfx] [RFC 7/8] drm/i915: Complain is hsw_get_pipe_config acquires the same power well twice

2018-08-10 Thread Chris Wilson
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 --- drivers/gpu/drm/i915/intel_display.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c

Re: [Intel-gfx] [v3] drm/i915: Add detection of changing of edid on between suspend and resume

2018-08-10 Thread Lisovskiy, Stanislav
On Thu, 2018-08-09 at 14:13 +0300, Gwan-gyeong Mun wrote: > The hotplug detection routine of i915 uses > drm_helper_hpd_irq_event(). This > helper can detect changing of status of connector, but it can not > detect > changing of edid. > > Following scenario requires detection of changing of edid.

[Intel-gfx] [PATCH v5 0/2] Add XYUV format support

2018-08-10 Thread StanLis
From: Stanislav Lisovskiy Introduced new XYUV scan-in format for framebuffer and added support for it to i915 driver. Stanislav Lisovskiy (2): drm: Introduce new DRM_FORMAT_XYUV drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support. drivers/gpu/drm/drm_fourcc.c | 1 +

[Intel-gfx] [PATCH v5 1/2] drm: Introduce new DRM_FORMAT_XYUV

2018-08-10 Thread StanLis
From: Stanislav Lisovskiy v5: This is YUV444 packed format same as AYUV, but without alpha, as supported by i915. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/drm_fourcc.c | 1 + include/uapi/drm/drm_fourcc.h | 1 + 2 files changed, 2 insertions(+) diff --git

[Intel-gfx] [PATCH v5 2/2] drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support.

2018-08-10 Thread StanLis
From: Stanislav Lisovskiy PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification. v2: Edited commit message, removed redundant whitespaces. v3: Fixed fallthrough logic for the format switch cases. v4: Yet again fixed fallthrough logic, to reuse code from other case

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] igt/perf_pmu: Aim for a fixed number of iterations for calibrating accuracy

2018-08-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-08-09 12:54:41) > > On 08/08/2018 15:59, Chris Wilson wrote: > > Our observation is that the systematic error is proportional to the > > number of iterations we perform; the suspicion is that it directly > > correlates with the number of sleeps. Reduce the number of

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915: Allow control of PSR at runtime through debugfs, v6

2018-08-10 Thread Maarten Lankhorst
Op 09-08-18 om 16:21 schreef Maarten Lankhorst: > Currently tests modify i915.enable_psr and then do a modeset cycle > to change PSR. We can write a value to i915_edp_psr_debug to force > a certain PSR mode without a modeset. > > To retain compatibility with older userspace, we also still allow >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: account for context save/restore removed bits

2018-08-10 Thread Patchwork
== Series Details == Series: drm/i915/icl: account for context save/restore removed bits URL : https://patchwork.freedesktop.org/series/47976/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4643 -> Patchwork_9919 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [RFC 1/8] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable

2018-08-10 Thread Imre Deak
On Fri, Aug 10, 2018 at 08:11:31AM +0100, Chris Wilson wrote: > Currently, we cancel the extra wakeref we have for !runtime-pm devices > inside power_wells_fini_hw. However, this is not strictly paired with > the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may > be called on

Re: [Intel-gfx] [RFC 1/8] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable

2018-08-10 Thread Chris Wilson
Quoting Imre Deak (2018-08-10 13:22:43) > On Fri, Aug 10, 2018 at 08:11:31AM +0100, Chris Wilson wrote: > > @@ -1474,6 +1476,8 @@ void i915_driver_unload(struct drm_device *dev) > > i915_driver_cleanup_mmio(dev_priv); > > > > intel_display_power_put(dev_priv, POWER_DOMAIN_INIT); > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RFC,1/8] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable (rev2)

2018-08-10 Thread Patchwork
== Series Details == Series: series starting with [RFC,1/8] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable (rev2) URL : https://patchwork.freedesktop.org/series/47989/ State : failure == Summary == Applying: drm/i915: Introduce intel_runtime_pm_disable to pair

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] intel-ci: Skip module reloads

2018-08-10 Thread Petri Latvala
On Fri, Aug 10, 2018 at 10:41:45AM +0100, Chris Wilson wrote: > Reloading the module may impact subsequent tests by destabilising the > system. As we do for BAT, if we want to test reloads, it should be > handled explicitly at the end of the run, rather than placed at random > in the middle of the

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] intel-ci: Skip module reloads

2018-08-10 Thread Chris Wilson
Quoting Petri Latvala (2018-08-10 10:55:06) > On Fri, Aug 10, 2018 at 10:41:45AM +0100, Chris Wilson wrote: > > Reloading the module may impact subsequent tests by destabilising the > > system. As we do for BAT, if we want to test reloads, it should be > > handled explicitly at the end of the run,

[Intel-gfx] [PATCH i-g-t 3/3] igt/gem_sync: Exercising waiting while keeping the GPU busy

2018-08-10 Thread Chris Wilson
Normally we wait on the last request, but that overlooks any difficulties in waiting on a request while the next is being qeued. Check those. Signed-off-by: Chris Wilson --- tests/gem_sync.c | 72 1 file changed, 72 insertions(+) diff --git

[Intel-gfx] [PATCH i-g-t 2/3] gem_sync: Measure wakeup latency while also scheduling the next batch

2018-08-10 Thread Chris Wilson
More variants on stress waits to serve the dual purpose of investigating different aspects of the latency (this time while also serving execlists interrupts) while also checking that we never miss the wakeup. Signed-off-by: Chris Wilson --- tests/gem_sync.c | 142

[Intel-gfx] [PATCH i-g-t 1/3] igt/gem_sync: Exercise sync after context switch

2018-08-10 Thread Chris Wilson
This exercises a special case that may be of interest, waiting for a context that may be preempted in order to reduce the wait. Signed-off-by: Chris Wilson --- tests/gem_sync.c | 146 +++ 1 file changed, 146 insertions(+) diff --git

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RFC,1/8] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable

2018-08-10 Thread Patchwork
== Series Details == Series: series starting with [RFC,1/8] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable URL : https://patchwork.freedesktop.org/series/47989/ State : failure == Summary == Applying: drm/i915: Introduce intel_runtime_pm_disable to pair

[Intel-gfx] [PATCH 2/2] drm/i915: Force reset on unready engine

2018-08-10 Thread Mika Kuoppala
If engine reports that it is not ready for reset, we give up. Evidence shows that forcing a per engine reset on an engine which is not reporting to be ready for reset, can bring it back into a working order. There is risk that we corrupt the context image currently executing on that engine. But

[Intel-gfx] [PATCH 1/2] drm/i915: Expose retry count to per gen reset logic

2018-08-10 Thread Mika Kuoppala
There is a possibility for per gen reset logic to be more nasty if the softer approach on resetting does not bear fruit. Expose retry count to per gen reset logic if it wants to take such tough measures. Cc: Chris Wilson Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_uncore.c |

Re: [Intel-gfx] [RFC 1/8] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable

2018-08-10 Thread Imre Deak
On Fri, Aug 10, 2018 at 01:33:19PM +0100, Chris Wilson wrote: > Quoting Imre Deak (2018-08-10 13:22:43) > > On Fri, Aug 10, 2018 at 08:11:31AM +0100, Chris Wilson wrote: > > > @@ -1474,6 +1476,8 @@ void i915_driver_unload(struct drm_device *dev) > > > i915_driver_cleanup_mmio(dev_priv); > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Force reset on unready engine

2018-08-10 Thread Chris Wilson
Quoting Mika Kuoppala (2018-08-10 15:00:36) > If engine reports that it is not ready for reset, we > give up. Evidence shows that forcing a per engine reset > on an engine which is not reporting to be ready for reset, > can bring it back into a working order. There is risk that > we corrupt the