Re: [Intel-gfx] Reviving the LPSS PWM patches

2016-04-09 Thread Lluís Batlle i Rossell 
On Sat, Apr 09, 2016 at 11:14:38AM +0200, Lluís Batlle i Rossell wrote:
> On Thu, Apr 07, 2016 at 11:54:39AM +0200, Lluís Batlle i Rossell wrote:
> > On Thu, Apr 07, 2016 at 03:19:04PM +0530, Kumar, Shobhit wrote:
> > > On Wednesday 06 April 2016 04:26 PM, Lluís Batlle i Rossell wrote:
> > > >I don't see any trace of pwm/lpss in dmesg, so it's normal that i915 
> > > >fails
> > > >to find it. I wonder if there may be a problem in the ACPI table. I have
> > > >the DSDT and it clearly reports the:
> > > >
> > > >Name (_CID, "80860F09")  // _CID: Compatible ID
> > > >Name (_DDN, "Intel(R) PWM Controller #2 - 80860F09")  // _DDN: DOS 
> > > >Device Name
> > > >
> > > >Which should be the lpss pwm. But somehow it is not loaded, so I guess it
> > > >fails the probing.
> > > 
> > > Can we put some prints in the probe routines and see whats happening in 
> > > the
> > > pwm-lpss-platform.c driver. There is also a PCI PWM LPSS driver -
> > > pwm-lpss-pci.c Can you also enable that and see if the probe for that is
> > > being called and successful ?

I think there is a lot to be done first, to be able to test this.

If I understand correctly, despite the lpss pwm may be available, it will
not be used as pwm-backlight (video/backlight/pwm_bl.c) because it depends
on "CONFIG_OF" and it is ready for devicetree only.

The only x86 that enable OF are X86_INTEL_CE and OLPC, and pwm_bl is
completely disabled without OF. I don't have any INTEL_CE or OLPC, this
LPSS of the Atom SoC is a different thing.

So, someone has to implement pwm_bl on my x86 first, for any of the
patches wrt i915 to be used at all. Should X86_INTEL_LPSS enable OF?
Should there be a devicetree definition for it first? Does someone have to
allow pwm_bl to work with ACPI? Is all that ready in some branch of some
other linux team?

Regards,
Lluís.

-- 
(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
PGP key D4831A8A - https://emailselfdefense.fsf.org/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

2016-04-09 Thread enpeng xu 
I found this issue when i run glbenchmark25, anyway, good to know, thanks.
Regards
Enpeng

On Saturday, April 9, 2016, Matthew Auld 
wrote:
> There's already a patch in the works for this:
> https://patchwork.freedesktop.org/patch/80078/
>
> Regards,
> Matt
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

2016-04-09 Thread Matthew Auld 
There's already a patch in the works for this:
https://patchwork.freedesktop.org/patch/80078/

Regards,
Matt
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

2016-04-09 Thread Patchwork 
== Series Details ==

Series: fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to 
kunmap_px.
URL   : https://patchwork.freedesktop.org/series/5490/
State : failure

== Summary ==

Series 5490v1 fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to 
kunmap_px.
http://patchwork.freedesktop.org/api/1.0/series/5490/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (ilk-hp8440p)
Test gem_exec_store:
Subgroup basic-blt:
pass   -> INCOMPLETE (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-small-copy:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2total:175  pass:137  dwarn:2   dfail:0   fail:1   skip:34 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 
BOOT FAILED for bdw-ultra

Results at /archive/results/CI_IGT_test/Patchwork_1856/

56aa709c9614bf7f39ee255fd0ddf4f1b2743387 drm-intel-nightly: 
2016y-04m-09d-11h-10m-49s UTC integration manifest
024596b2d693181736f63cc0c8126d8f0aeccdfb fix bug in function 
gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

2016-04-09 Thread enpengxu 
From: Enpeng Xu 

Signed-off-by: Enpeng Xu 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 49e4f26..527eca7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -746,7 +746,7 @@ static void gen8_ppgtt_clear_pte_range(struct 
i915_address_space *vm,
num_entries--;
}
 
-   kunmap_px(ppgtt, pt);
+   kunmap_px(ppgtt, pt_vaddr);
 
pte = 0;
if (++pde == I915_PDES) {
-- 
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915: Force clean compilation with -Werror

2016-04-09 Thread Chris Wilson 
On Sat, Apr 09, 2016 at 12:27:35PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [01/10] drm/i915: Force clean compilation with 
> -Werror
> URL   : https://patchwork.freedesktop.org/series/5487/
> State : failure
> 
> == Summary ==
> 
> Series 5487v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/5487/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (ilk-hp8440p)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
> Subgroup basic-flip-vs-modeset:
> pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-a:
> skip   -> FAIL   (bsw-nuc-2)

Forgot to push the test fix since it was using the defunct debug-only
mechanism and not hanging the GPU at all.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915: Force clean compilation with -Werror

2016-04-09 Thread Patchwork 
== Series Details ==

Series: series starting with [01/10] drm/i915: Force clean compilation with 
-Werror
URL   : https://patchwork.freedesktop.org/series/5487/
State : failure

== Summary ==

Series 5487v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5487/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> FAIL   (bsw-nuc-2)
pass   -> FAIL   (ivb-t430s)
pass   -> FAIL   (bdw-ultra)
pass   -> FAIL   (skl-i7k-2)
pass   -> FAIL   (byt-nuc)
pass   -> FAIL   (snb-x220t)
pass   -> FAIL   (snb-dellxps)
pass   -> FAIL   (hsw-brixbox)
pass   -> FAIL   (bdw-nuci7)
pass   -> FAIL   (ilk-hp8440p)
Subgroup hang-read-crc-pipe-b:
skip   -> FAIL   (bsw-nuc-2)
pass   -> FAIL   (ivb-t430s)
pass   -> FAIL   (bdw-ultra)
pass   -> FAIL   (skl-i7k-2)
pass   -> FAIL   (byt-nuc)
pass   -> FAIL   (snb-x220t)
pass   -> FAIL   (snb-dellxps)
pass   -> FAIL   (hsw-brixbox)
pass   -> FAIL   (bdw-nuci7)
pass   -> FAIL   (ilk-hp8440p)
Subgroup hang-read-crc-pipe-c:
pass   -> FAIL   (bsw-nuc-2)
pass   -> FAIL   (ivb-t430s)
pass   -> FAIL   (bdw-ultra)
pass   -> FAIL   (skl-i7k-2)
skip   -> FAIL   (byt-nuc)
skip   -> FAIL   (snb-x220t)
skip   -> FAIL   (snb-dellxps)
pass   -> FAIL   (hsw-brixbox)
pass   -> FAIL   (bdw-nuci7)
skip   -> FAIL   (ilk-hp8440p)

bdw-nuci7total:196  pass:181  dwarn:0   dfail:0   fail:3   skip:12 
bdw-ultratotal:196  pass:172  dwarn:0   dfail:0   fail:3   skip:21 
bsw-nuc-2total:196  pass:158  dwarn:0   dfail:0   fail:3   skip:35 
byt-nuc  total:196  pass:159  dwarn:0   dfail:0   fail:3   skip:34 
hsw-brixbox  total:196  pass:171  dwarn:0   dfail:0   fail:3   skip:22 
ilk-hp8440p  total:196  pass:128  dwarn:2   dfail:0   fail:3   skip:63 
ivb-t430stotal:196  pass:168  dwarn:0   dfail:0   fail:3   skip:25 
skl-i7k-2total:196  pass:170  dwarn:0   dfail:0   fail:3   skip:23 
snb-dellxps  total:196  pass:160  dwarn:0   dfail:0   fail:3   skip:33 
snb-x220ttotal:196  pass:160  dwarn:0   dfail:0   fail:4   skip:32 

Results at /archive/results/CI_IGT_test/Patchwork_1855/

56aa709c9614bf7f39ee255fd0ddf4f1b2743387 drm-intel-nightly: 
2016y-04m-09d-11h-10m-49s UTC integration manifest
2991addbcc20b7c9edef418e957f0a4b5f3f6338 drm/i915: Suppress error message when 
GPU resets are disabled
2d2ba3cc386af50a9dbd5fe68eac37d8a6483878 drm/i915: Prevent leaking of -EIO from 
i915_wait_request()
8d03b898b939ac59dec888dbdaa4fc7785c7d0d0 drm/i915: Simplify reset_counter 
handling during atomic modesetting
c17a7f934130cff780c8195adcd158f9cc16e2a2 drm/i915: Store the reset counter when 
constructing a request
eddf9a904c8c4d3f840af264fa069cd5cdbb9ff0 drm/i915: Tighten reset_counter for 
reset status
51e07f54e96cf699b532b0d9ede3ffe84a757c94 drm/i915: Simplify checking of GPU 
reset_counter in display pageflips
c99c64ac47dff274a4d3da9dc31f0210832b8e17 drm/i915: Hide the 
atomic_read(reset_counter) behind a helper
1ce3cd107f28e31cc0bf43281bd863e4a1c3a8b2 drm/i915: Add GEM debugging Kconfig 
option
c68a744b2ec476f0ab5b576a3409b09a289e2f85 drm/i915: Disentangle i915_drv.h 
includes
7baec233ff87dd04ef53d8c10f9fc26438ca944f drm/i915: Force clean compilation with 
-Werror

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/10] drm/i915: Simplify reset_counter handling during atomic modesetting

2016-04-09 Thread Chris Wilson 
Now that the reset_counter is stored on the request, we can rearrange
the code to handle reading the counter versus waiting during the atomic
modesetting for readibility (by deleting the hairiest of codes).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 438e2f7ca836..8858f57488a6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13384,9 +13384,9 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
return ret;
 
ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (!ret && !async && 
!i915_reset_in_progress_or_wedged(_priv->gpu_error)) {
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>struct_mutex);
 
+   if (!ret && !async) {
for_each_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
@@ -13400,19 +13400,15 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
/* Swallow -EIO errors to allow updates during hw 
lockup. */
if (ret == -EIO)
ret = 0;
-
-   if (ret)
+   if (ret) {
+   mutex_lock(>struct_mutex);
+   drm_atomic_helper_cleanup_planes(dev, state);
+   mutex_unlock(>struct_mutex);
break;
+   }
}
-
-   if (!ret)
-   return 0;
-
-   mutex_lock(>struct_mutex);
-   drm_atomic_helper_cleanup_planes(dev, state);
}
 
-   mutex_unlock(>struct_mutex);
return ret;
 }
 
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] EIO cleanup

2016-04-09 Thread Chris Wilson 
Mostly reviewed series, just 2/10 needs attention (and 1/10 will be good
to run through 0day to make sure it is invisible to the automated builders).
-Chris

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 07/10] drm/i915: Store the reset counter when constructing a request

2016-04-09 Thread Chris Wilson 
As the request is only valid during the same global reset epoch, we can
record the current reset_counter when constructing the request and reuse
it when waiting upon that request in future. This removes a very hairy
atomic check serialised by the struct_mutex at the time of waiting and
allows us to transfer those waits to a central dispatcher for all
waiters and all requests.

PS: With per-engine resets, we obviously cannot assume a global reset
epoch for the requests - a per-engine epoch makes the most sense. The
challenge then is how to handle checking in the waiter for when to break
the wait, as the fine-grained reset may also want to requeue the
request (i.e. the assumption that just because the epoch changes the
request is completed may be broken - or we just avoid breaking that
assumption with the fine-grained resets).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by:: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 40 +++--
 drivers/gpu/drm/i915/intel_display.c|  7 +-
 drivers/gpu/drm/i915/intel_lrc.c|  7 --
 drivers/gpu/drm/i915/intel_ringbuffer.c |  6 -
 5 files changed, 15 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4026babd43b..02e56161fac2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2243,6 +2243,7 @@ struct drm_i915_gem_request {
/** On Which ring this request was generated */
struct drm_i915_private *i915;
struct intel_engine_cs *engine;
+   unsigned reset_counter;
 
 /** GEM sequence number associated with the previous request,
  * when the HWS breadcrumb is equal to this the GPU is processing
@@ -3116,7 +3117,6 @@ void __i915_add_request(struct drm_i915_gem_request *req,
 #define i915_add_request_no_flush(req) \
__i915_add_request(req, NULL, false)
 int __i915_wait_request(struct drm_i915_gem_request *req,
-   unsigned reset_counter,
bool interruptible,
s64 *timeout,
struct intel_rps_client *rps);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2cab1786be79..80ca6bab3258 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1213,7 +1213,6 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
 /**
  * __i915_wait_request - wait until execution of request has finished
  * @req: duh!
- * @reset_counter: reset sequence associated with the given request
  * @interruptible: do an interruptible wait (normally yes)
  * @timeout: in - how long to wait (NULL forever); out - how much time 
remaining
  *
@@ -1228,7 +1227,6 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
  * errno with remaining time filled in timeout argument.
  */
 int __i915_wait_request(struct drm_i915_gem_request *req,
-   unsigned reset_counter,
bool interruptible,
s64 *timeout,
struct intel_rps_client *rps)
@@ -1290,7 +1288,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
-   if (reset_counter != i915_reset_counter(_priv->gpu_error)) {
+   if (req->reset_counter != 
i915_reset_counter(_priv->gpu_error)) {
/* ... but upgrade the -EAGAIN to an -EIO if the gpu
 * is truely gone. */
ret = i915_gem_check_wedge(_priv->gpu_error, 
interruptible);
@@ -1460,13 +1458,7 @@ i915_wait_request(struct drm_i915_gem_request *req)
 
BUG_ON(!mutex_is_locked(>struct_mutex));
 
-   ret = i915_gem_check_wedge(_priv->gpu_error, interruptible);
-   if (ret)
-   return ret;
-
-   ret = __i915_wait_request(req,
- i915_reset_counter(_priv->gpu_error),
- interruptible, NULL, NULL);
+   ret = __i915_wait_request(req, interruptible, NULL, NULL);
if (ret)
return ret;
 
@@ -1541,7 +1533,6 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
-   unsigned reset_counter;
int ret, i, n = 0;
 
BUG_ON(!mutex_is_locked(>struct_mutex));
@@ -1550,12 +1541,6 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
if (!obj->active)
return 0;
 
-   ret =

[Intel-gfx] [PATCH 01/10] drm/i915: Force clean compilation with -Werror

2016-04-09 Thread Chris Wilson 
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the patch.)

v2: Kick off a new "Debugging" submenu for i915.ko

At this point, we applied it to the kernel and promptly kicked it out
again as it broke buildbots (due to a compiler warning on 32bits):

commit 908d759b210effb33d927a8cb6603a16448474e4
Author: Daniel Vetter 
Date:   Tue May 26 07:46:21 2015 +0200

Revert "drm/i915: Force clean compilation with -Werror"

v3: Avoid enabling -Werror for allyesconfig/allmodconfig builds, using
COMPILE_TEST as a suitable proxy suggested by Andrew Morton. (Damien)
Only make the option available for EXPERT to reinforce that the option
should not be casually enabled.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Damien Lespiau 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/Kconfig.debug | 17 +
 drivers/gpu/drm/i915/Makefile  |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 649a562ddf17..61485c8ba3a8 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -1,3 +1,20 @@
+config DRM_I915_WERROR
+bool "Force GCC to throw an error instead of a warning when compiling"
+# As this may inadvertently break the build, only allow the user
+# to shoot oneself in the foot iff they aim really hard
+depends on EXPERT
+# We use the dependency on !COMPILE_TEST to not be enabled in
+# allmodconfig or allyesconfig configurations
+depends on !COMPILE_TEST
+default n
+help
+  Add -Werror to the build flags for (and only for) i915.ko.
+  Do not enable this unless you are writing code for the i915.ko 
module.
+
+  Recommended for driver developers only.
+
+  If in doubt, say "N".
+
 config DRM_I915_DEBUG
 bool "Enable additional driver debugging"
 depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b0cbc2..0b88ba0f3c1f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
+subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror
+
 # Please keep these build lists sorted!
 
 # core driver code
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 09/10] drm/i915: Prevent leaking of -EIO from i915_wait_request()

2016-04-09 Thread Chris Wilson 
Reporting -EIO from i915_wait_request() has proven very troublematic
over the years, with numerous hard-to-reproduce bugs cropping up in the
corner case of where a reset occurs and the code wasn't expecting such
an error.

If the we reset the GPU or have detected a hang and wish to reset the
GPU, the request is forcibly complete and the wait broken. Currently, we
report either -EAGAIN or -EIO in order for the caller to retreat and
restart the wait (if appropriate) after dropping and then reacquiring
the struct_mutex (essential to allow the GPU reset to proceed). However,
if we take the view that the request is complete (no further work will
be done on it by the GPU because it is dead and soon to be reset), then
we can proceed with the task at hand and then drop the struct_mutex
allowing the reset to occur. This transfers the burden of checking
whether it is safe to proceed to the caller, which in all but one
instance it is safe - completely eliminating the source of all spurious
-EIO.

Of note, we only have two API entry points where we expect that
userspace can observe an EIO. First is when submitting an execbuf, if
the GPU is terminally wedged, then the operation cannot succeed and an
-EIO is reported. Secondly, existing userspace uses the throttle ioctl
to detect an already wedged GPU before starting using HW acceleration
(or to confirm that the GPU is wedged after an error condition). So if
the GPU is wedged when the user calls throttle, also report -EIO.

v2: Split more carefully the change to i915_wait_request() and assorted
ABI from the reset handling.
v3: Add a couple of WARN_ON(EIO) to the interruptible modesetting code
so that we don't start to leak EIO there in future (and break our hang
resistant modesetting).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 --
 drivers/gpu/drm/i915/i915_gem.c | 44 -
 drivers/gpu/drm/i915/i915_gem_userptr.c |  6 ++---
 drivers/gpu/drm/i915/intel_display.c| 13 +-
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  3 +--
 6 files changed, 32 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 02e56161fac2..97ff6eeb1f0c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3044,8 +3044,6 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine);
 
 bool i915_gem_retire_requests(struct drm_device *dev);
 void i915_gem_retire_requests_ring(struct intel_engine_cs *engine);
-int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
- bool interruptible);
 
 static inline u32 i915_reset_counter(struct i915_gpu_error *error)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 80ca6bab3258..04678942fc32 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -206,11 +206,10 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object 
*obj)
BUG_ON(obj->madv == __I915_MADV_PURGED);
 
ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret) {
+   if (WARN_ON(ret)) {
/* In the event of a disaster, abandon all caches and
 * hope for the best.
 */
-   WARN_ON(ret != -EIO);
obj->base.read_domains = obj->base.write_domain = 
I915_GEM_DOMAIN_CPU;
}
 
@@ -1105,15 +1104,13 @@ put_rpm:
return ret;
 }
 
-int
-i915_gem_check_wedge(struct i915_gpu_error *error,
-bool interruptible)
+static int
+i915_gem_check_wedge(unsigned reset_counter, bool interruptible)
 {
-   if (i915_reset_in_progress_or_wedged(error)) {
-   /* Recovery complete, but the reset failed ... */
-   if (i915_terminally_wedged(error))
-   return -EIO;
+   if (__i915_terminally_wedged(reset_counter))
+   return -EIO;
 
+   if (__i915_reset_in_progress(reset_counter)) {
/* Non-interruptible callers can't handle -EAGAIN, hence return
 * -EIO unconditionally for these. */
if (!interruptible)
@@ -1287,13 +1284,14 @@ int __i915_wait_request(struct drm_i915_gem_request 
*req,
prepare_to_wait(>irq_queue, , state);
 
/* We need to check whether any gpu reset happened in between
-* the caller grabbing the seqno and now ... */
+* the request being submitted and now. If a reset has occurred,
+* the request is effectively complete (we either are in the
+* process of or have discarded the rendering and completely
+* reset the GPU. The results of the request are lost and we
+* are free to continue

[Intel-gfx] [PATCH 05/10] drm/i915: Simplify checking of GPU reset_counter in display pageflips

2016-04-09 Thread Chris Wilson 
If we, when we store the reset_counter for the operation, we ensure that
it is not in a wedged or in the middle of a reset, we can then assert that
if any reset occurs the reset_counter must change. Later we can just
compare the operation's reset epoch against the current counter to see
if we need to abort the operation (to handle the hang).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a1a15342be72..3c01ebf10fa2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3198,14 +3198,12 @@ void intel_finish_reset(struct drm_device *dev)
 static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
unsigned reset_counter;
bool pending;
 
-   reset_counter = i915_reset_counter(_priv->gpu_error);
-   if (intel_crtc->reset_counter != reset_counter ||
-   __i915_reset_in_progress_or_wedged(reset_counter))
+   reset_counter = i915_reset_counter(_i915(dev)->gpu_error);
+   if (intel_crtc->reset_counter != reset_counter)
return false;
 
spin_lock_irq(>event_lock);
@@ -10908,8 +10906,7 @@ static bool page_flip_finished(struct intel_crtc *crtc)
unsigned reset_counter;
 
reset_counter = i915_reset_counter(_priv->gpu_error);
-   if (crtc->reset_counter != reset_counter ||
-   __i915_reset_in_progress_or_wedged(reset_counter))
+   if (crtc->reset_counter != reset_counter)
return true;
 
/*
@@ -11571,8 +11568,13 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (ret)
goto cleanup;
 
-   atomic_inc(_crtc->unpin_work_count);
intel_crtc->reset_counter = i915_reset_counter(_priv->gpu_error);
+   if (__i915_reset_in_progress_or_wedged(intel_crtc->reset_counter)) {
+   ret = -EIO;
+   goto cleanup;
+   }
+
+   atomic_inc(_crtc->unpin_work_count);
 
if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev))
work->flip_count = I915_READ(PIPE_FLIPCOUNT_G4X(pipe)) + 1;
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/10] drm/i915: Add GEM debugging Kconfig option

2016-04-09 Thread Chris Wilson 
Currently there is a #define to enable extra BUG_ON for debugging
requests and associated activities. I want to expand its use to cover
all of GEM internals (so that we can saturate the code with asserts).
We can add a Kconfig option to make it easier to enable - with the usual
caveats of not enabling unless explicitly requested.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Kconfig.debug | 12 
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_gem.c| 12 +---
 drivers/gpu/drm/i915/i915_gem.h| 34 ++
 4 files changed, 52 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem.h

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 61485c8ba3a8..8f404103341d 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -27,3 +27,15 @@ config DRM_I915_DEBUG
 
   If in doubt, say "N".
 
+config DRM_I915_DEBUG_GEM
+bool "Insert extra checks into the GEM internals"
+default n
+depends on DRM_I915_WERROR
+help
+  Enable extra sanity checks (including BUGs) along the GEM driver
+  paths that may slow the system down and if hit hang the machine.
+
+  Recommended for driver developers only.
+
+  If in doubt, say "N".
+
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1753077aebbc..fcecc0a7332f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -57,6 +57,7 @@
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
 
+#include "i915_gem.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_render_state.h"
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a65a7663b88..716b7e00dd88 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -38,8 +38,6 @@
 #include 
 #include 
 
-#define RQ_BUG_ON(expr)
-
 static void i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object 
*obj);
 static void i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object 
*obj);
 static void
@@ -1521,7 +1519,7 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj,
 
i915_gem_object_retire__read(obj, i);
}
-   RQ_BUG_ON(obj->active);
+   GEM_BUG_ON(obj->active);
}
 
return 0;
@@ -2422,8 +2420,8 @@ void i915_vma_move_to_active(struct i915_vma *vma,
 static void
 i915_gem_object_retire__write(struct drm_i915_gem_object *obj)
 {
-   RQ_BUG_ON(obj->last_write_req == NULL);
-   RQ_BUG_ON(!(obj->active & 
intel_engine_flag(obj->last_write_req->engine)));
+   GEM_BUG_ON(obj->last_write_req == NULL);
+   GEM_BUG_ON(!(obj->active & 
intel_engine_flag(obj->last_write_req->engine)));
 
i915_gem_request_assign(>last_write_req, NULL);
intel_fb_obj_flush(obj, true, ORIGIN_CS);
@@ -2434,8 +2432,8 @@ i915_gem_object_retire__read(struct drm_i915_gem_object 
*obj, int ring)
 {
struct i915_vma *vma;
 
-   RQ_BUG_ON(obj->last_read_req[ring] == NULL);
-   RQ_BUG_ON(!(obj->active & (1 << ring)));
+   GEM_BUG_ON(obj->last_read_req[ring] == NULL);
+   GEM_BUG_ON(!(obj->active & (1 << ring)));
 
list_del_init(>engine_list[ring]);
i915_gem_request_assign(>last_read_req[ring], NULL);
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
new file mode 100644
index ..8292e797d9b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __I915_GEM_H__
+#define __I915_GEM_H__
+
+#ifdef CONFIG_DRM_I915_DEBUG_GEM
+#define

[Intel-gfx] [PATCH 10/10] drm/i915: Suppress error message when GPU resets are disabled

2016-04-09 Thread Chris Wilson 
If we do not have lowlevel support for reseting the GPU, or if the user
has explicitly disabled reseting the device, the failure is expected.
Since it is an expected failure, we should be using a lower priority
message than *ERROR*, perhaps NOTICE. In the absence of DRM_NOTICE, just
emit the expected failure as a DEBUG message.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 310dc61817fa..18eb3e698763 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -917,7 +917,10 @@ int i915_reset(struct drm_device *dev)
pr_notice("drm/i915: Resetting chip after gpu hang\n");
 
if (ret) {
-   DRM_ERROR("Failed to reset chip: %i\n", ret);
+   if (ret != -ENODEV)
+   DRM_ERROR("Failed to reset chip: %i\n", ret);
+   else
+   DRM_DEBUG_DRIVER("GPU reset disabled\n");
goto error;
}
 
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/10] drm/i915: Disentangle i915_drv.h includes

2016-04-09 Thread Chris Wilson 
Separate out the layers of includes (linux, drm, intel, i915) so that it
is a little easier to order our definitions between our multiple
reentrant headers. A couple of headers needed fixes to make them more
standalone (forgotten includes, forward declarations etc).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  | 29 +
 drivers/gpu/drm/i915/intel_guc.h |  2 ++
 drivers/gpu/drm/i915/intel_lrc.h |  2 ++
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 542401659013..1753077aebbc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -33,27 +33,32 @@
 #include 
 #include 
 
-#include 
-#include "i915_params.h"
-#include "i915_reg.h"
-#include "intel_bios.h"
-#include "intel_ringbuffer.h"
-#include "intel_lrc.h"
-#include "i915_gem_gtt.h"
-#include "i915_gem_render_state.h"
 #include 
 #include 
 #include 
-#include 
-#include  /* for struct drm_dma_handle */
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include "intel_guc.h"
+#include 
+
+#include 
+#include 
+#include  /* for struct drm_dma_handle */
+#include 
+
+#include "i915_params.h"
+#include "i915_reg.h"
+
+#include "intel_bios.h"
 #include "intel_dpll_mgr.h"
+#include "intel_guc.h"
+#include "intel_lrc.h"
+#include "intel_ringbuffer.h"
+
+#include "i915_gem_gtt.h"
+#include "i915_gem_render_state.h"
 
 /* General customization:
  */
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 73002e901ff2..3bb85b127cb0 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -27,6 +27,8 @@
 #include "intel_guc_fwif.h"
 #include "i915_guc_reg.h"
 
+struct drm_i915_gem_request;
+
 struct i915_guc_client {
struct drm_i915_gem_object *client_obj;
struct intel_context *owner;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 0b0853eee91e..5136a2cf50b5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -24,6 +24,8 @@
 #ifndef _INTEL_LRC_H_
 #define _INTEL_LRC_H_
 
+#include "intel_ringbuffer.h"
+
 #define GEN8_LR_CONTEXT_ALIGN 4096
 
 /* Execlists regs */
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 06/10] drm/i915: Tighten reset_counter for reset status

2016-04-09 Thread Chris Wilson 
In the reset_counter, we use two bits to track a GPU hang and reset. The
low bit is a "reset-in-progress" flag that we set to signal when we need
to break waiters in order for the recovery task to grab the mutex. As
soon as the recovery task has the mutex, we can clear that flag (which
we do by incrementing the reset_counter thereby incrementing the gobal
reset epoch). By clearing that flag when the recovery task holds the
struct_mutex, we can forgo a second flag that simply tells GEM to ignore
the "reset-in-progress" flag.

The second flag we store in the reset_counter is whether the
reset failed and we consider the GPU terminally wedged. Whilst this flag
is set, all access to the GPU (at least through GEM rather than direct mmio
access) is verboten.

PS: Fun is in store, as in the future we want to move from a global
reset epoch to a per-engine reset engine with request recovery.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.c | 39 ++---
 drivers/gpu/drm/i915/i915_drv.h |  3 ---
 drivers/gpu/drm/i915/i915_gem.c | 27 +
 drivers/gpu/drm/i915/i915_irq.c | 21 ++--
 5 files changed, 36 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5def0c076ee2..70676fad8669 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4722,7 +4722,7 @@ i915_wedged_get(void *data, u64 *val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   *val = i915_reset_counter(_priv->gpu_error);
+   *val = i915_terminally_wedged(_priv->gpu_error);
 
return 0;
 }
@@ -4741,7 +4741,7 @@ i915_wedged_set(void *data, u64 val)
 * while it is writing to 'i915_wedged'
 */
 
-   if (i915_reset_in_progress_or_wedged(_priv->gpu_error))
+   if (i915_reset_in_progress(_priv->gpu_error))
return -EAGAIN;
 
intel_runtime_pm_get(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 29b4e79c85a6..310dc61817fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -880,23 +880,32 @@ int i915_resume_switcheroo(struct drm_device *dev)
 int i915_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   bool simulated;
+   struct i915_gpu_error *error = _priv->gpu_error;
+   unsigned reset_counter;
int ret;
 
intel_reset_gt_powersave(dev);
 
mutex_lock(>struct_mutex);
 
-   i915_gem_reset(dev);
+   /* Clear any previous failed attempts at recovery. Time to try again. */
+   atomic_andnot(I915_WEDGED, >reset_counter);
 
-   simulated = dev_priv->gpu_error.stop_rings != 0;
+   /* Clear the reset-in-progress flag and increment the reset epoch. */
+   reset_counter = atomic_inc_return(>reset_counter);
+   if (WARN_ON(__i915_reset_in_progress(reset_counter))) {
+   ret = -EIO;
+   goto error;
+   }
+
+   i915_gem_reset(dev);
 
ret = intel_gpu_reset(dev, ALL_ENGINES);
 
/* Also reset the gpu hangman. */
-   if (simulated) {
+   if (error->stop_rings != 0) {
DRM_INFO("Simulated gpu hang, resetting stop_rings\n");
-   dev_priv->gpu_error.stop_rings = 0;
+   error->stop_rings = 0;
if (ret == -ENODEV) {
DRM_INFO("Reset not implemented, but ignoring "
 "error for simulated gpu hangs\n");
@@ -909,8 +918,7 @@ int i915_reset(struct drm_device *dev)
 
if (ret) {
DRM_ERROR("Failed to reset chip: %i\n", ret);
-   mutex_unlock(>struct_mutex);
-   return ret;
+   goto error;
}
 
intel_overlay_reset(dev_priv);
@@ -929,20 +937,14 @@ int i915_reset(struct drm_device *dev)
 * was running at the time of the reset (i.e. we weren't VT
 * switched away).
 */
-
-   /* Used to prevent gem_check_wedged returning -EAGAIN during gpu reset 
*/
-   dev_priv->gpu_error.reload_in_reset = true;
-
ret = i915_gem_init_hw(dev);
-
-   dev_priv->gpu_error.reload_in_reset = false;
-
-   mutex_unlock(>struct_mutex);
if (ret) {
DRM_ERROR("Failed hw init on reset %d\n", ret);
-   return ret;
+   goto error;
}
 
+   mutex_unlock(>struct_mutex);
+
/*
 * rps/rc6 re-init is necessary to restore state lost after the
 * reset and the re-install of gt irqs. Skip for ironlake per
@@ -953,6 +955,11 @@ int i915_reset(struct drm_device *dev)

[Intel-gfx] [PATCH 04/10] drm/i915: Hide the atomic_read(reset_counter) behind a helper

2016-04-09 Thread Chris Wilson 
This is principally a little bit of syntatic sugar to hide the
atomic_read()s throughout the code to retrieve the current reset_counter.
It also provides the other utility functions to check the reset state on the
already read reset_counter, so that (in later patches) we can read it once
and do multiple tests rather than risk the value changing between tests.

v2: Be more strict on converting existing i915_reset_in_progress() over to
the more verbose i915_reset_in_progress_or_wedged().

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h | 32 
 drivers/gpu/drm/i915/i915_gem.c | 16 
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c| 18 +++---
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  7 ---
 7 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9640738aabf2..5def0c076ee2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4722,7 +4722,7 @@ i915_wedged_get(void *data, u64 *val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   *val = atomic_read(_priv->gpu_error.reset_counter);
+   *val = i915_reset_counter(_priv->gpu_error);
 
return 0;
 }
@@ -4741,7 +4741,7 @@ i915_wedged_set(void *data, u64 val)
 * while it is writing to 'i915_wedged'
 */
 
-   if (i915_reset_in_progress(_priv->gpu_error))
+   if (i915_reset_in_progress_or_wedged(_priv->gpu_error))
return -EAGAIN;
 
intel_runtime_pm_get(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fcecc0a7332f..38f6dce05574 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3049,20 +3049,44 @@ void i915_gem_retire_requests_ring(struct 
intel_engine_cs *engine);
 int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
  bool interruptible);
 
+static inline u32 i915_reset_counter(struct i915_gpu_error *error)
+{
+   return atomic_read(>reset_counter);
+}
+
+static inline bool __i915_reset_in_progress(u32 reset)
+{
+   return unlikely(reset & I915_RESET_IN_PROGRESS_FLAG);
+}
+
+static inline bool __i915_reset_in_progress_or_wedged(u32 reset)
+{
+   return unlikely(reset & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+}
+
+static inline bool __i915_terminally_wedged(u32 reset)
+{
+   return unlikely(reset & I915_WEDGED);
+}
+
 static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
 {
-   return unlikely(atomic_read(>reset_counter)
-   & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+   return __i915_reset_in_progress(i915_reset_counter(error));
+}
+
+static inline bool i915_reset_in_progress_or_wedged(struct i915_gpu_error 
*error)
+{
+   return __i915_reset_in_progress_or_wedged(i915_reset_counter(error));
 }
 
 static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
 {
-   return atomic_read(>reset_counter) & I915_WEDGED;
+   return __i915_terminally_wedged(i915_reset_counter(error));
 }
 
 static inline u32 i915_reset_count(struct i915_gpu_error *error)
 {
-   return ((atomic_read(>reset_counter) & ~I915_WEDGED) + 1) / 2;
+   return ((i915_reset_counter(error) & ~I915_WEDGED) + 1) / 2;
 }
 
 static inline bool i915_stop_ring_allow_ban(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 716b7e00dd88..eb79a54c09bc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -83,7 +83,7 @@ i915_gem_wait_for_error(struct i915_gpu_error *error)
 {
int ret;
 
-#define EXIT_COND (!i915_reset_in_progress(error) || \
+#define EXIT_COND (!i915_reset_in_progress_or_wedged(error) || \
   i915_terminally_wedged(error))
if (EXIT_COND)
return 0;
@@ -1112,7 +1112,7 @@ int
 i915_gem_check_wedge(struct i915_gpu_error *error,
 bool interruptible)
 {
-   if (i915_reset_in_progress(error)) {
+   if (i915_reset_in_progress_or_wedged(error)) {
/* Non-interruptible callers can't handle -EAGAIN, hence return
 * -EIO unconditionally for these. */
if (!interruptible)
@@ -1299,7 +1299,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
-   if (reset_counter !=

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: Fix gen8 semaphores id for legacy mode

2016-04-09 Thread Patchwork 
== Series Details ==

Series: series starting with [1/4] drm/i915: Fix gen8 semaphores id for legacy 
mode
URL   : https://patchwork.freedesktop.org/series/5486/
State : warning

== Summary ==

Series 5486v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5486/revisions/1/mbox/

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:158  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1854/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
927d2ad1d9dc07c247b8982be63364dd7a783a86 drm/i915: Enable semaphores for legacy 
submission on gen8
cca81731cca2772d61ce2def44fcb9e9d3ee173e drm/i915: Reload PD tables after 
semaphore wait on gen8
c9e1c1a170cb57d0c9192388717a1fba4c632921 drm/i915: Fix serialisation of 
pipecontrol write vs semaphore signal
5123a722cfc43c931126b372a4c3ee55e9bcd662 drm/i915: Fix gen8 semaphores id for 
legacy mode

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: Prevent machine death on Ivybridge context switching

2016-04-09 Thread Chris Wilson 
On Sat, Apr 09, 2016 at 09:56:11AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/4] drm/i915: Prevent machine death on 
> Ivybridge context switching
> URL   : https://patchwork.freedesktop.org/series/5484/
> State : warning
> 
> == Summary ==
> 
> Series 5484v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/5484/revisions/1/mbox/
> 
> Test gem_exec_basic:
> Subgroup basic-bsd:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test gem_ringfill:
> Subgroup basic-default-hang:
> pass   -> DMESG-WARN (byt-nuc)
> pass   -> DMESG-WARN (snb-x220t)
> pass   -> DMESG-WARN (snb-dellxps)
> pass   -> DMESG-WARN (hsw-brixbox)
> pass   -> DMESG-WARN (ivb-t430s)

which apparently requires the EIO handling fixes to silence correctly.
Hmm,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915: Reload PD tables after semaphore wait on gen8

2016-04-09 Thread Chris Wilson 
When the engine idles waiting upon a semaphore, it loses its
pagetables and we must reload them before executing the batch.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 62d09cf2ea8f..a4bab6466388 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1446,6 +1446,7 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
 {
struct intel_engine_cs *waiter = waiter_req->engine;
struct drm_i915_private *dev_priv = waiter->dev->dev_private;
+   struct i915_hw_ppgtt *ppgtt;
int ret;
 
ret = intel_ring_begin(waiter_req, 4);
@@ -1461,6 +1462,15 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
intel_ring_emit(waiter,
upper_32_bits(GEN8_WAIT_OFFSET(waiter, signaller->id)));
intel_ring_advance(waiter);
+
+   /* When the engine idles waiting upon a semaphore, it loses its
+* pagetables and we must reload them before executing the batch.
+* We do this on the i915_switch_context() following the wait and
+* before the dispatch.
+*/
+   ppgtt = waiter_req->ctx->ppgtt;
+   if (ppgtt)
+   ppgtt->pd_dirty_rings |= intel_engine_flag(waiter_req->engine);
return 0;
 }
 
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/4] drm/i915: Enable semaphores for legacy submission on gen8

2016-04-09 Thread Chris Wilson 
We have sufficient evidence from igt to support that semaphores are in
a working state. Enabling semaphores now for legacy provides a better
comparison of execlists against legacy ring submission.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 29b4e79c85a6..98f24474bc04 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -542,10 +542,6 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
if (i915.enable_execlists)
return false;
 
-   /* Until we get further testing... */
-   if (IS_GEN8(dev))
-   return false;
-
 #ifdef CONFIG_INTEL_IOMMU
/* Enable semaphores on SNB when IO remapping is off */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm/i915: Fix gen8 semaphores id for legacy mode

2016-04-09 Thread Chris Wilson 
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.

Fixes: de1add360522c876c25ef2ab1c94bdb509ab
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin id));
+  MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
 
@@ -1347,7 +1347,7 @@ static int gen8_xcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, upper_32_bits(gtt_offset));
intel_ring_emit(signaller, seqno);
intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL |
-  MI_SEMAPHORE_TARGET(waiter->id));
+  MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
 
@@ -2793,6 +2793,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
engine->name = "render ring";
engine->id = RCS;
engine->exec_id = I915_EXEC_RENDER;
+   engine->hw_id = 0;
engine->mmio_base = RENDER_RING_BASE;
 
if (INTEL_INFO(dev)->gen >= 8) {
@@ -2942,6 +2943,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
engine->name = "bsd ring";
engine->id = VCS;
engine->exec_id = I915_EXEC_BSD;
+   engine->hw_id = 1;
 
engine->write_tail = ring_write_tail;
if (INTEL_INFO(dev)->gen >= 6) {
@@ -3019,6 +3021,7 @@ int intel_init_bsd2_ring_buffer(struct drm_device *dev)
engine->name = "bsd2 ring";
engine->id = VCS2;
engine->exec_id = I915_EXEC_BSD;
+   engine->hw_id = 4;
 
engine->write_tail = ring_write_tail;
engine->mmio_base = GEN8_BSD2_RING_BASE;
@@ -3050,6 +3053,7 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
engine->name = "blitter ring";
engine->id = BCS;
engine->exec_id = I915_EXEC_BLT;
+   engine->hw_id = 2;
 
engine->mmio_base = BLT_RING_BASE;
engine->write_tail = ring_write_tail;
@@ -3108,6 +3112,7 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
engine->name = "video enhancement ring";
engine->id = VECS;
engine->exec_id = I915_EXEC_VEBOX;
+   engine->hw_id = 3;
 
engine->mmio_base = VEBOX_RING_BASE;
engine->write_tail = ring_write_tail;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 98eadfa79116..6efa47389276 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -155,7 +155,8 @@ struct  intel_engine_cs {
 #define I915_NUM_ENGINES 5
 #define _VCS(n) (VCS + (n))
unsigned int exec_id;
-   unsigned int guc_id;
+   unsigned int hw_id;
+   unsigned int guc_id; /* XXX same as hw_id? */
u32 mmio_base;
struct  drm_device *dev;
struct intel_ringbuffer *buffer;
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Finish gen8 legacy semaphores

2016-04-09 Thread Chris Wilson 
Semaphores for gen8 were almost finished and only required a couple of
tweaks to pass the most stressful igt I could write, as well as the
existing inter-engine stress tests.

But what's the point you might ask when legacy ringbuffer submission is
already turned off by default? gen8 still serves as our test platform on
which we can directly compare the alternative submission modes and for
the purposes of testing, we want it to be as feature complete as
possible.
-Chris

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

2016-04-09 Thread Chris Wilson 
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the
pipecontrol writing the signal value is complete, we have to pause the
CS inside the PIPE_CONTROL with the CS_STALL bit.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 556924ee47f9..62d09cf2ea8f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1301,7 +1301,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6));
intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB |
   PIPE_CONTROL_QW_WRITE |
-  PIPE_CONTROL_FLUSH_ENABLE);
+  PIPE_CONTROL_CS_STALL);
intel_ring_emit(signaller, lower_32_bits(gtt_offset));
intel_ring_emit(signaller, upper_32_bits(gtt_offset));
intel_ring_emit(signaller, seqno);
@@ -1454,7 +1454,6 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
 
intel_ring_emit(waiter, MI_SEMAPHORE_WAIT |
MI_SEMAPHORE_GLOBAL_GTT |
-   MI_SEMAPHORE_POLL |
MI_SEMAPHORE_SAD_GTE_SDD);
intel_ring_emit(waiter, seqno);
intel_ring_emit(waiter,
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI-ping 3/5] drm/i915: Harden detection of missed interrupts

2016-04-09 Thread Chris Wilson 
Only declare a missed interrupt if we find that the GPU is idle with
waiters and a hangcheck interval has passed in which no new user
interrupts have been raised.

v2: Clear the stuck interrupt marker between successful batches

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 11 ++
 drivers/gpu/drm/i915/i915_irq.c | 38 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
 3 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 919c05ba9932..9640738aabf2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -728,10 +728,10 @@ static int i915_gem_request_info(struct seq_file *m, void 
*data)
 static void i915_ring_seqno_info(struct seq_file *m,
 struct intel_engine_cs *engine)
 {
-   if (engine->get_seqno) {
-   seq_printf(m, "Current sequence (%s): %x\n",
-  engine->name, engine->get_seqno(engine));
-   }
+   seq_printf(m, "Current sequence (%s): %x\n",
+  engine->name, engine->get_seqno(engine));
+   seq_printf(m, "Current user interrupts (%s): %x\n",
+  engine->name, READ_ONCE(engine->user_interrupts));
 }
 
 static int i915_gem_seqno_info(struct seq_file *m, void *data)
@@ -1367,6 +1367,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
   engine->hangcheck.seqno,
   seqno[id],
   engine->last_submitted_seqno);
+   seq_printf(m, "\tuser interrupts = %x [current %x]\n",
+  engine->hangcheck.user_interrupts,
+  READ_ONCE(engine->user_interrupts));
seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
   (long long)engine->hangcheck.acthd,
   (long long)acthd[id]);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3b946e1c7614..679f08c944ef 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1000,6 +1000,7 @@ static void notify_ring(struct intel_engine_cs *engine)
return;
 
trace_i915_gem_request_notify(engine);
+   engine->user_interrupts++;
 
wake_up_all(>irq_queue);
 }
@@ -3054,6 +3055,24 @@ ring_stuck(struct intel_engine_cs *engine, u64 acthd)
return HANGCHECK_HUNG;
 }
 
+static unsigned kick_waiters(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *i915 = to_i915(engine->dev);
+   unsigned user_interrupts = READ_ONCE(engine->user_interrupts);
+
+   if (engine->hangcheck.user_interrupts == user_interrupts &&
+   !test_and_set_bit(engine->id, >gpu_error.missed_irq_rings)) {
+   if (!(i915->gpu_error.test_irq_rings & 
intel_engine_flag(engine)))
+   DRM_ERROR("Hangcheck timer elapsed... %s idle\n",
+ engine->name);
+   else
+   DRM_INFO("Fake missed irq on %s\n",
+engine->name);
+   wake_up_all(>irq_queue);
+   }
+
+   return user_interrupts;
+}
 /*
  * This is called when the chip hasn't reported back with completed
  * batchbuffers in a long time. We keep track per ring seqno progress and
@@ -3096,6 +3115,7 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
for_each_engine_id(engine, dev_priv, id) {
u64 acthd;
u32 seqno;
+   unsigned user_interrupts;
bool busy = true;
 
semaphore_clear_deadlocks(dev_priv);
@@ -3113,22 +3133,15 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
acthd = intel_ring_get_active_head(engine);
seqno = engine->get_seqno(engine);
 
+   /* Reset stuck interrupts between batch advances */
+   user_interrupts = 0;
+
if (engine->hangcheck.seqno == seqno) {
if (ring_idle(engine, seqno)) {
engine->hangcheck.action = HANGCHECK_IDLE;
-
if (waitqueue_active(>irq_queue)) {
-   /* Issue a wake-up to catch stuck h/w. 
*/
-   if (!test_and_set_bit(engine->id, 
_priv->gpu_error.missed_irq_rings)) {
-   if 
(!(dev_priv->gpu_error.test_irq_rings & intel_engine_flag(engine)))
-   DRM_ERROR("Hangcheck 
timer elapsed... %s idle\n",
- engine->name);
-

[Intel-gfx] [CI-ping 5/5] drm/i915: Replace manual barrier() with READ_ONCE() in HWS accessor

2016-04-09 Thread Chris Wilson 
When reading from the HWS page, we use barrier() to prevent the compiler
optimising away the read from the volatile (may be updated by the GPU)
memory address. This is more suited to READ_ONCE(); make it so.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 9d7b7bf9ed14..78dc46864a10 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -391,12 +391,10 @@ intel_flush_status_page(struct intel_engine_cs *engine, 
int reg)
 }
 
 static inline u32
-intel_read_status_page(struct intel_engine_cs *engine,
-  int reg)
+intel_read_status_page(struct intel_engine_cs *engine, int reg)
 {
/* Ensure that the compiler doesn't optimize away the load. */
-   barrier();
-   return engine->status_page.page_addr[reg];
+   return READ_ONCE(engine->status_page.page_addr[reg]);
 }
 
 static inline void
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI-ping 2/5] drm/i915: Separate out the seqno-barrier from engine->get_seqno

2016-04-09 Thread Chris Wilson 
In order to simplify future patches, extract the
lazy_coherency optimisation our of the engine->get_seqno() vfunc into
its own callback.

v2: Rename the barrier to engine->irq_seqno_barrier to try and better
reflect that the barrier is only required after the user interrupt before
reading the seqno (to ensure that the seqno update lands in time as we
do not have strict seqno-irq ordering on all platforms).

Reviewed-by: Dave Gordon  [#v2]

v3: Comments for hangcheck paranoia. Mika wanted to keep the extra
barrier inside the hangcheck, just in case. I can argue that it doesn't
provide a barrier against anything, but the side-effects of applying the
barrier may prevent a false declaration of a hung GPU.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Dave Gordon 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  6 +++---
 drivers/gpu/drm/i915/i915_drv.h | 12 
 drivers/gpu/drm/i915/i915_gpu_error.c   |  2 +-
 drivers/gpu/drm/i915/i915_irq.c | 14 --
 drivers/gpu/drm/i915/i915_trace.h   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 19 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 34 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 ++--
 8 files changed, 51 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ebbf4e400684..919c05ba9932 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -598,7 +598,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
   engine->name,
   
i915_gem_request_get_seqno(work->flip_queued_req),
   dev_priv->next_seqno,
-  engine->get_seqno(engine, true),
+  engine->get_seqno(engine),
   
i915_gem_request_completed(work->flip_queued_req, true));
} else
seq_printf(m, "Flip not associated with any 
ring\n");
@@ -730,7 +730,7 @@ static void i915_ring_seqno_info(struct seq_file *m,
 {
if (engine->get_seqno) {
seq_printf(m, "Current sequence (%s): %x\n",
-  engine->name, engine->get_seqno(engine, false));
+  engine->name, engine->get_seqno(engine));
}
 }
 
@@ -1346,8 +1346,8 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
intel_runtime_pm_get(dev_priv);
 
for_each_engine_id(engine, dev_priv, id) {
-   seqno[id] = engine->get_seqno(engine, false);
acthd[id] = intel_ring_get_active_head(engine);
+   seqno[id] = engine->get_seqno(engine);
}
 
i915_get_extra_instdone(dev, instdone);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a93e5dd4fa9a..542401659013 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3017,15 +3017,19 @@ i915_seqno_passed(uint32_t seq1, uint32_t seq2)
 static inline bool i915_gem_request_started(struct drm_i915_gem_request *req,
   bool lazy_coherency)
 {
-   u32 seqno = req->engine->get_seqno(req->engine, lazy_coherency);
-   return i915_seqno_passed(seqno, req->previous_seqno);
+   if (!lazy_coherency && req->engine->irq_seqno_barrier)
+   req->engine->irq_seqno_barrier(req->engine);
+   return i915_seqno_passed(req->engine->get_seqno(req->engine),
+req->previous_seqno);
 }
 
 static inline bool i915_gem_request_completed(struct drm_i915_gem_request *req,
  bool lazy_coherency)
 {
-   u32 seqno = req->engine->get_seqno(req->engine, lazy_coherency);
-   return i915_seqno_passed(seqno, req->seqno);
+   if (!lazy_coherency && req->engine->irq_seqno_barrier)
+   req->engine->irq_seqno_barrier(req->engine);
+   return i915_seqno_passed(req->engine->get_seqno(req->engine),
+req->seqno);
 }
 
 int __must_check i915_gem_get_seqno(struct drm_device *dev, u32 *seqno);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ce77713a555d..89725c9efc25 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -931,8 +931,8 @@ static void i915_record_ring_state(struct drm_device *dev,
 
ering->waiting = waitqueue_active(>irq_queue);
ering->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
-   ering->seqno = engine->get_seqno(engine, false);
ering->acthd =

[Intel-gfx] [CI-ping 4/5] drm/i915: Use simplest form for flushing the single cacheline in the HWS

2016-04-09 Thread Chris Wilson 
Rather than call a function to compute the matching cachelines and
clflush them, just call the clflush *instruction* directly. We also know
that we can use the unpatched plain clflush rather than the clflushopt
alternative.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Imre Deak 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_ringbuffer.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 29c54cc1ee5c..9d7b7bf9ed14 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -385,8 +385,9 @@ intel_ring_sync_index(struct intel_engine_cs *engine,
 static inline void
 intel_flush_status_page(struct intel_engine_cs *engine, int reg)
 {
-   drm_clflush_virt_range(>status_page.page_addr[reg],
-  sizeof(uint32_t));
+   mb();
+   clflush(>status_page.page_addr[reg]);
+   mb();
 }
 
 static inline u32
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI-ping 1/5] drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+

2016-04-09 Thread Chris Wilson 
In order to ensure seqno/irq coherency, we currently read a ring register.
The mmio transaction following the interrupt delays the inspection of
the seqno long enough for the MI_STORE_DWORD_IMM to update the CPU
cache. However, it is only the memory timing that is important for the
purposes of the delay, we do not need nor desire the extra forcewake.

v3: Update commentary

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala  [v2]
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6b4952031e30..edd5ae41ba60 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1573,10 +1573,19 @@ gen6_ring_get_seqno(struct intel_engine_cs *engine, 
bool lazy_coherency)
 {
/* Workaround to force correct ordering between irq and seqno writes on
 * ivb (and maybe also on snb) by reading from a CS register (like
-* ACTHD) before reading the status page. */
+* ACTHD) before reading the status page.
+*
+* Note that this effectively stalls the read by the time it takes to
+* do a memory transaction, which more or less ensures that the write
+* from the GPU has sufficient time to invalidate the CPU cacheline.
+* Alternatively we could delay the interrupt from the CS ring to give
+* the write time to land, but that would incur a delay after every
+* batch i.e. much more frequent than a delay when waiting for the
+* interrupt (with the same net latency).
+*/
if (!lazy_coherency) {
struct drm_i915_private *dev_priv = engine->dev->dev_private;
-   POSTING_READ(RING_ACTHD(engine->mmio_base));
+   POSTING_READ_FW(RING_ACTHD(engine->mmio_base));
}
 
return intel_read_status_page(engine, I915_GEM_HWS_INDEX);
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: Prevent machine death on Ivybridge context switching

2016-04-09 Thread Patchwork 
== Series Details ==

Series: series starting with [1/4] drm/i915: Prevent machine death on Ivybridge 
context switching
URL   : https://patchwork.freedesktop.org/series/5484/
State : warning

== Summary ==

Series 5484v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5484/revisions/1/mbox/

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ivb-t430s)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:160  dwarn:1   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:173  dwarn:1   dfail:0   fail:0   skip:22 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:170  dwarn:1   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:161  dwarn:1   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:161  dwarn:1   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1852/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
37779149c4e4b641d0ff811502d90e594882efda drm/i915: Late request cancellations 
are harmful
87ac23b892993e2500a35af4b3fc3eff1df38315 drm/i915: Move the mb() following 
release-mmap into release-mmap
ff41060287aabfb3bf463629144ccae744f9ebda drm/i915: Force ringbuffers to not be 
at offset 0
a64d18416237b2230a329477e8f201c6c4a42114 drm/i915: Prevent machine death on 
Ivybridge context switching

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Force ringbuffers to not be at offset 0

2016-04-09 Thread Chris Wilson 
On Sat, Apr 09, 2016 at 10:27:37AM +0100, Chris Wilson wrote:
> For reasons unknown Sandybridge GT1 (at least) will eventually hang when
> it encounters a ring wraparound at offset 0. The test case that
> reproduces the bug reliably forces a large number of interrupted context
> switches, thereby causing very frequent ring wraparounds, but there are
> similar bug reports in the wild with the same symptoms, seqno writes
> stop just before the wrap and the ringbuffer at address 0. It is also
> timing crucial, but adding various delays hasn't helped pinpoint where
> the window lies.

This also seems to fix resume on my SNB-GT2, but I guess that is a
different issue related to address 0. And long ago, I reported PNV also
hung when resumed when it hang ringbuffers at address 0 - so I wonder if
that's the same as well...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/4] drm/i915: Late request cancellations are harmful

2016-04-09 Thread Chris Wilson 
Conceptually, each request is a record of a hardware transaction - we
build up a list of pending commands and then either commit them to
hardware, or cancel them. However, whilst building up the list of
pending commands, we may modify state outside of the request and make
references to the pending request. If we do so and then cancel that
request, external objects then point to the deleted request leading to
both graphical and memory corruption.

The easiest example is to consider object/VMA tracking. When we mark an
object as active in a request, we store a pointer to this, the most
recent request, in the object. Then we want to free that object, we wait
for the most recent request to be idle before proceeding (otherwise the
hardware will write to pages now owned by the system, or we will attempt
to read from those pages before the hardware is finished writing). If
the request was cancelled instead, that wait completes immediately. As a
result, all requests must be committed and not cancelled if the external
state is unknown.

All that remains of i915_gem_request_cancel() users are just a couple of
extremely unlikely allocation failures, so remove the API entirely.

A consequence of committing all incomplete requests is that we generate
excess breadcrumbs and fill the ring much more often with dummy work. We
have completely undone the outstanding_last_seqno optimisation.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93907
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h|  2 --
 drivers/gpu/drm/i915/i915_gem.c| 50 --
 drivers/gpu/drm/i915/i915_gem_context.c| 21 ++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +++--
 drivers/gpu/drm/i915/intel_display.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   |  4 +--
 drivers/gpu/drm/i915/intel_overlay.c   |  8 ++---
 7 files changed, 39 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a93e5dd4fa9a..f374db8de673 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2320,7 +2320,6 @@ struct drm_i915_gem_request {
 struct drm_i915_gem_request * __must_check
 i915_gem_request_alloc(struct intel_engine_cs *engine,
   struct intel_context *ctx);
-void i915_gem_request_cancel(struct drm_i915_gem_request *req);
 void i915_gem_request_free(struct kref *req_ref);
 int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
   struct drm_file *file);
@@ -2872,7 +2871,6 @@ int i915_gem_sw_finish_ioctl(struct drm_device *dev, void 
*data,
 struct drm_file *file_priv);
 void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
struct drm_i915_gem_request *req);
-void i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params 
*params);
 int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
   struct drm_i915_gem_execbuffer2 *args,
   struct list_head *vmas);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1c3ff56594d6..42227495803f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2753,7 +2753,8 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
 * fully prepared. Thus it can be cleaned up using the proper
 * free code.
 */
-   i915_gem_request_cancel(req);
+   intel_ring_reserved_space_cancel(req->ringbuf);
+   i915_gem_request_unreference(req);
return ret;
}
 
@@ -2790,13 +2791,6 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
return err ? ERR_PTR(err) : req;
 }
 
-void i915_gem_request_cancel(struct drm_i915_gem_request *req)
-{
-   intel_ring_reserved_space_cancel(req->ringbuf);
-
-   i915_gem_request_unreference(req);
-}
-
 struct drm_i915_gem_request *
 i915_gem_find_active_request(struct intel_engine_cs *engine)
 {
@@ -3410,12 +3404,9 @@ int i915_gpu_idle(struct drm_device *dev)
return PTR_ERR(req);
 
ret = i915_switch_context(req);
-   if (ret) {
-   i915_gem_request_cancel(req);
-   return ret;
-   }
-
i915_add_request_no_flush(req);
+   if (ret)
+   return ret;
}
 
ret = intel_engine_idle(engine);
@@ -4917,34 +4908,33 @@ i915_gem_init_hw(struct drm_device *dev)
req = i915_gem_request_alloc(engine, NULL);

[Intel-gfx] GPU and machine hang fixes, take 2

2016-04-09 Thread Chris Wilson 
Please review or even just ack!

Tvrtko, please have another look at 4/4 as it impacts upon requests and
both the state we track in a request and activity tracked by requests.
-Chris

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm/i915: Prevent machine death on Ivybridge context switching

2016-04-09 Thread Chris Wilson 
Two concurrent writes into the same register cacheline has the chance of
killing the machine on Ivybridge and other gen7. This includes LRI
emitted from the command parser.  The MI_SET_CONTEXT itself serves as
serialising barrier and prevents the pair of register writes in the first
packet from triggering the fault.  However, if a second switch-context
immediately occurs then we may have two adjacent blocks of LRI to the
same registers which may then trigger the hang. To counteract this we
need to insert a delay after the second register write using SRM.

This is easiest to reproduce with something like
igt/gem_ctx_switch/interruptible that triggers back-to-back context
switches (with no operations in between them in the command stream,
which requires the execbuf operation to be interrupted after the
MI_SET_CONTEXT) but can be observed sporadically elsewhere when running
interruptible igt. No reports from the wild though, so it must be of low
enough frequency that no one has correlated the random machine freezes
with i915.ko

The issue was introduced with
commit 2c550183476dfa25641309ae9a28d30feed14379 [v3.19]
Author: Chris Wilson 
Date:   Tue Dec 16 10:02:27 2014 +

drm/i915: Disable PSMI sleep messages on all rings around context switches

Testcase: igt/gem_ctx_switch/render-interruptible #ivb
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_gem_context.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index fe580cb9501a..e5ad7b21e356 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -539,7 +539,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 
len = 4;
if (INTEL_INFO(engine->dev)->gen >= 7)
-   len += 2 + (num_rings ? 4*num_rings + 2 : 0);
+   len += 2 + (num_rings ? 4*num_rings + 6 : 0);
 
ret = intel_ring_begin(req, len);
if (ret)
@@ -579,6 +579,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
if (INTEL_INFO(engine->dev)->gen >= 7) {
if (num_rings) {
struct intel_engine_cs *signaller;
+   i915_reg_t last_reg = {}; /* keep gcc quiet */
 
intel_ring_emit(engine,
MI_LOAD_REGISTER_IMM(num_rings));
@@ -586,11 +587,19 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
if (signaller == engine)
continue;
 
-   intel_ring_emit_reg(engine,
-   
RING_PSMI_CTL(signaller->mmio_base));
+   last_reg = RING_PSMI_CTL(signaller->mmio_base);
+   intel_ring_emit_reg(engine, last_reg);
intel_ring_emit(engine,

_MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
}
+
+   /* Insert a delay before the next switch! */
+   intel_ring_emit(engine,
+   MI_STORE_REGISTER_MEM |
+   MI_SRM_LRM_GLOBAL_GTT);
+   intel_ring_emit_reg(engine, last_reg);
+   intel_ring_emit(engine, engine->scratch.gtt_offset);
+   intel_ring_emit(engine, MI_NOOP);
}
intel_ring_emit(engine, MI_ARB_ON_OFF | MI_ARB_ENABLE);
}
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915: Move the mb() following release-mmap into release-mmap

2016-04-09 Thread Chris Wilson 
As paranoia, we want to ensure that the CPU's PTEs have been revoked for
the object before we return from i915_gem_release_mmap(). This allows us
to rely on there being no outstanding memory accesses and guarantees
serialisation of the code against concurrent access just by calling
i915_gem_release_mmap().

v2: Reduce the mb() into a wmb() following the revoke.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: "Goel, Akash" 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a65a7663b88..1c3ff56594d6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1964,11 +1964,21 @@ out:
 void
 i915_gem_release_mmap(struct drm_i915_gem_object *obj)
 {
+   /* Serialisation between user GTT access and our code depends upon
+* revoking the CPU's PTE whilst the mutex is held. The next user
+* pagefault then has to wait until we release the mutex.
+*/
+   lockdep_assert_held(>base.dev->struct_mutex);
+
if (!obj->fault_mappable)
return;
 
drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
+
+   /* Ensure that the CPU's PTE are revoked before we return */
+   wmb();
+
obj->fault_mappable = false;
 }
 
@@ -3296,9 +3306,6 @@ static void i915_gem_object_finish_gtt(struct 
drm_i915_gem_object *obj)
if ((obj->base.read_domains & I915_GEM_DOMAIN_GTT) == 0)
return;
 
-   /* Wait for any direct GTT access to complete */
-   mb();
-
old_read_domains = obj->base.read_domains;
old_write_domain = obj->base.write_domain;
 
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] drm/i915: Force ringbuffers to not be at offset 0

2016-04-09 Thread Chris Wilson 
For reasons unknown Sandybridge GT1 (at least) will eventually hang when
it encounters a ring wraparound at offset 0. The test case that
reproduces the bug reliably forces a large number of interrupted context
switches, thereby causing very frequent ring wraparounds, but there are
similar bug reports in the wild with the same symptoms, seqno writes
stop just before the wrap and the ringbuffer at address 0. It is also
timing crucial, but adding various delays hasn't helped pinpoint where
the window lies.

Whether the fault is restricted to the ringbuffer itself or the GTT
addressing is unclear, but moving the ringbuffer fixes all the hangs I
have been able to reproduce.

References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262
Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1
Signed-off-by: Chris Wilson 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6b4952031e30..2f13ab2a1098 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2113,10 +2113,12 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_object *obj = ringbuf->obj;
+   /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
+   unsigned flags = PIN_OFFSET_BIAS | 4096;
int ret;
 
if (HAS_LLC(dev_priv) && !obj->stolen) {
-   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, 0);
+   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, flags);
if (ret)
return ret;
 
@@ -2132,7 +2134,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
return -ENOMEM;
}
} else {
-   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
+   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE,
+   flags | PIN_MAPPABLE);
if (ret)
return ret;
 
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Reviving the LPSS PWM patches

2016-04-09 Thread Lluís Batlle i Rossell 
On Thu, Apr 07, 2016 at 11:54:39AM +0200, Lluís Batlle i Rossell wrote:
> On Thu, Apr 07, 2016 at 03:19:04PM +0530, Kumar, Shobhit wrote:
> > On Wednesday 06 April 2016 04:26 PM, Lluís Batlle i Rossell wrote:
> > >I don't see any trace of pwm/lpss in dmesg, so it's normal that i915 fails
> > >to find it. I wonder if there may be a problem in the ACPI table. I have
> > >the DSDT and it clearly reports the:
> > >
> > >Name (_CID, "80860F09")  // _CID: Compatible ID
> > >Name (_DDN, "Intel(R) PWM Controller #2 - 80860F09")  // _DDN: DOS Device 
> > >Name
> > >
> > >Which should be the lpss pwm. But somehow it is not loaded, so I guess it
> > >fails the probing.
> > 
> > Can we put some prints in the probe routines and see whats happening in the
> > pwm-lpss-platform.c driver. There is also a PCI PWM LPSS driver -
> > pwm-lpss-pci.c Can you also enable that and see if the probe for that is
> > being called and successful ?
> 
> I have CONFIG_PWM_LPSS_PCI=m, but udev doesn't load it. I can try to set
> it to =y.
> 
> I will try to add some prints.

I have in /sys/kernel/debug/pwm:
platform/80860F09:01, 1 PWM device
pwm-0   ((null)  ):

platform/80860F09:00, 1 PWM device
pwm-0   ((null)  ):

So something is there.

-- 
(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
PGP key D4831A8A - https://emailselfdefense.fsf.org/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 0/4] Eliminating the execlist retired request queue

2016-04-09 Thread Chris Wilson 
On Fri, Apr 08, 2016 at 02:54:54PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Retired request queue coupled with retired work handler is a scalability
> concern on some workloads of which one dramatic example is gem_close_race.
> 
> This series depend on i915_gem_object_pin_map series by Chris Wilson.

My biggest concern with this is that this touches code that has a known
GPF and so imo cannot be tested until that *regression* has been fixed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: atomic: fix legacy gamma set helper

2016-04-09 Thread Patchwork 
== Series Details ==

Series: drm: atomic: fix legacy gamma set helper
URL   : https://patchwork.freedesktop.org/series/5471/
State : warning

== Summary ==

Series 5471v1 drm: atomic: fix legacy gamma set helper
http://patchwork.freedesktop.org/api/1.0/series/5471/revisions/1/mbox/

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (snb-x220t)
Subgroup force-load-detect:
pass   -> SKIP   (snb-x220t)
Subgroup prune-stale-modes:
pass   -> SKIP   (ivb-t430s)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (byt-nuc)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:160  dwarn:1   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
ilk-hp8440p  total:196  pass:131  dwarn:1   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:170  dwarn:0   dfail:0   fail:0   skip:26 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:160  dwarn:0   dfail:0   fail:1   skip:35 

Results at /archive/results/CI_IGT_test/Patchwork_1851/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
ff2301ce4c39a6e755adac9f45225f4e1648336f drm: atomic: fix legacy gamma set 
helper

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: add missing condition for committing planes on crtc

2016-04-09 Thread Patchwork 
== Series Details ==

Series: drm/i915: add missing condition for committing planes on crtc
URL   : https://patchwork.freedesktop.org/series/5467/
State : failure

== Summary ==

Series 5467v1 drm/i915: add missing condition for committing planes on crtc
http://patchwork.freedesktop.org/api/1.0/series/5467/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (bdw-ultra)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (bsw-nuc-2)
pass   -> FAIL   (ivb-t430s)
pass   -> DMESG-FAIL (bdw-ultra)
pass   -> FAIL   (skl-i7k-2)
pass   -> FAIL   (byt-nuc)
pass   -> FAIL   (snb-x220t)
pass   -> FAIL   (snb-dellxps)
pass   -> FAIL   (hsw-brixbox)
pass   -> DMESG-FAIL (bdw-nuci7)
skip   -> FAIL   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup hang-read-crc-pipe-c:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-c:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-c:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (bdw-ultra)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass