Re: [Intel-gfx] [PATCH] drm/syncobj: Use dma_fence_wait for the simple wait case

2018-05-07 Thread Daniel Vetter
On Sat, May 05, 2018 at 11:55:49AM +0100, Chris Wilson wrote:
> When waiting for a single fence beneath a syncobj, forgo our open coding
> for waiting over multiple fences and call the driver specific
> dma_fence_wait_timeout(). This gives the opportunity for the driver to
> handle it more efficiently then the lcd of signal callbacks, and avoids
> the temporary allocations and array iterations.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Daniel Vetter 

Aside: Do the igts test both the single and multi-case?
-Daniel
> ---
>  drivers/gpu/drm/drm_syncobj.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index d4f4ce484529..c0f787f7a298 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -695,6 +695,14 @@ static signed long drm_syncobj_array_wait_timeout(struct 
> drm_syncobj **syncobjs,
>   signed long ret;
>   uint32_t signaled_count, i;
>  
> + /* KISS for the common case of waiting for a single submitted fence. */
> + if (count == 1 && (fence = drm_syncobj_fence_get(syncobjs[0]))) {
> + ret = dma_fence_wait_timeout(fence, true, timeout);
> + dma_fence_put(fence);
> + *idx = 0;
> + return ret;
> + }
> +
>   entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
>   if (!entries)
>   return -ENOMEM;
> -- 
> 2.17.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for Enable NV12 support (rev6)

2018-05-07 Thread Patchwork
== Series Details ==

Series: Enable NV12 support (rev6)
URL   : https://patchwork.freedesktop.org/series/41674/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4152_full -> Patchwork_8932_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8932_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8932_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41674/revisions/6/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8932_full:

  === IGT changes ===

 Warnings 

igt@kms_force_connector_basic@force-load-detect:
  shard-hsw:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_8932_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-apl:  PASS -> FAIL (fdo#106087)

igt@kms_flip@plain-flip-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#100368) +1


 Possible fixes 

igt@drv_selftest@live_contexts:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087


== Participating hosts (6 -> 6) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4152 -> Patchwork_8932

  CI_DRM_4152: 06e15c0f055b8b8e326bb65fa83f69b1b7391e51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8932: 8ed55fec3a1cd6d018ae8f392744cb49c0de0be6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8932/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace

2018-05-07 Thread Rogozhkin, Dmitry V
>> I'm pretty sure Dmitry wants dynamic configurations.

Yes, I afraid we really need dynamic slice configurations for media.

From: Landwerlin, Lionel G
Sent: Friday, May 4, 2018 9:25 AM
To: Tvrtko Ursulin ; 
intel-gfx@lists.freedesktop.org; Rogozhkin, Dmitry V 

Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration 
to userspace

On 03/05/18 18:18, Tvrtko Ursulin wrote:
  +int intel_lr_context_set_sseu(struct i915_gem_context *ctx,
+  struct intel_engine_cs *engine,
+  struct i915_gem_context_sseu *sseu)
+{
+struct drm_i915_private *dev_priv = ctx->i915;
+struct intel_context *ce;
+enum intel_engine_id id;
+int ret;
+
+lockdep_assert_held(_priv->drm.struct_mutex);
+
+if (memcmp(sseu, >engine[engine->id].sseu, sizeof(*sseu)) == 0)
+return 0;
+
+/*
+ * We can only program this on render ring.
+ */
+ce = >engine[RCS];
+
+if (ce->pin_count) { /* Assume that the context is active! */
+ret = i915_gem_switch_to_kernel_context(dev_priv);
+if (ret)
+return ret;
+
+ret = i915_gem_wait_for_idle(dev_priv,
+ I915_WAIT_INTERRUPTIBLE |
+ I915_WAIT_LOCKED);

Could we consider the alternative of only allowing this to be configured on 
context create? That way we would not need to idle the GPU every time userspace 
decides to fiddle with it. It is unprivileged so quite an easy way for random 
app to ruin GPU performance for everyone.

Regards,

Tvrtko


I'm pretty sure Dmitry wants dynamic configurations.

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Enable NV12 support (rev6)

2018-05-07 Thread Patchwork
== Series Details ==

Series: Enable NV12 support (rev6)
URL   : https://patchwork.freedesktop.org/series/41674/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4152 -> Patchwork_8932 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41674/revisions/6/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8932 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-hsw-4200u:   PASS -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   PASS -> DMESG-FAIL (fdo#102614, fdo#106103)


 Possible fixes 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-skl-6770hq:  FAIL (fdo#100368, fdo#103928) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103


== Participating hosts (41 -> 37) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4152 -> Patchwork_8932

  CI_DRM_4152: 06e15c0f055b8b8e326bb65fa83f69b1b7391e51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8932: 8ed55fec3a1cd6d018ae8f392744cb49c0de0be6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

8ed55fec3a1c drm/i915: Add NV12 as supported format for sprite plane
4f3dbd32ac39 drm/i915: Add NV12 as supported format for primary plane
47db37f2bc68 drm/i915: Add NV12 support to intel_framebuffer_init
53c609a50ded drm/i915: Add skl_check_nv12_surface for NV12
3bb8c22c799b drm/i915: Enable Display WA 0528
df7ef5673726 drm/i915: Enable display workaround 827 for all planes, v2.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8932/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v8 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.

v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B

v7: Rebased (me)

v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.

v11: Addressed review comments from Shashank Sharma

v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.

v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported. These were
review comments from Kristian Høgsberg 

v15: Added reviewed by from Juha-Pekka Heikkila

v16: Rebased the series

v17: Added all tiling under mod supported for NV12
Credits to Megha Aggarwal

v18: Added RB by Maarten and Kristian

v19: Addressed review comments from Maarten
Made modification to skl_mod_supported

Credits-to: Megha Aggarwal 
Credits-to: Kristian Høgsberg 
Reviewed-by: Kristian Høgsberg 
Reviewed-by: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index c73553a..6b79e1f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1180,6 +1180,19 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static uint32_t skl_planar_formats[] = {
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1274,6 +1287,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -1373,8 +1387,14 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
 
-   plane_formats = skl_plane_formats;
-   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+   plane_formats = skl_planar_formats;
+   num_plane_formats = ARRAY_SIZE(skl_planar_formats);
+   } else {
+   plane_formats = skl_plane_formats;
+   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   }
 
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
modifiers = 

[Intel-gfx] [PATCH v8 5/6] drm/i915: Add NV12 as supported format for primary plane

2018-05-07 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 to list of supported formats for
primary plane

v2: Rebased (Chandra Konduru)

v3: Rebased (me)

v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats

v5: Rebased (me)

v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)

v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.

v11: Adding Reviewed By tag from Shashank Sharma

v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported. These were review comments
from Kristian Høgsberg 

v14: Added reviewed by from Juha-Pekka Heikkila

v15: Rebased the series

v16: Added all tiling support under mod supported
for NV12. Credits to Megha Aggarwal

v17: Added RB by Maarten and Kristian

v18: Review comments from Maarten addressed -
Removing BROXTON support for NV12 due to WA826

v19: Addressed review comments from Maarten
Make changes to skl_mod_supported

Credits-to: Megha Aggarwal megha.aggar...@intel.com
Credits-to: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Kristian Høgsberg 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 50 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e746948..5133934 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,6 +88,22 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint32_t skl_pri_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13202,6 +13218,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -13409,6 +13426,30 @@ static bool skl_plane_has_fbc(struct drm_i915_private 
*dev_priv,
return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
 }
 
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum plane_id plane_id)
+{
+   if (plane_id == PLANE_PRIMARY) {
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+   else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
+!IS_GEMINILAKE(dev_priv))
+   return false;
+   } else if (plane_id >= PLANE_SPRITE0) {
+   if (plane_id == PLANE_CURSOR)
+   return false;
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
+   if (plane_id != PLANE_SPRITE0)
+   return false;
+   } else {
+   if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
+   IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+   }
+   }
+   return true;
+}
+
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13469,8 +13510,13 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
primary->check_plane = intel_check_primary_plane;
 
if 

[Intel-gfx] [PATCH v8 0/6] Enable NV12 support

2018-05-07 Thread Vidya Srinivas
Enabling NV12 support:
- Framebuffer creation
- Primary and Sprite plane support
Patch series depend on Enable display workaround 827 patch
mentioned below submitted by Maarten
Removed BXT support for NV12 due to WA826

Changes from prev version:
Made change to skl_check_nv12_surface as required by WA#1106

Chandra Konduru (3):
  drm/i915: Add NV12 support to intel_framebuffer_init
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane

Maarten Lankhorst (2):
  drm/i915: Enable display workaround 827 for all planes, v2.
  drm/i915: Add skl_check_nv12_surface for NV12

Srinivas, Vidya (1):
  drm/i915: Enable Display WA 0528

 drivers/gpu/drm/i915/intel_atomic_plane.c |   7 +-
 drivers/gpu/drm/i915/intel_display.c  | 160 ++
 drivers/gpu/drm/i915/intel_drv.h  |   3 +
 drivers/gpu/drm/i915/intel_sprite.c   |  25 -
 4 files changed, 171 insertions(+), 24 deletions(-)

-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 2:56 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12
> 
> Op 10-05-18 om 10:31 schreef Vidya Srinivas:
> > From: Maarten Lankhorst 
> >
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > v3: Moving all the src coords handling code for NV12 to
> > skl_check_nv12_surface
> >
> > v4: Added RB from Mika
> >
> > v5: Rebased the series. Removed checks of mult of 4 in
> > skl_update_scaler, Added NV12 condition in intel_check_sprite_plane
> > where src x/w is being checked for mult of 2 for yuv planes.
> >
> > Reviewed-by: Mika Kahola 
> > Signed-off-by: Maarten Lankhorst 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 42
> > ++--
> >  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
> >  2 files changed, 41 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index dfca71e..cca46f9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3102,6 +3102,42 @@ static int skl_check_main_surface(const struct
> intel_crtc_state *crtc_state,
> > return 0;
> >  }
> >
> > +static int
> > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> > +  struct intel_plane_state *plane_state) {
> > +   int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> > +   int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> > +
> > +   if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_y >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_w >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_h >> 16) % 4) != 0) {
> > +   DRM_DEBUG_KMS("src coords must be multiple of 4 for
> NV12\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> > +   if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
> 4) ||
> > +   (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))
> {
> > +   DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> %u,%u\n",
> > + crtc_x2, crtc_y2,
> > + crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> > +   return -EINVAL;
> > +   }
> Oops, wrong checks here..
> 
> skl_check_nv12_surface is only needed for Display WA #1106, so check
> might need to be something like:
> 
> static int
> skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>  struct intel_plane_state *plane_state) {
>   /* Display WA #1106 */
>   if (plane_state->base.rotation != (DRM_MODE_REFLECT_X |
> DRM_MODE_ROTATE_90) &&
>   plane_state->base.rotation != DRM_MODE_ROTATE_270)
>   return 0;
> 
>   /* src coordinates are rotated here. We check height but report it as
> width. */
>   if (((drm_rect_height(_state->base.src) >> 16) % 4) != 0) {
>   DRM_DEBUG_KMS("src width must be multiple of 4 for
> rotated NV12\n");
>   return -EINVAL;
>   }
> 
>   return 0;
> }
> 
> Would this hit FIFO underruns?

Thank you. I have made the change and floated the series. Please have a check.
When I tested It on my end on GLK, I did not observe any fifo underruns. Will 
wait for IGT
test results from BAT.

Regards
Vidya


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


[Intel-gfx] [PATCH v8 2/6] drm/i915: Enable Display WA 0528

2018-05-07 Thread Vidya Srinivas
From: "Srinivas, Vidya" 

Possible hang with NV12 plane surface formats.
WA: When the plane source pixel format is NV12,
the CHICKEN_PIPESL_* register bit 22 must be set to 1
and the render decompression must not be enabled
on any of the planes in that pipe.

v2: removed unnecessary POSTING_READ

v3: Added RB from Maarten

v4: Removed support for NV12 for BROXTON

Credits-to: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bdbb995..dfca71e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -489,9 +489,21 @@ static const struct intel_limit intel_limits_bxt = {
 };
 
 static void
+skl_wa_528(struct drm_i915_private *dev_priv, int pipe, bool enable)
+{
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return;
+
+   if (enable)
+   I915_WRITE(CHICKEN_PIPESL_1(pipe), HSW_FBCQ_DIS);
+   else
+   I915_WRITE(CHICKEN_PIPESL_1(pipe), 0);
+}
+
+static void
 skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
 {
-   if (IS_SKYLAKE(dev_priv))
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
return;
 
if (enable)
@@ -5193,8 +5205,10 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
 
/* Display WA 827 */
if (needs_nv12_wa(dev_priv, old_crtc_state) &&
-   !needs_nv12_wa(dev_priv, pipe_config))
+   !needs_nv12_wa(dev_priv, pipe_config)) {
skl_wa_clkgate(dev_priv, crtc->pipe, false);
+   skl_wa_528(dev_priv, crtc->pipe, false);
+   }
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
@@ -5231,8 +5245,10 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
 
/* Display WA 827 */
if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
-   needs_nv12_wa(dev_priv, pipe_config))
+   needs_nv12_wa(dev_priv, pipe_config)) {
skl_wa_clkgate(dev_priv, crtc->pipe, true);
+   skl_wa_528(dev_priv, crtc->pipe, true);
+   }
 
/*
 * Vblank time updates from the shadow to live plane control register
-- 
2.7.4

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


[Intel-gfx] [PATCH v8 3/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-05-07 Thread Vidya Srinivas
From: Maarten Lankhorst 

We skip src trunction/adjustments for
NV12 case and handle the sizes directly.
Without this, pipe fifo underruns are seen on APL/KBL.

v2: For NV12, making the src coordinates multiplier of 4

v3: Moving all the src coords handling code for NV12
to skl_check_nv12_surface

v4: Added RB from Mika

v5: Rebased the series. Removed checks of mult of 4 in
skl_update_scaler, Added NV12 condition in intel_check_sprite_plane
where src x/w is being checked for mult of 2 for yuv planes.

v6: Made changes to skl_check_nv12_surface as per WA#1106

Reviewed-by: Mika Kahola 
Signed-off-by: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 29 +++--
 drivers/gpu/drm/i915/intel_sprite.c  |  1 +
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dfca71e..6c42910 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3102,6 +3102,29 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
return 0;
 }
 
+static int
+skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
+  struct intel_plane_state *plane_state)
+{
+   /* Display WA #1106 */
+   if (plane_state->base.rotation !=
+   (DRM_MODE_REFLECT_X | DRM_MODE_ROTATE_90) &&
+   plane_state->base.rotation != DRM_MODE_ROTATE_270)
+   return 0;
+
+   /*
+* src coordinates are rotated here.
+* We check height but report it as width
+*/
+   if (((drm_rect_height(_state->base.src) >> 16) % 4) != 0) {
+   DRM_DEBUG_KMS("src width must be multiple "
+ "of 4 for rotated NV12\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
 {
const struct drm_framebuffer *fb = plane_state->base.fb;
@@ -3185,6 +3208,9 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
 * the main surface setup depends on it.
 */
if (fb->format->format == DRM_FORMAT_NV12) {
+   ret = skl_check_nv12_surface(crtc_state, plane_state);
+   if (ret)
+   return ret;
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
@@ -4806,8 +4832,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
}
 
if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
-   (src_h < SKL_MIN_YUV_420_SRC_H || (src_w % 4) != 0 ||
-(src_h % 4) != 0)) {
+   (src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
DRM_DEBUG_KMS("NV12: src dimensions not met\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0c394a2..c73553a 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1011,6 +1011,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
src->y2 = (src_y + src_h) << 16;
 
if (intel_format_is_yuv(fb->format->format) &&
+   fb->format->format != DRM_FORMAT_NV12 &&
(src_x % 2 || src_w % 2)) {
DRM_DEBUG_KMS("src x/w (%u, %u) must be a multiple of 2 
for YUV planes\n",
  src_x, src_w);
-- 
2.7.4

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


[Intel-gfx] [PATCH v8 1/6] drm/i915: Enable display workaround 827 for all planes, v2.

2018-05-07 Thread Vidya Srinivas
From: Maarten Lankhorst 

The workaround was applied only to the primary plane, but is required
on all planes. Iterate over all planes in the crtc atomic check to see
if the workaround is enabled, and only perform the actual toggling in
the pre/post plane update functions.

Changes since v1:
- Track active NV12 planes in a nv12_planes bitmask. (Ville)

v2: Removing BROXTON support for NV12 due to WA826

Signed-off-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  7 -
 drivers/gpu/drm/i915/intel_display.c  | 43 +++
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 3 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce8..6d06878 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -183,11 +183,16 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
}
 
/* FIXME pre-g4x don't work like this */
-   if (intel_state->base.visible)
+   if (state->visible)
crtc_state->active_planes |= BIT(intel_plane->id);
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
 
+   if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+   crtc_state->nv12_planes |= BIT(intel_plane->id);
+   else
+   crtc_state->nv12_planes &= ~BIT(intel_plane->id);
+
return intel_plane_atomic_calc_changes(old_crtc_state,
   _state->base,
   old_plane_state,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3fd249c..bdbb995 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5142,6 +5142,22 @@ static bool hsw_post_update_enable_ips(const struct 
intel_crtc_state *old_crtc_s
return !old_crtc_state->ips_enabled;
 }
 
+static bool needs_nv12_wa(struct drm_i915_private *dev_priv,
+ const struct intel_crtc_state *crtc_state)
+{
+   if (!crtc_state->nv12_planes)
+   return false;
+
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+
+   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+   IS_CANNONLAKE(dev_priv))
+   return true;
+
+   return false;
+}
+
 static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
@@ -5166,7 +5182,6 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
if (old_primary_state) {
struct drm_plane_state *new_primary_state =
drm_atomic_get_new_plane_state(old_state, primary);
-   struct drm_framebuffer *fb = new_primary_state->fb;
 
intel_fbc_post_update(crtc);
 
@@ -5174,15 +5189,12 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
(needs_modeset(_config->base) ||
 !old_primary_state->visible))
intel_post_enable_primary(>base, pipe_config);
-
-   /* Display WA 827 */
-   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
-   IS_CANNONLAKE(dev_priv)) {
-   if (fb && fb->format->format == DRM_FORMAT_NV12)
-   skl_wa_clkgate(dev_priv, crtc->pipe, false);
-   }
-
}
+
+   /* Display WA 827 */
+   if (needs_nv12_wa(dev_priv, old_crtc_state) &&
+   !needs_nv12_wa(dev_priv, pipe_config))
+   skl_wa_clkgate(dev_priv, crtc->pipe, false);
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
@@ -5206,14 +5218,6 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
struct intel_plane_state *new_primary_state =
intel_atomic_get_new_plane_state(old_intel_state,
 
to_intel_plane(primary));
-   struct drm_framebuffer *fb = new_primary_state->base.fb;
-
-   /* Display WA 827 */
-   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
-   IS_CANNONLAKE(dev_priv)) {
-   if (fb && fb->format->format == DRM_FORMAT_NV12)
-   skl_wa_clkgate(dev_priv, crtc->pipe, true);
-   }
 
intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
/*
@@ -5225,6 +5229,11 @@ static void 

[Intel-gfx] [PATCH v8 4/6] drm/i915: Add NV12 support to intel_framebuffer_init

2018-05-07 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.

v6: Rebased (me)

v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.

v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.

v9: Rebased (me)

v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable

v11: Addressed review comments from Shashank Sharma

v12: Adding Reviewed By from Shashank Sharma

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Maarten.
Add checks for fb width height for NV12 and fail the fb
creation if check fails. Added reviewed by from
Juha-Pekka Heikkila

v15: Rebased the series

v16: Setting the minimum value during fb creating to 16
as per Bspec for NV12. Earlier minimum was expected
to be > 16. Now changed it to >=16.

v17: Adding restriction to framebuffer_init - the fb
width and height should be a multiplier of 4

v18: Added RB from Maarten. Included Maarten's review comments
Dont allow CCS formats for fb creation of NV12

v19: Review comments from Maarten addressed -
Removing BROXTON support for NV12 due to WA826

Credits-to: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6c42910..e746948 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14291,6 +14291,20 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_NV12:
+   if (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED_CCS ||
+   mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED_CCS) {
+   DRM_DEBUG_KMS("RC not to be enabled with NV12\n");
+   goto err;
+   }
+   if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv) ||
+   IS_BROXTON(dev_priv)) {
+   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+ 
drm_get_format_name(mode_cmd->pixel_format,
+ _name));
+   goto err;
+   }
+   break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
@@ -14303,6 +14317,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 
drm_helper_mode_fill_fb_struct(_priv->drm, fb, mode_cmd);
 
+   if (fb->format->format == DRM_FORMAT_NV12 &&
+   (fb->width < SKL_MIN_YUV_420_SRC_W ||
+fb->height < SKL_MIN_YUV_420_SRC_H ||
+(fb->width % 4) != 0 || (fb->height % 4) != 0)) {
+   DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
+   return -EINVAL;
+   }
+
for (i = 0; i < fb->format->num_planes; i++) {
u32 stride_alignment;
 
-- 
2.7.4

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


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Drop unused parameter to lookup_priolist()

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/execlists: Drop unused parameter to 
lookup_priolist()
URL   : https://patchwork.freedesktop.org/series/42836/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4152_full -> Patchwork_8930_full =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42836/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8930_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@cursor-vs-flip-toggle:
  shard-hsw:  PASS -> FAIL (fdo#103355)

igt@kms_flip@2x-dpms-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103928)
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@plain-flip-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#100368) +1

igt@kms_rotation_crc@primary-rotation-270:
  shard-apl:  PASS -> FAIL (fdo#103925, fdo#104724) +1


 Possible fixes 

igt@drv_selftest@live_contexts:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-hsw:  FAIL (fdo#103060) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724


== Participating hosts (6 -> 6) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4152 -> Patchwork_8930

  CI_DRM_4152: 06e15c0f055b8b8e326bb65fa83f69b1b7391e51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8930: b3992f1e5c088e330d75c3fe8c99835d4328673a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8930/shards.html
___
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 linux-next: build failure after merge of the drm-intel tree

2018-05-07 Thread Stephen Rothwell
Hi all,

On Tue, 08 May 2018 01:36:25 - Patchwork  
wrote:
>
> == Series Details ==
> 
> Series: linux-next: build failure after merge of the drm-intel tree
> URL   : https://patchwork.freedesktop.org/series/42839/
> State : failure

Blah, blah :-)

Can someone please arrange for my linux-next merge fix patches to not
be fed into your patchwork/ci as they will never work out side
linux-next ...

-- 
Cheers,
Stephen Rothwell


pgppUO97yreq8.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for linux-next: build failure after merge of the drm-intel tree

2018-05-07 Thread Patchwork
== Series Details ==

Series: linux-next: build failure after merge of the drm-intel tree
URL   : https://patchwork.freedesktop.org/series/42839/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4152 -> Patchwork_8931 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8931 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8931, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42839/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8931:

  === IGT changes ===

 Possible regressions 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-hsw-4200u:   PASS -> FAIL


== Known issues ==

  Here are the changes found in Patchwork_8931 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951)


 Possible fixes 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-skl-6770hq:  FAIL (fdo#103928, fdo#100368) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951


== Participating hosts (41 -> 37) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4152 -> Patchwork_8931

  CI_DRM_4152: 06e15c0f055b8b8e326bb65fa83f69b1b7391e51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8931: 3c1454cc91d53c9b6782b9fd72071fcf24e6fe3f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

3c1454cc91d5 linux-next: build failure after merge of the drm-intel tree

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8931/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for linux-next: build failure after merge of the drm-intel tree

2018-05-07 Thread Patchwork
== Series Details ==

Series: linux-next: build failure after merge of the drm-intel tree
URL   : https://patchwork.freedesktop.org/series/42839/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3c1454cc91d5 linux-next: build failure after merge of the drm-intel tree
-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit c575b7eeb89f ("drm/xen-front: 
Add support for Xen PV display frontend")'
#25: 
  c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")

-:37: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#37: 
Subject: [PATCH] drm/xen-front: merge fix for "drivers: remove force dma flag 
from buses"

total: 1 errors, 1 warnings, 0 checks, 10 lines checked

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


[Intel-gfx] linux-next: build failure after merge of the drm-intel tree

2018-05-07 Thread Stephen Rothwell
Hi all,

After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/xen/xen_drm_front.c: In function 'xen_drv_probe':
drivers/gpu/drm/xen/xen_drm_front.c:740:10: error: 'struct bus_type' has no 
member named 'force_dma'
  dev->bus->force_dma = true;
  ^~
drivers/gpu/drm/xen/xen_drm_front.c:742:8: error: too few arguments to function 
'of_dma_configure'
  ret = of_dma_configure(dev, NULL);
^~~~
In file included from drivers/gpu/drm/xen/xen_drm_front.c:16:0:
include/linux/of_device.h:58:5: note: declared here
 int of_dma_configure(struct device *dev,
 ^~~~

Caused by commit

  c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")

interacting with commit

  3d6ce86ee794 ("drivers: remove force dma flag from buses")

from the dma-mapping tree.

I have added the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 8 May 2018 11:02:24 +1000
Subject: [PATCH] drm/xen-front: merge fix for "drivers: remove force dma flag 
from buses"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/xen/xen_drm_front.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1b0ea9ac330e..0e486cb1c10c 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -737,9 +737,8 @@ static int xen_drv_probe(struct xenbus_device *xb_dev,
 * is not correct: to fix this call of_dma_configure() with a NULL
 * node to set default DMA ops.
 */
-   dev->bus->force_dma = true;
dev->coherent_dma_mask = DMA_BIT_MASK(32);
-   ret = of_dma_configure(dev, NULL);
+   ret = of_dma_configure(dev, NULL, true);
if (ret < 0) {
DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
return ret;
-- 
2.17.0

-- 
Cheers,
Stephen Rothwell


pgpJRVkeJqfMO.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: configure the transcoder clocks before touching pipeconf on HSW+ (rev2)

2018-05-07 Thread Patchwork
== Series Details ==

Series: drm/i915: configure the transcoder clocks before touching pipeconf on 
HSW+ (rev2)
URL   : https://patchwork.freedesktop.org/series/42436/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4151_full -> Patchwork_8929_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8929_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8929_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42436/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8929_full:

  === IGT changes ===

 Possible regressions 

igt@perf_pmu@interrupts-sync:
  shard-hsw:  PASS -> FAIL


 Warnings 

igt@gem_mocs_settings@mocs-rc6-blt:
  shard-kbl:  PASS -> SKIP

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_8929_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060) +1

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_rotation_crc@primary-rotation-180:
  shard-apl:  PASS -> FAIL (fdo#103925, fdo#104724)

igt@kms_setmode@basic:
  shard-glk:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@drv_selftest@live_contexts:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@drv_selftest@live_gtt:
  shard-apl:  INCOMPLETE (fdo#103927) -> PASS

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#102887) -> PASS

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-glk:  FAIL (fdo#103060) -> PASS

igt@kms_flip@plain-flip-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_pwrite_crc:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103313, fdo#103558) -> 
PASS +6

igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
  shard-apl:  FAIL (fdo#103925, fdo#104724) -> PASS +1

igt@pm_rpm@debugfs-read:
  shard-kbl:  DMESG-WARN (fdo#103313, fdo#103558) -> PASS

igt@pm_rpm@i2c:
  shard-kbl:  DMESG-FAIL (fdo#103313, fdo#103558) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 6) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4151 -> Patchwork_8929

  CI_DRM_4151: 176975baca37c5cdb1632b9aa2ba0170c9ab53df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8929: 3ed9e5ed8acae24777f512cd36516a2815ccf907 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8929/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Drop unused parameter to lookup_priolist()

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/execlists: Drop unused parameter to 
lookup_priolist()
URL   : https://patchwork.freedesktop.org/series/42836/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4152 -> Patchwork_8930 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42836/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8930 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_module_reload@basic-reload:
  fi-bsw-n3050:   PASS -> DMESG-FAIL (fdo#106373)


 Possible fixes 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-skl-6770hq:  FAIL (fdo#103928, fdo#100368) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#106373 https://bugs.freedesktop.org/show_bug.cgi?id=106373


== Participating hosts (41 -> 36) ==

  Missing(5): fi-ctg-p8600 fi-byt-squawks fi-ilk-m540 fi-glk-j4005 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4152 -> Patchwork_8930

  CI_DRM_4152: 06e15c0f055b8b8e326bb65fa83f69b1b7391e51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8930: b3992f1e5c088e330d75c3fe8c99835d4328673a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

b3992f1e5c08 drm/i915/execlists: Cache the priolist when rescheduling
fbc6c33847ee drm/i915/execlists: Drop unused parameter to lookup_priolist()

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8930/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/execlists: Drop unused parameter to lookup_priolist()

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/execlists: Drop unused parameter to 
lookup_priolist()
URL   : https://patchwork.freedesktop.org/series/42836/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
fbc6c33847ee drm/i915/execlists: Drop unused parameter to lookup_priolist()
b3992f1e5c08 drm/i915/execlists: Cache the priolist when rescheduling
-:21: WARNING:FUNCTION_ARGUMENTS: function definition argument 'pl' should also 
have an identifier name
#21: FILE: drivers/gpu/drm/i915/intel_lrc.c:1200:
+   struct i915_priolist *uninitialized_var(pl);

total: 0 errors, 1 warnings, 0 checks, 29 lines checked

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


[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Cache the priolist when rescheduling

2018-05-07 Thread Chris Wilson
When rescheduling a change of dependencies, they all need to be added to
the same priolist (at least the ones on the same engine!). Since we
likely want to move a batch of requests, keep the priolist around.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a9d211f28ab8..28a02d3b53a4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1197,7 +1197,8 @@ sched_lock_engine(struct i915_sched_node *node, struct 
intel_engine_cs *locked)
 static void execlists_schedule(struct i915_request *request,
   const struct i915_sched_attr *attr)
 {
-   struct intel_engine_cs *engine;
+   struct i915_priolist *uninitialized_var(pl);
+   struct intel_engine_cs *engine, *last;
struct i915_dependency *dep, *p;
struct i915_dependency stack;
const int prio = attr->priority;
@@ -1270,6 +1271,7 @@ static void execlists_schedule(struct i915_request 
*request,
__list_del_entry(_link);
}
 
+   last = NULL;
engine = request->engine;
spin_lock_irq(>timeline.lock);
 
@@ -1286,8 +1288,11 @@ static void execlists_schedule(struct i915_request 
*request,
 
node->attr.priority = prio;
if (!list_empty(>link)) {
-   __list_del_entry(>link);
-   queue_request(engine, node, prio);
+   if (last != engine) {
+   pl = lookup_priolist(engine, prio);
+   last = engine;
+   }
+   list_move_tail(>link, >requests);
}
 
if (prio > engine->execlists.queue_priority &&
-- 
2.17.0

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


[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Drop unused parameter to lookup_priolist()

2018-05-07 Thread Chris Wilson
lookup_priolist() no longer attaches the request into the priolist, it
just returns the priolist for the given priority instead. Drop the
unused parameter.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f9f4064dec0e..a9d211f28ab8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -258,9 +258,7 @@ intel_lr_context_descriptor_update(struct i915_gem_context 
*ctx,
 }
 
 static struct i915_priolist *
-lookup_priolist(struct intel_engine_cs *engine,
-   struct i915_sched_node *node,
-   int prio)
+lookup_priolist(struct intel_engine_cs *engine, int prio)
 {
struct intel_engine_execlists * const execlists = >execlists;
struct i915_priolist *p;
@@ -345,7 +343,7 @@ static void __unwind_incomplete_requests(struct 
intel_engine_cs *engine)
GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
if (rq_prio(rq) != last_prio) {
last_prio = rq_prio(rq);
-   p = lookup_priolist(engine, >sched, last_prio);
+   p = lookup_priolist(engine, last_prio);
}
 
list_add(>sched.link, >requests);
@@ -1144,7 +1142,7 @@ static void queue_request(struct intel_engine_cs *engine,
  int prio)
 {
list_add_tail(>link,
- _priolist(engine, node, prio)->requests);
+ _priolist(engine, prio)->requests);
 }
 
 static void __submit_queue(struct intel_engine_cs *engine, int prio)
-- 
2.17.0

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: configure the transcoder clocks before touching pipeconf on HSW+ (rev2)

2018-05-07 Thread Patchwork
== Series Details ==

Series: drm/i915: configure the transcoder clocks before touching pipeconf on 
HSW+ (rev2)
URL   : https://patchwork.freedesktop.org/series/42436/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4151 -> Patchwork_8929 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42436/revisions/2/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8929 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_module_reload@basic-reload:
  fi-bsw-n3050:   PASS -> DMESG-FAIL (fdo#106373)

igt@gem_exec_suspend@basic-s4-devices:
  fi-skl-guc: PASS -> FAIL (fdo#105900, fdo#104699) +1

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-cnl-psr: PASS -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   PASS -> DMESG-FAIL (fdo#102614, fdo#106103)


 Possible fixes 

igt@drv_module_reload@basic-no-display:
  fi-bsw-n3050:   DMESG-FAIL (fdo#106373) -> PASS

igt@kms_chamelium@hdmi-hpd-fast:
  fi-kbl-7500u:   FAIL (fdo#103841, fdo#102672) -> SKIP

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-elk-e7500:   INCOMPLETE (fdo#103989) -> PASS

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cnl-psr: FAIL (fdo#103481) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#104699 https://bugs.freedesktop.org/show_bug.cgi?id=104699
  fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103
  fdo#106373 https://bugs.freedesktop.org/show_bug.cgi?id=106373


== Participating hosts (41 -> 35) ==

  Missing(6): fi-ilk-m540 fi-byt-j1900 fi-byt-squawks fi-ctg-p8600 
fi-glk-j4005 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4151 -> Patchwork_8929

  CI_DRM_4151: 176975baca37c5cdb1632b9aa2ba0170c9ab53df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8929: 3ed9e5ed8acae24777f512cd36516a2815ccf907 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

3ed9e5ed8aca drm/i915: enable the pipe/transcoder/planes later on HSW+

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8929/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t 3/4] trace.pl: Fix incomplete request handling

2018-05-07 Thread John Harrison

On 4/23/2018 2:52 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Incomplete requests (no notify, no context complete) have to be corrected
by looking at the engine timeline, and not the sorted-by-start-time view
as was previously used.

Per-engine timelines are generated on demand and cached for later use.

v2: Find end of current context on the engine timeline instead of just
 using the next request for adjusting the incomplete start time.

Signed-off-by: Tvrtko Ursulin 
Cc: John Harrison 
---
  scripts/trace.pl | 86 ++--
  1 file changed, 65 insertions(+), 21 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index eb5a36b91a5c..b48f43225fc1 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -26,6 +26,8 @@ use strict;
  use warnings;
  use 5.010;
  
+use List::Util;

+
  my $gid = 0;
  my (%db, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait);
  my @freqs;
@@ -516,29 +518,71 @@ foreach my $key (keys %db) {
}
  }
  
-# Fix up incompletes

  my $key_count = scalar(keys %db);
-foreach my $key (keys %db) {
-   next unless exists $db{$key}->{'incomplete'};
  
-	# End the incomplete batch at the time next one starts

-   my $ring = $db{$key}->{'ring'};
-   my $ctx = $db{$key}->{'ctx'};
-   my $seqno = $db{$key}->{'seqno'};
-   my $next_key;
-   my $i = 1;
+my %engine_timelines;
+
+sub sortEngine {
+   my $as = $db{$a}->{'global'};
+   my $bs = $db{$b}->{'global'};
+   my $val;
+
+   $val = $as <=> $bs;
+
+   die if $val == 0;
+
+   return $val;
+}
+
+sub get_engine_timeline {
+   my ($ring) = @_;
+   my @timeline;
+
+   return $engine_timelines{$ring} if exists $engine_timelines{$ring};
+
+   @timeline = grep { $db{$_}->{'ring'} == $ring } keys %db;
+   # FIXME seqno restart
+   @timeline = sort sortEngine @timeline;
+
+   $engine_timelines{$ring} = \@timeline;
+
+   return \@timeline;
+}
+
+# Fix up incompletes by ending them when the last request of a coalesced group
+# ends. Start by filtering out the incomplete requests.
+my @incompletes = sort grep { exists $db{$_}->{'incomplete'} } keys %db;
+
+foreach my $key (@incompletes) {
+   my $timeline;
+   my $last_key;
my $end;
+   my $i;
  
-	do {

-   $next_key = db_key($ring, $ctx, $seqno + $i);
-   $i++;
-   } until ((exists $db{$next_key} and not exists 
$db{$next_key}->{'incomplete'})
-or $i > $key_count);  # ugly stop hack
+   # Find the next request on the engine timeline.
+   $timeline = get_engine_timeline($db{$key}->{'ring'});
+   $i = List::Util::first { ${$timeline}[$_] eq $key } 0..$#{$timeline};
This line in particular massively slows the process down! With one of my 
longer trace files, the incomplete fix-up step took 30 seconds prior to 
this. After this patch, it took 11205 seconds! Just shy of four hours!


Caching the start point of the search greatly speeds things up but it is 
still a lot slower than previous. With the following, it is down to 4068 
seconds, or a little over one hour.

+my $lastIndex = 0;
...
-   $i = List::Util::first { ${$timeline}[$_] eq $key } 
0..$#{$timeline};
+   $i = List::Util::first { ${$timeline}[$_] eq $key } 
${lastIndex}..$#{$timeline};

+   if( !defined($i) ) {
+   $i = List::Util::first { ${$timeline}[$_] eq $key } 
0..$#{$timeline};

+   defined($i) || die "Failed to find '$key'!\n";
+   }
+   $lastIndex = $i;

If I sort the '@incompletes' array numerically by seqno rather than as a 
string sort, then I get rid of all the first level match failures 
(except when rolling from one ring to the next) and the time drops to 
1819 seconds or half an hour.


+sub sortKeys {
+   my( $aR, $aC, $aS ) = split( '/', $a );
+   my( $bR, $bC, $bS ) = split( '/', $b );
+   my $val;
+
+   $val = $aR <=> $bR;
+   return $val if $val != 0;
+
+   $val = $aC <=> $bC;
+   return $val if $val != 0;
+
+   return $aS <=> $bS;
+}
+

-my @incompletes = sort grep { exists $db{$_}->{'incomplete'} } keys %db;
+my @incompletes = sort sortKeys grep { exists $db{$_}->{'incomplete'} } 
keys %db;





+
+   while ($i < $#{$timeline}) {
+   my $next;
+
+   $i = $i + 1;

$i++; ?


+   $next = ${$timeline}[$i];
+
+   next if exists $db{$next}->{'incomplete'};
  
-	if (exists $db{$next_key}) {

-   $end = $db{$next_key}->{'end'};
+   $last_key = $next;
+   last;
+   }
+
+   if (defined $last_key) {
+   if ($db{$key}->{'ctx'} eq $db{$last_key}->{'ctx'}) {
+   $end = $db{$last_key}->{'end'};
+   } else {
+   $end = $db{$last_key}->{'start'};
+   }
} else {
-

Re: [Intel-gfx] [PATCH 1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate

2018-05-07 Thread Chris Wilson
Quoting Mika Kuoppala (2018-05-07 17:52:18)
> We use a pattern of wmb() along with ggtt_invalidate.
> Move the wmb out from call sites into the ggtt_invalidate
> as it is part of invalidation.
> 
> Cc: Chris Wilson 
> Cc: Matthew Auld 
> Signed-off-by: Mika Kuoppala 

If we take this and the last which look at ggtt together, then
Reviewed-by: Chris Wilson 

I've a persistent dread when it comes to write through the GTT itself,
as different wc buffers seem to mess up aliasing, but this should be
simple wc vs uc mmio, so playing by concrete rules.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Don't request a bug report for unsafe module parameters

2018-05-07 Thread Rodrigo Vivi
On Sun, May 06, 2018 at 07:31:47PM +0100, Chris Wilson wrote:
> Unsafe module parameters are just that, unsafe. If the user is foolish
> enough to try them and the kernel breaks, they get to keep both pieces.
> Don't ask them to file a bug report if they broke it themselves.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=106423
> Fixes: d15d7538c6d2 ("drm/i915: Tune down init error message due to failure 
> injection")
> Signed-off-by: Chris Wilson 
> Cc: Imre Deak 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 

I believe there are cases where having the reports would be extremely useful,
like on PSR case.
But of course prioritized as "Lowest".

Better than not having anything and suddenly, when we switch
things on, we start having so many reports at once.

So, probably a different message would be worth trying?

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9b782045ae17..9c449b8d8eab 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -101,7 +101,13 @@ __i915_printk(struct drm_i915_private *dev_priv, const 
> char *level,
>  __builtin_return_address(0), );
>  
>   if (is_error && !shown_bug_once) {
> - dev_notice(kdev, "%s", FDO_BUG_MSG);
> + /*
> +  * Ask the user to file a bug report for the error, except
> +  * if they may have caused the bug by fiddling with unsafe
> +  * module parameters.
> +  */
> + if (!test_taint(TAINT_USER))
> + dev_notice(kdev, "%s", FDO_BUG_MSG);
>   shown_bug_once = true;
>   }
>  
> -- 
> 2.17.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/5] drm/i915/gtt: Flush write combining buffer on insert entries

2018-05-07 Thread Chris Wilson
Quoting Mika Kuoppala (2018-05-07 17:52:21)
> We could be using write combining map through which we insert
> our ptes. Make sure to flush the write combining buffer
> after the writes.

"Could?" We do flush the ppgtt before execution, and the ppgtt is only
used by execution.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/5] drm/i915/gtt: Don't track dirty in gen6_alloc_va_range

2018-05-07 Thread Chris Wilson
Quoting Mika Kuoppala (2018-05-07 17:52:20)
> gen6_alloc_va_range is only used to init the aliasing ppgtt, so
> we can be certain that it will be dirty every time. No need
> to track it.

Nah, we want it for full-ppgtt...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/5] drm/i915/gtt: Combine marking engines dirty with wmb

2018-05-07 Thread Chris Wilson
Quoting Mika Kuoppala (2018-05-07 17:52:19)
> It is a common pattern to mark the tlbs dirty along with flushing
> the writes. Introduce gen6_ppgtt_invalidate for this.

It wasn't that common at all. We were careful not to do more wmb() than
required before; not so now.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate
URL   : https://patchwork.freedesktop.org/series/42821/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4151_full -> Patchwork_8928_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8928_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8928_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42821/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8928_full:

  === IGT changes ===

 Warnings 

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_8928_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@modeset-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_rotation_crc@primary-rotation-270:
  shard-apl:  PASS -> FAIL (fdo#104724, fdo#103925)


 Possible fixes 

igt@drv_selftest@live_gtt:
  shard-apl:  INCOMPLETE (fdo#103927) -> PASS

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#102887) -> PASS

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-glk:  FAIL (fdo#103060) -> PASS

igt@kms_flip@plain-flip-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#103928) -> PASS

igt@kms_pwrite_crc:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#103313, fdo#105602) -> 
PASS +6

igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
  shard-apl:  FAIL (fdo#104724, fdo#103925) -> PASS +1

igt@pm_rpm@debugfs-read:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#103313) -> PASS

igt@pm_rpm@i2c:
  shard-kbl:  DMESG-FAIL (fdo#103558, fdo#103313) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602


== Participating hosts (6 -> 6) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4151 -> Patchwork_8928

  CI_DRM_4151: 176975baca37c5cdb1632b9aa2ba0170c9ab53df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8928: 1455371931347174e0a6087e9de8de0ff071b631 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8928/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/8] drm/i915/icl: add basic support for the ICL clocks

2018-05-07 Thread James Ausmus
On Fri, Apr 27, 2018 at 04:14:36PM -0700, Paulo Zanoni wrote:
> This commit introduces the definitions for the ICL clocks and adds the
> basic functions to the shared DPLL framework. It adds code for the
> Enable and Disable sequences for some PLLs, but it does not have the
> code to compute the actual PLL values, which are marked as TODO
> comments and should be introduced as separate commits.
> 
> Special thanks to James Ausmus for investigating and fixing a bug with
> the placement of icl_unmap_plls_to_ports() function.
> 
> v2:
>  - Rebase around dpll_lock changes.
> v3:
>  - The spec now says what the timeouts should be.
>  - Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
>the machine.
>  - Checkpatch found a white space problem.
>  - Small adjustments before upstreaming.
> v4:
>  - Move the ICL checks out of the *map_plls_to_ports() functions
>   (James)
>  - Add extra encoder check (James)
>  - Call icl_unmap_plls_to_ports() later (James)
> v5:
>  - Rebase after the pll struct changes.
> v6:
>  - Properly make the unmap function based on encoders_post_disable()
>with regarding to checks and iterators.
>  - Address checkpatch comment on "min = max = x()".
> 
> Cc: James Ausmus 
> Signed-off-by: Paulo Zanoni 

Reviewed-by: James Ausmus 


> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   |  22 +++
>  drivers/gpu/drm/i915/intel_ddi.c  |  98 ++-
>  drivers/gpu/drm/i915/intel_display.c  |  16 ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 313 
> +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |  41 +
>  drivers/gpu/drm/i915/intel_drv.h  |   6 +
>  6 files changed, 491 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index cb1a804bf72e..ba8927cb1dcc 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3365,6 +3365,28 @@ static int i915_shared_dplls_info(struct seq_file *m, 
> void *unused)
>   seq_printf(m, " fp0: 0x%08x\n", pll->state.hw_state.fp0);
>   seq_printf(m, " fp1: 0x%08x\n", pll->state.hw_state.fp1);
>   seq_printf(m, " wrpll:   0x%08x\n", pll->state.hw_state.wrpll);
> + seq_printf(m, " cfgcr0:  0x%08x\n", pll->state.hw_state.cfgcr0);
> + seq_printf(m, " cfgcr1:  0x%08x\n", pll->state.hw_state.cfgcr1);
> + seq_printf(m, " mg_refclkin_ctl:0x%08x\n",
> +pll->state.hw_state.mg_refclkin_ctl);
> + seq_printf(m, " mg_clktop2_coreclkctl1: 0x%08x\n",
> +pll->state.hw_state.mg_clktop2_coreclkctl1);
> + seq_printf(m, " mg_clktop2_hsclkctl:0x%08x\n",
> +pll->state.hw_state.mg_clktop2_hsclkctl);
> + seq_printf(m, " mg_pll_div0:  0x%08x\n",
> +pll->state.hw_state.mg_pll_div0);
> + seq_printf(m, " mg_pll_div1:  0x%08x\n",
> +pll->state.hw_state.mg_pll_div1);
> + seq_printf(m, " mg_pll_lf:0x%08x\n",
> +pll->state.hw_state.mg_pll_lf);
> + seq_printf(m, " mg_pll_frac_lock: 0x%08x\n",
> +pll->state.hw_state.mg_pll_frac_lock);
> + seq_printf(m, " mg_pll_ssc:   0x%08x\n",
> +pll->state.hw_state.mg_pll_ssc);
> + seq_printf(m, " mg_pll_bias:  0x%08x\n",
> +pll->state.hw_state.mg_pll_bias);
> + seq_printf(m, " mg_pll_tdc_coldst_bias: 0x%08x\n",
> +pll->state.hw_state.mg_pll_tdc_coldst_bias);
>   }
>   drm_modeset_unlock_all(dev);
>  
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 92cb26b18a9b..178a7b0d0149 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1013,6 +1013,25 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const struct 
> intel_shared_dpll *pll)
>   }
>  }
>  
> +static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
> +const struct intel_shared_dpll *pll)
> +{
> + const enum intel_dpll_id id = pll->info->id;
> +
> + switch (id) {
> + default:
> + MISSING_CASE(id);
> + case DPLL_ID_ICL_DPLL0:
> + case DPLL_ID_ICL_DPLL1:
> + return DDI_CLK_SEL_NONE;
> + case DPLL_ID_ICL_MGPLL1:
> + case DPLL_ID_ICL_MGPLL2:
> + case DPLL_ID_ICL_MGPLL3:
> + case DPLL_ID_ICL_MGPLL4:
> + return DDI_CLK_SEL_MG;
> + }
> +}
> +
>  /* Starting with Haswell, different DDI ports can work in FDI mode for
>   * connection to the PCH-located connectors. For this, it is necessary to 
> train
>   * both the DDI port and PCH receiver for the desired DDI buffer settings.
> @@ -2234,6 +2253,69 @@ uint32_t 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/7] drm/i915: Flush submission tasklet after 
bumping priority
URL   : https://patchwork.freedesktop.org/series/42815/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4151_full -> Patchwork_8927_full =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42815/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8927_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_softpin@noreloc-s3:
  shard-snb:  PASS -> DMESG-WARN (fdo#102365)

igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge:
  shard-apl:  PASS -> FAIL (fdo#104724, fdo#104671)

igt@kms_flip@plain-flip-ts-check:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_rotation_crc@primary-rotation-270:
  shard-apl:  PASS -> FAIL (fdo#104724, fdo#103925)

igt@kms_setmode@basic:
  shard-glk:  PASS -> FAIL (fdo#99912)

igt@perf@blocking:
  shard-hsw:  PASS -> FAIL (fdo#102252)

igt@perf_pmu@enable-race-bcs0:
  shard-glk:  PASS -> INCOMPLETE (k.org#198133, fdo#103359)


 Possible fixes 

igt@drv_selftest@live_gtt:
  shard-apl:  INCOMPLETE (fdo#103927) -> PASS

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#102887) -> PASS

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-glk:  FAIL (fdo#103060) -> PASS

igt@kms_flip@plain-flip-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#103928) -> PASS

igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
  shard-apl:  FAIL (fdo#104724, fdo#103925) -> PASS +1


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
  fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (6 -> 5) ==

  Missing(1): shard-kbl 


== Build changes ==

* Linux: CI_DRM_4151 -> Patchwork_8927

  CI_DRM_4151: 176975baca37c5cdb1632b9aa2ba0170c9ab53df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8927: f11f14adf4e6010fc93ab44c0848ef846a522590 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8927/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate
URL   : https://patchwork.freedesktop.org/series/42821/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4151 -> Patchwork_8928 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42821/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8928 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@debugfs_test@read_all_entries:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)

igt@drv_module_reload@basic-reload:
  fi-bsw-n3050:   PASS -> DMESG-FAIL (fdo#106373)

igt@kms_chamelium@dp-edid-read:
  fi-kbl-7500u:   PASS -> FAIL (fdo#103841)

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-cfl-s3:  PASS -> FAIL (fdo#100368, fdo#103928)


 Possible fixes 

igt@drv_module_reload@basic-no-display:
  fi-bsw-n3050:   DMESG-FAIL (fdo#106373) -> PASS

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128) -> PASS

igt@kms_chamelium@hdmi-hpd-fast:
  fi-kbl-7500u:   FAIL (fdo#102672, fdo#103841) -> SKIP

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-elk-e7500:   INCOMPLETE (fdo#103989) -> PASS

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cnl-psr: FAIL (fdo#103481) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106373 https://bugs.freedesktop.org/show_bug.cgi?id=106373


== Participating hosts (41 -> 37) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4151 -> Patchwork_8928

  CI_DRM_4151: 176975baca37c5cdb1632b9aa2ba0170c9ab53df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8928: 1455371931347174e0a6087e9de8de0ff071b631 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

145537193134 drm/i915/gtt: Trust the uncached store to flush wcb
04cd57af405c drm/i915/gtt: Flush write combining buffer on insert entries
e85884eafe3a drm/i915/gtt: Don't track dirty in gen6_alloc_va_range
778f0e880a15 drm/i915/gtt: Combine marking engines dirty with wmb
09ef7cafacef drm/i915/gtt: Move wmb inside ggtt_invalidate

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8928/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate
URL   : https://patchwork.freedesktop.org/series/42821/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Move wmb inside ggtt_invalidate
Okay!

Commit: drm/i915/gtt: Combine marking engines dirty with wmb
-O:drivers/gpu/drm/i915/i915_gem_gtt.c:1724:9: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/i915_gem_gtt.c:1724:9: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:1730:9: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:1730:9: warning: expression using 
sizeof(void)

Commit: drm/i915/gtt: Don't track dirty in gen6_alloc_va_range
-O:drivers/gpu/drm/i915/i915_gem_gtt.c:1934:9: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/i915_gem_gtt.c:1934:9: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:1933:9: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:1933:9: warning: expression using 
sizeof(void)

Commit: drm/i915/gtt: Flush write combining buffer on insert entries
Okay!

Commit: drm/i915/gtt: Trust the uncached store to flush wcb
Okay!

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate
URL   : https://patchwork.freedesktop.org/series/42821/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
09ef7cafacef drm/i915/gtt: Move wmb inside ggtt_invalidate
778f0e880a15 drm/i915/gtt: Combine marking engines dirty with wmb
e85884eafe3a drm/i915/gtt: Don't track dirty in gen6_alloc_va_range
04cd57af405c drm/i915/gtt: Flush write combining buffer on insert entries
145537193134 drm/i915/gtt: Trust the uncached store to flush wcb
-:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#16: 
References: http://download.intel.com/design/PentiumII/applnots/24442201.pdf [2]

total: 0 errors, 1 warnings, 0 checks, 11 lines checked

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


[Intel-gfx] [PATCH 2/5] drm/i915/gtt: Combine marking engines dirty with wmb

2018-05-07 Thread Mika Kuoppala
It is a common pattern to mark the tlbs dirty along with flushing
the writes. Introduce gen6_ppgtt_invalidate for this.

Cc: Chris Wilson 
Cc: Matthew Auld 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2963d3d71729..b162617afe18 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -108,6 +108,21 @@
 static int
 i915_get_ggtt_vma_pages(struct i915_vma *vma);
 
+static void gen6_ppgtt_invalidate(struct i915_address_space * const vm)
+{
+   struct i915_hw_ppgtt * const ppgtt = i915_vm_to_ppgtt(vm);
+
+   /* PDE TLBs are a pain to invalidate on GEN8+. When we modify
+* the page table structures, we mark them dirty so that
+* context switching/execlist queuing code takes extra steps
+* to ensure that tlbs are flushed.
+*/
+   ppgtt->pd_dirty_rings = INTEL_INFO(ppgtt->base.i915)->ring_mask;
+
+   /* Flush write combining buffer */
+   wmb();
+}
+
 static void gen6_ggtt_invalidate(struct drm_i915_private *dev_priv)
 {
/* Flush write combining buffer */
@@ -814,15 +829,6 @@ static int gen8_mm_switch_4lvl(struct i915_hw_ppgtt *ppgtt,
return gen8_write_pdp(rq, 0, px_dma(>pml4));
 }
 
-/* PDE TLBs are a pain to invalidate on GEN8+. When we modify
- * the page table structures, we mark them dirty so that
- * context switching/execlist queuing code takes extra steps
- * to ensure that tlbs are flushed.
- */
-static void mark_tlbs_dirty(struct i915_hw_ppgtt *ppgtt)
-{
-   ppgtt->pd_dirty_rings = INTEL_INFO(ppgtt->base.i915)->ring_mask;
-}
 
 /* Removes entries from a single page table, releasing it if it's empty.
  * Caller can use the return value to update higher-level entries.
@@ -1398,7 +1404,7 @@ static int gen8_ppgtt_alloc_pdp(struct i915_address_space 
*vm,
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
GEM_BUG_ON(pdp->used_pdpes > i915_pdpes_per_pdp(vm));
 
-   mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
+   gen6_ppgtt_invalidate(vm);
}
 
ret = gen8_ppgtt_alloc_pd(vm, pd, start, length);
@@ -1724,8 +1730,7 @@ static void gen6_write_page_range(struct i915_hw_ppgtt 
*ppgtt,
gen6_for_each_pde(pt, >pd, start, length, pde)
gen6_write_pde(ppgtt, pde, pt);
 
-   mark_tlbs_dirty(ppgtt);
-   wmb();
+   gen6_ppgtt_invalidate(>base);
 }
 
 static inline u32 get_pd_offset(struct i915_hw_ppgtt *ppgtt)
@@ -1939,10 +1944,8 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
}
}
 
-   if (flush) {
-   mark_tlbs_dirty(ppgtt);
-   wmb();
-   }
+   if (flush)
+   gen6_ppgtt_invalidate(vm);
 
return 0;
 
-- 
2.14.1

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


[Intel-gfx] [PATCH 1/5] drm/i915/gtt: Move wmb inside ggtt_invalidate

2018-05-07 Thread Mika Kuoppala
We use a pattern of wmb() along with ggtt_invalidate.
Move the wmb out from call sites into the ggtt_invalidate
as it is part of invalidation.

Cc: Chris Wilson 
Cc: Matthew Auld 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c879bfd9294f..2963d3d71729 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -110,6 +110,9 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma);
 
 static void gen6_ggtt_invalidate(struct drm_i915_private *dev_priv)
 {
+   /* Flush write combining buffer */
+   wmb();
+
/* Note that as an uncached mmio write, this should flush the
 * WCB of the writes into the GGTT before it triggers the invalidate.
 */
@@ -2418,8 +2421,6 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
for_each_sgt_dma(addr, sgt_iter, vma->pages)
gen8_set_pte(gtt_entries++, pte_encode | addr);
 
-   wmb();
-
/* This next bit makes the above posting read even more important. We
 * want to flush the TLBs only after we're certain all the PTE updates
 * have finished.
@@ -2460,7 +2461,6 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
dma_addr_t addr;
for_each_sgt_dma(addr, iter, vma->pages)
iowrite32(vm->pte_encode(addr, level, flags), [i++]);
-   wmb();
 
/* This next bit makes the above posting read even more important. We
 * want to flush the TLBs only after we're certain all the PTE updates
-- 
2.14.1

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


[Intel-gfx] [PATCH 3/5] drm/i915/gtt: Don't track dirty in gen6_alloc_va_range

2018-05-07 Thread Mika Kuoppala
gen6_alloc_va_range is only used to init the aliasing ppgtt, so
we can be certain that it will be dirty every time. No need
to track it.

Cc: Chris Wilson 
Cc: Matthew Auld 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b162617afe18..6434ebe8c033 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1929,7 +1929,6 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
struct i915_page_table *pt;
u64 from = start;
unsigned int pde;
-   bool flush = false;
 
gen6_for_each_pde(pt, >pd, start, length, pde) {
if (pt == vm->scratch_pt) {
@@ -1940,12 +1939,10 @@ static int gen6_alloc_va_range(struct 
i915_address_space *vm,
gen6_initialize_pt(vm, pt);
ppgtt->pd.page_table[pde] = pt;
gen6_write_pde(ppgtt, pde, pt);
-   flush = true;
}
}
 
-   if (flush)
-   gen6_ppgtt_invalidate(vm);
+   gen6_ppgtt_invalidate(vm);
 
return 0;
 
-- 
2.14.1

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


[Intel-gfx] [PATCH 4/5] drm/i915/gtt: Flush write combining buffer on insert entries

2018-05-07 Thread Mika Kuoppala
We could be using write combining map through which we insert
our ptes. Make sure to flush the write combining buffer
after the writes.

Cc: Chris Wilson 
Cc: Matthew Auld 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6434ebe8c033..dcac8bd604ab 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1077,6 +1077,9 @@ static void gen8_ppgtt_insert_3lvl(struct 
i915_address_space *vm,
  cache_level);
 
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
+
+   /* Flush write combining buffer */
+   wmb();
 }
 
 static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
@@ -1196,6 +1199,9 @@ static void gen8_ppgtt_insert_4lvl(struct 
i915_address_space *vm,
 
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
}
+
+   /* Flush write combining buffer */
+   wmb();
 }
 
 static void gen8_free_page_tables(struct i915_address_space *vm,
-- 
2.14.1

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


[Intel-gfx] [PATCH 5/5] drm/i915/gtt: Trust the uncached store to flush wcb

2018-05-07 Thread Mika Kuoppala
Not all architectures guarantee that uncached read will
flush the write combining buffer. So marking it explicitly
is recommended [1].

However we know the architecture we are operating on
and can avoid wmb as the UC store will flush the wcb [2].

Omit the wmb() on gen6_ppgtt_invalidate as redundant.

References: http://yarchive.net/comp/linux/write_combining.html [1]
References: http://download.intel.com/design/PentiumII/applnots/24442201.pdf [2]
Cc: Chris Wilson 
Cc: Matthew Auld 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index dcac8bd604ab..ef2727f4b6a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -125,10 +125,7 @@ static void gen6_ppgtt_invalidate(struct 
i915_address_space * const vm)
 
 static void gen6_ggtt_invalidate(struct drm_i915_private *dev_priv)
 {
-   /* Flush write combining buffer */
-   wmb();
-
-   /* Note that as an uncached mmio write, this should flush the
+   /* Note that as an uncached mmio write, this will flush the
 * WCB of the writes into the GGTT before it triggers the invalidate.
 */
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
-- 
2.14.1

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/7] drm/i915: Flush submission tasklet after 
bumping priority
URL   : https://patchwork.freedesktop.org/series/42815/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4151 -> Patchwork_8927 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42815/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8927 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@drv_module_reload@basic-no-display:
  fi-bsw-n3050:   DMESG-FAIL (fdo#106373) -> PASS

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128) -> PASS

igt@kms_chamelium@hdmi-hpd-fast:
  fi-kbl-7500u:   FAIL (fdo#102672, fdo#103841) -> SKIP

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-elk-e7500:   INCOMPLETE (fdo#103989) -> PASS

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cnl-psr: FAIL (fdo#103481) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106373 https://bugs.freedesktop.org/show_bug.cgi?id=106373


== Participating hosts (41 -> 37) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4151 -> Patchwork_8927

  CI_DRM_4151: 176975baca37c5cdb1632b9aa2ba0170c9ab53df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4464: 1bb318b32db003a377da14715c7b80675a712b6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8927: f11f14adf4e6010fc93ab44c0848ef846a522590 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4464: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

f11f14adf4e6 drm/i915: Speed up idle detection by kicking the tasklets
cc4737fd06e9 drm/i915/execlists: Direct submission from irq handler
4fa5bf4dcf57 drm/i915/execlists: Direct submit onto idle engines
9c06e59f519a drm/i915/guc: Make submission tasklet hardirq safe
73b5184f0846 drm/i915/execlists: Make submission tasklet hardirq safe
a4169738 drm/i915: Disable tasklet scheduling across initial scheduling
8cef3a53edbb drm/i915: Flush submission tasklet after bumping priority

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8927/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/7] drm/i915: Flush submission tasklet after 
bumping priority
URL   : https://patchwork.freedesktop.org/series/42815/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Flush submission tasklet after bumping priority
Okay!

Commit: drm/i915: Disable tasklet scheduling across initial scheduling
Okay!

Commit: drm/i915/execlists: Make submission tasklet hardirq safe
Okay!

Commit: drm/i915/guc: Make submission tasklet hardirq safe
Okay!

Commit: drm/i915/execlists: Direct submit onto idle engines
+drivers/gpu/drm/i915/intel_guc_submission.c:770:28: warning: context imbalance 
in 'guc_dequeue' - unexpected unlock
+drivers/gpu/drm/i915/intel_lrc.c:369:39: warning: context imbalance in 
'execlists_unwind_incomplete_requests' - unexpected unlock
+drivers/gpu/drm/i915/intel_lrc.c:776:39: warning: context imbalance in 
'execlists_dequeue' - unexpected unlock
-O:drivers/gpu/drm/i915/intel_ringbuffer.h:651:23: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_ringbuffer.h:651:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_ringbuffer.h:658:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_ringbuffer.h:658:23: warning: expression using 
sizeof(void)

Commit: drm/i915/execlists: Direct submission from irq handler
Okay!

Commit: drm/i915: Speed up idle detection by kicking the tasklets
Okay!

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/7] drm/i915: Flush submission tasklet after 
bumping priority
URL   : https://patchwork.freedesktop.org/series/42815/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8cef3a53edbb drm/i915: Flush submission tasklet after bumping priority
a4169738 drm/i915: Disable tasklet scheduling across initial scheduling
73b5184f0846 drm/i915/execlists: Make submission tasklet hardirq safe
9c06e59f519a drm/i915/guc: Make submission tasklet hardirq safe
4fa5bf4dcf57 drm/i915/execlists: Direct submit onto idle engines
-:28: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should 
also have an identifier name
#28: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:757:
+   unsigned long uninitialized_var(flags);

-:56: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should 
also have an identifier name
#56: FILE: drivers/gpu/drm/i915/intel_lrc.c:360:
+   unsigned long uninitialized_var(flags);

-:85: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should 
also have an identifier name
#85: FILE: drivers/gpu/drm/i915/intel_lrc.c:766:
+   unsigned long uninitialized_var(flags);

total: 0 errors, 3 warnings, 0 checks, 160 lines checked
cc4737fd06e9 drm/i915/execlists: Direct submission from irq handler
f11f14adf4e6 drm/i915: Speed up idle detection by kicking the tasklets

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


Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

2018-05-07 Thread Feng Tang
On Mon, May 07, 2018 at 05:09:21PM +0200, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote:
> > Quoting Feng Tang (2018-05-07 22:26:34)
> > > Hi Chris,
> > > 
> > > Thanks for the prompt review!
> > > 
> > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
> > > > Quoting Feng Tang (2018-05-07 11:36:09)
> > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
> > > > > from 7 to 32, which may hurt the boot/init time for some platforms,
> > > > > as the 32 retries may take hundreds of ms.
> > > > 
> > > > If we need that many retries, so be it. No modparam, the driver just has
> > > > to work.
> > > 
> > > I understand your point. The retry numer was originally 7, and worked
> > > fine untill the Dell 4K monitor which changes to 32.  According to my 
> > > test,
> > > each retry will take about 8ms on the A3960 based NUC.
> > > 
> > > One of our product need to boot up within a given time limit, this
> > > 32 retries will take about 1/3 of the budget (about 270ms), that's
> > > why I would try to make it a parameter.
> > 
> > The essence is that probing whether a monitor is connected should not be
> > blocking boot. If an async probe tries and fails to find a monitor,
> > fine - no one will notice. If it does take 270ms to find a monitor, it
> > turns on 200ms after userspace kicks in, just like any other hotplug.
> 
> Yeah, the fix here is to get the probing out of the driver load path, not
> to break the driver for some funky monitors. And definitely not using a
> modparam.

Thank you both for the suggestion! 

Will try to make the probing async first, though I'm not familiar with the
whole drm yet :)

- Feng

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


[Intel-gfx] ✓ Fi.CI.IGT: success for Enabling content-type setting for HDMI displays. (rev8)

2018-05-07 Thread Patchwork
== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev8)
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4150_full -> Patchwork_8926_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8926_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8926_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41876/revisions/8/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8926_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-render:
  shard-kbl:  SKIP -> PASS +1

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_8926_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_contexts:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_flip@2x-dpms-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103928) +1


 Possible fixes 

igt@gem_eio@in-flight-suspend:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-kbl:  FAIL (fdo#100368) -> PASS

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_flip@plain-flip-fb-recreate:
  shard-glk:  FAIL (fdo#100368) -> PASS +2

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +13

igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
  shard-apl:  FAIL (fdo#103166, fdo#104724) -> PASS

igt@kms_rotation_crc@primary-rotation-90:
  shard-apl:  FAIL (fdo#104724, fdo#103925) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602


== Participating hosts (6 -> 6) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4150 -> Patchwork_8926

  CI_DRM_4150: 93d32416ba4b1dae9451fec28aaa71915d770f51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4463: 91b5a3ef5516b29584ea4567b0f5ffa18219b29f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8926: 279113b4c78fe777697aaeb801ec4aeb407b56f4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4463: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8926/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

2018-05-07 Thread Daniel Vetter
On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote:
> Quoting Feng Tang (2018-05-07 22:26:34)
> > Hi Chris,
> > 
> > Thanks for the prompt review!
> > 
> > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
> > > Quoting Feng Tang (2018-05-07 11:36:09)
> > > > To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
> > > > from 7 to 32, which may hurt the boot/init time for some platforms,
> > > > as the 32 retries may take hundreds of ms.
> > > 
> > > If we need that many retries, so be it. No modparam, the driver just has
> > > to work.
> > 
> > I understand your point. The retry numer was originally 7, and worked
> > fine untill the Dell 4K monitor which changes to 32.  According to my test,
> > each retry will take about 8ms on the A3960 based NUC.
> > 
> > One of our product need to boot up within a given time limit, this
> > 32 retries will take about 1/3 of the budget (about 270ms), that's
> > why I would try to make it a parameter.
> 
> The essence is that probing whether a monitor is connected should not be
> blocking boot. If an async probe tries and fails to find a monitor,
> fine - no one will notice. If it does take 270ms to find a monitor, it
> turns on 200ms after userspace kicks in, just like any other hotplug.

Yeah, the fix here is to get the probing out of the driver load path, not
to break the driver for some funky monitors. And definitely not using a
modparam.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Add documentation to gen9_set_dc_state()

2018-05-07 Thread Imre Deak
On Tue, Apr 17, 2018 at 02:31:47PM +0300, Imre Deak wrote:
> Add documentation to gen9_set_dc_state() on what enabling a given DC
> state means and at what point HW/DMC actually enters/exits these states.
> 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Signed-off-by: Imre Deak 

Pushed to -dinq, thanks for the review, comments.

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> [ On IRC I stated that PSR entry would be prevented in a given DC state,
>   but looking more at it I haven't found any proof for this. So as I
>   understand the only connection between PSR and DC states is that if
>   DC5/6 is disabled power saving will be blocked, which would otherwise
>   be possible when PSR is active and the display pipe is off. ]
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 53ea564f971e..40a7955886d4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private 
> *dev_priv)
>   dev_priv->csr.dc_state = val;
>  }
>  
> +/**
> + * gen9_set_dc_state - set target display C power state
> + * @dev_priv: i915 device instance
> + * @state: target DC power state
> + * - DC_STATE_DISABLE
> + * - DC_STATE_EN_UPTO_DC5
> + * - DC_STATE_EN_UPTO_DC6
> + * - DC_STATE_EN_DC9
> + *
> + * Signal to DMC firmware/HW the target DC power state passed in @state.
> + * DMC/HW can turn off individual display clocks and power rails when 
> entering
> + * a deeper DC power state (higher in number) and turns these back when 
> exiting
> + * that state to a shallower power state (lower in number). The HW will 
> decide
> + * when to actually enter a given state on an on-demand basis, for instance
> + * depending on the active state of display pipes. The state of display
> + * registers backed by affected power rails are saved/restored as needed.
> + *
> + * Based on the above enabling a deeper DC power state is asynchronous wrt.
> + * enabling it. Disabling a deeper power state is synchronous: for instance
> + * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
> + * back on and register state is restored. This is guaranteed by the MMIO 
> write
> + * to DC_STATE_EN blocking until the state is restored.
> + */
>  static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t 
> state)
>  {
>   uint32_t val;
> -- 
> 2.13.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3] drm/i915: Speed up idle detection by kicking the tasklets

2018-05-07 Thread kbuild test robot
Hi Chris,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.17-rc4 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Speed-up-idle-detection-by-kicking-the-tasklets/20180507-184057
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x0-05071422 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/intel_engine_cs.c: In function 'intel_engine_is_idle':
>> drivers/gpu//drm/i915/intel_engine_cs.c:954:3: error: implicit declaration 
>> of function 'execlists_tasklet' [-Werror=implicit-function-declaration]
  execlists_tasklet(>execlists);
  ^
   cc1: some warnings being treated as errors

vim +/execlists_tasklet +954 drivers/gpu//drm/i915/intel_engine_cs.c

   923  
   924  /**
   925   * intel_engine_is_idle() - Report if the engine has finished process 
all work
   926   * @engine: the intel_engine_cs
   927   *
   928   * Return true if there are no requests pending, nothing left to be 
submitted
   929   * to hardware, and that the engine is idle.
   930   */
   931  bool intel_engine_is_idle(struct intel_engine_cs *engine)
   932  {
   933  struct drm_i915_private *dev_priv = engine->i915;
   934  
   935  /* More white lies, if wedged, hw state is inconsistent */
   936  if (i915_terminally_wedged(_priv->gpu_error))
   937  return true;
   938  
   939  /* Any inflight/incomplete requests? */
   940  if (!i915_seqno_passed(intel_engine_get_seqno(engine),
   941 intel_engine_last_submit(engine)))
   942  return false;
   943  
   944  if (I915_SELFTEST_ONLY(engine->breadcrumbs.mock))
   945  return true;
   946  
   947  /*
   948   * ksoftirqd has notorious latency that may cause us to
   949   * timeout while waiting for the engine to idle as we wait for
   950   * ksoftirqd to run the execlists tasklet to drain the ELSP.
   951   * If we are expecting a context switch from the GPU, check now.
   952   */
   953  if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
 > 954  execlists_tasklet(>execlists);
   955  
   956  /* Waiting to drain ELSP? */
   957  if (READ_ONCE(engine->execlists.active))
   958  return false;
   959  
   960  /* ELSP is empty, but there are ready requests? E.g. after 
reset */
   961  if (READ_ONCE(engine->execlists.first))
   962  return false;
   963  
   964  /* Ring stopped? */
   965  if (!ring_is_idle(engine))
   966  return false;
   967  
   968  return true;
   969  }
   970  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v9 1/2] drm: content-type property for HDMI connector

2018-05-07 Thread Daniel Vetter
On Mon, May 07, 2018 at 04:16:40PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
> 
> v2:
>  * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
> 
> v3:
>  * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
> 
> v4:
>  * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
> 
> v5:
>  * Moved patch revision's description to commit messages.
> 
> v6:
>  * Minor naming fix for the content type enumeration string.
> 
> v7:
>  * Fix parameter name for documentation and parameter alignment
>in order not to get warning. Added Content Type description to
>new HDMI connector properties section.
> 
> v8:
>  * Thrown away unneeded numbers from HDMI content-type property
>description. Switch to strings desription instead of plain
>definitions.
> 
> v9:
>  * Moved away hdmi specific content-type enum from
>drm_connector_state. Content type property should probably not
>be bound to any specific connector interface in
>drm_connector_state.
>Same probably should be done to hdmi_picture_aspect_ration enum
>which is also contained in drm_connector_state. Added special
>helper function to get derive hdmi specific relevant infoframe
>fields.
> 
> Signed-off-by: Stanislav Lisovskiy 

> ---
>  Documentation/gpu/drm-kms.rst|  6 +++
>  Documentation/gpu/kms-properties.csv |  1 +
>  drivers/gpu/drm/drm_atomic.c |  4 ++
>  drivers/gpu/drm/drm_connector.c  | 74 
>  drivers/gpu/drm/drm_edid.c   | 55 +
>  include/drm/drm_connector.h  | 12 +
>  include/drm/drm_edid.h   |  6 +++
>  include/drm/drm_mode_config.h|  5 ++
>  include/uapi/drm/drm_mode.h  |  7 +++
>  9 files changed, 170 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 1dffd1ac4cd4..e233c2626bd0 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -517,6 +517,12 @@ Standard Connector Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :doc: standard connector properties
>  
> +HDMI Specific Connector Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> +   :doc: HDMI connector properties
> +
>  Plane Composition Properties
>  
>  
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 07ed22ea3bd6..bfde04eddd14 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> Values,Object attached,De
>  ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property 
> to suggest an X offset for a connector
>  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest 
> an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", 
> ""Cinema"", ""Game"" }",Connector,TBD
>  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
> set, the hardware will be programmed with the result of the multiplication of 
> CTM by the limited range matrix to ensure the pixels normaly in the range 
> 0..1.0 are remapped to the range 16/255..235/255."
>  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
>  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3d9ae057a6cd..6c1e1e774517 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1270,6 +1270,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->link_status = val;
>   } else if (property == config->aspect_ratio_property) {
>   state->picture_aspect_ratio = val;
> + } else if (property == config->content_type_property) {
> + state->content_type = val;
>   } else if (property == 

[Intel-gfx] [PATCH v2 4/7] drm/i915/guc: Make submission tasklet hardirq safe

2018-05-07 Thread Chris Wilson
Prepare to allow the GuC submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets and context switches.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 34 +++--
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 62828e39ee26..2feb65096966 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -669,7 +669,7 @@ static inline int port_prio(const struct execlist_port 
*port)
return rq_prio(port_request(port));
 }
 
-static void guc_dequeue(struct intel_engine_cs *engine)
+static bool __guc_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
@@ -679,7 +679,8 @@ static void guc_dequeue(struct intel_engine_cs *engine)
bool submit = false;
struct rb_node *rb;
 
-   spin_lock_irq(>timeline.lock);
+   lockdep_assert_held(>timeline.lock);
+
rb = execlists->first;
GEM_BUG_ON(rb_first(>queue) != rb);
 
@@ -694,13 +695,13 @@ static void guc_dequeue(struct intel_engine_cs *engine)
 EXECLISTS_ACTIVE_PREEMPT);
queue_work(engine->i915->guc.preempt_wq,
   _work->work);
-   goto unlock;
+   return false;
}
}
 
port++;
if (port_isset(port))
-   goto unlock;
+   return false;
}
GEM_BUG_ON(port_isset(port));
 
@@ -738,19 +739,34 @@ static void guc_dequeue(struct intel_engine_cs *engine)
 done:
execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
execlists->first = rb;
-   if (submit) {
+   if (submit)
port_assign(port, last);
+   if (last)
execlists_user_begin(execlists, execlists->port);
-   guc_submit(engine);
-   }
 
/* We must always keep the beast fed if we have work piled up */
GEM_BUG_ON(port_isset(execlists->port) &&
   !execlists_is_active(execlists, EXECLISTS_ACTIVE_USER));
GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
 
-unlock:
-   spin_unlock_irq(>timeline.lock);
+   return submit;
+}
+
+static void guc_dequeue(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+   bool submit;
+
+   local_irq_save(flags);
+
+   spin_lock(>timeline.lock);
+   submit = __guc_dequeue(engine);
+   spin_unlock(>timeline.lock);
+
+   if (submit)
+   guc_submit(engine);
+
+   local_irq_restore(flags);
 }
 
 static void guc_submission_tasklet(unsigned long data)
-- 
2.17.0

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


[Intel-gfx] [PATCH v2 7/7] drm/i915: Speed up idle detection by kicking the tasklets

2018-05-07 Thread Chris Wilson
We rely on ksoftirqd to run in a timely fashion in order to drain the
execlists queue. Quite frequently, it does not. In some cases we may see
latencies of over 200ms triggering our idle timeouts and forcing us to
declare the driver wedged!

Thus we can speed up idle detection by bypassing ksoftirqd in these
cases and flush our tasklet to confirm if we are indeed still waiting
for the ELSP to drain.

v2: Put the execlists.first check back; it is required for handling
reset!
v3: Follow Mika's suggestion to try and limit kicking the tasklet to
only when we expect it to make a difference, i.e. in catch up after a CS
interrupt, and not just execute it everytime as that is likely just to
cover over our own bugs.

References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 70325e0824e3..27f6b30e032f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -944,11 +944,20 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (I915_SELFTEST_ONLY(engine->breadcrumbs.mock))
return true;
 
+   /*
+* ksoftirqd has notorious latency that may cause us to
+* timeout while waiting for the engine to idle as we wait for
+* ksoftirqd to run the execlists tasklet to drain the ELSP.
+* If we are expecting a context switch from the GPU, check now.
+*/
+   if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
+   execlists_tasklet(>execlists);
+
/* Waiting to drain ELSP? */
if (READ_ONCE(engine->execlists.active))
return false;
 
-   /* ELSP is empty, but there are ready requests? */
+   /* ELSP is empty, but there are ready requests? E.g. after reset */
if (READ_ONCE(engine->execlists.first))
return false;
 
-- 
2.17.0

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


[Intel-gfx] [PATCH v2 5/7] drm/i915/execlists: Direct submit onto idle engines

2018-05-07 Thread Chris Wilson
Bypass using the tasklet to submit the first request to HW, as the
tasklet may be deferred unto ksoftirqd and at a minimum will add in
excess of 10us (and maybe tens of milliseconds) to our execution
latency. This latency reduction is most notable when execution flows
between engines.

v2: Beware handling preemption completion from the direct submit path as
well.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 12 +++-
 drivers/gpu/drm/i915/intel_lrc.c| 66 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  7 +++
 3 files changed, 69 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 2feb65096966..6bfe30af7826 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -754,14 +754,20 @@ static bool __guc_dequeue(struct intel_engine_cs *engine)
 
 static void guc_dequeue(struct intel_engine_cs *engine)
 {
-   unsigned long flags;
+   unsigned long uninitialized_var(flags);
bool submit;
 
local_irq_save(flags);
 
-   spin_lock(>timeline.lock);
+   GEM_BUG_ON(!test_bit(TASKLET_STATE_RUN,
+>execlists.tasklet.state));
+   if (!intel_engine_direct_submit(engine))
+   spin_lock(>timeline.lock);
+
submit = __guc_dequeue(engine);
-   spin_unlock(>timeline.lock);
+
+   if (!intel_engine_direct_submit(engine))
+   spin_unlock(>timeline.lock);
 
if (submit)
guc_submit(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 15c373ea5b7e..ac7c5edee4ee 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -357,13 +357,16 @@ execlists_unwind_incomplete_requests(struct 
intel_engine_execlists *execlists)
 {
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
-   unsigned long flags;
+   unsigned long uninitialized_var(flags);
 
-   spin_lock_irqsave(>timeline.lock, flags);
+   GEM_BUG_ON(!test_bit(TASKLET_STATE_RUN, >tasklet.state));
+   if (!intel_engine_direct_submit(engine))
+   spin_lock_irqsave(>timeline.lock, flags);
 
__unwind_incomplete_requests(engine);
 
-   spin_unlock_irqrestore(>timeline.lock, flags);
+   if (!intel_engine_direct_submit(engine))
+   spin_unlock_irqrestore(>timeline.lock, flags);
 }
 
 static inline void
@@ -602,6 +605,8 @@ static bool __execlists_dequeue(struct intel_engine_cs 
*engine)
 */
GEM_BUG_ON(!execlists_is_active(execlists,
EXECLISTS_ACTIVE_USER));
+   GEM_BUG_ON(execlists_is_active(execlists,
+  EXECLISTS_ACTIVE_PREEMPT));
GEM_BUG_ON(!port_count([0]));
if (port_count([0]) > 1)
return false;
@@ -758,12 +763,17 @@ static bool __execlists_dequeue(struct intel_engine_cs 
*engine)
 static void execlists_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
-   unsigned long flags;
+   unsigned long uninitialized_var(flags);
bool submit;
 
-   spin_lock_irqsave(>timeline.lock, flags);
+   GEM_BUG_ON(!test_bit(TASKLET_STATE_RUN, >tasklet.state));
+   if (!intel_engine_direct_submit(engine))
+   spin_lock_irqsave(>timeline.lock, flags);
+
submit = __execlists_dequeue(engine);
-   spin_unlock_irqrestore(>timeline.lock, flags);
+
+   if (!intel_engine_direct_submit(engine))
+   spin_unlock_irqrestore(>timeline.lock, flags);
 
if (submit)
execlists_submit_ports(engine);
@@ -1163,16 +1173,45 @@ static void queue_request(struct intel_engine_cs 
*engine,
  _priolist(engine, node, prio)->requests);
 }
 
-static void __submit_queue(struct intel_engine_cs *engine, int prio)
+static void __wakeup_queue(struct intel_engine_cs *engine, int prio)
 {
engine->execlists.queue_priority = prio;
+}
+
+static void __schedule_queue(struct intel_engine_cs *engine)
+{
tasklet_hi_schedule(>execlists.tasklet);
 }
 
+static void __submit_queue(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+   struct tasklet_struct * const t = >tasklet;
+
+   GEM_BUG_ON(!engine->i915->gt.awake);
+
+   /* If inside GPU reset, the tasklet will be queued later. */
+   if (unlikely(atomic_read(>count)))
+   return;
+
+   /* Directly submit the first request to reduce the initial latency */
+   if (!port_isset(execlists->port) && 

[Intel-gfx] [PATCH v2 2/7] drm/i915: Disable tasklet scheduling across initial scheduling

2018-05-07 Thread Chris Wilson
During request submission, we call the engine->schedule() function so
that we may reorder the active requests as required for inheriting the
new request's priority. This may schedule several tasklets to run on the
local CPU, but we will need to schedule the tasklets again for the new
request. Delay all the local tasklets until the end, so that we only
have to process the queue just once.

v2: Beware PREEMPT_RCU, as then local_bh_disable() is then not a
superset of rcu_read_lock().

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_request.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index e4cf76ec14a6..f336942229cf 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1110,12 +1110,11 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
 * decide whether to preempt the entire chain so that it is ready to
 * run at the earliest possible convenience.
 */
-   rcu_read_lock();
+   local_bh_disable();
+   rcu_read_lock(); /* RCU serialisation for set-wedged protection */
if (engine->schedule)
engine->schedule(request, >ctx->sched);
rcu_read_unlock();
-
-   local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
 
-- 
2.17.0

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


[Intel-gfx] [PATCH v2 3/7] drm/i915/execlists: Make submission tasklet hardirq safe

2018-05-07 Thread Chris Wilson
Prepare to allow the execlists submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets and context switches.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 42 ++--
 1 file changed, 29 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f9f4064dec0e..15c373ea5b7e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -357,10 +357,13 @@ execlists_unwind_incomplete_requests(struct 
intel_engine_execlists *execlists)
 {
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
+   unsigned long flags;
+
+   spin_lock_irqsave(>timeline.lock, flags);
 
-   spin_lock_irq(>timeline.lock);
__unwind_incomplete_requests(engine);
-   spin_unlock_irq(>timeline.lock);
+
+   spin_unlock_irqrestore(>timeline.lock, flags);
 }
 
 static inline void
@@ -554,7 +557,7 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
 }
 
-static void execlists_dequeue(struct intel_engine_cs *engine)
+static bool __execlists_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
@@ -564,6 +567,8 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
struct rb_node *rb;
bool submit = false;
 
+   lockdep_assert_held(>timeline.lock);
+
/* Hardware submission is through 2 ports. Conceptually each port
 * has a (RING_START, RING_HEAD, RING_TAIL) tuple. RING_START is
 * static for a context, and unique to each, so we only execute
@@ -585,7 +590,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * and context switches) submission.
 */
 
-   spin_lock_irq(>timeline.lock);
rb = execlists->first;
GEM_BUG_ON(rb_first(>queue) != rb);
 
@@ -600,7 +604,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
EXECLISTS_ACTIVE_USER));
GEM_BUG_ON(!port_count([0]));
if (port_count([0]) > 1)
-   goto unlock;
+   return false;
 
/*
 * If we write to ELSP a second time before the HW has had
@@ -610,11 +614,11 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * the HW to indicate that it has had a chance to respond.
 */
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_HWACK))
-   goto unlock;
+   return false;
 
if (need_preempt(engine, last, execlists->queue_priority)) {
inject_preempt_context(engine);
-   goto unlock;
+   return false;
}
 
/*
@@ -639,7 +643,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * priorities of the ports haven't been switch.
 */
if (port_count([1]))
-   goto unlock;
+   return false;
 
/*
 * WaIdleLiteRestore:bdw,skl
@@ -744,13 +748,25 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
/* We must always keep the beast fed if we have work piled up */
GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
 
-unlock:
-   spin_unlock_irq(>timeline.lock);
-
-   if (submit) {
+   /* Re-evaluate the executing context setup after each preemptive kick */
+   if (last)
execlists_user_begin(execlists, execlists->port);
+
+   return submit;
+}
+
+static void execlists_dequeue(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+   unsigned long flags;
+   bool submit;
+
+   spin_lock_irqsave(>timeline.lock, flags);
+   submit = __execlists_dequeue(engine);
+   spin_unlock_irqrestore(>timeline.lock, flags);
+
+   if (submit)
execlists_submit_ports(engine);
-   }
 
GEM_BUG_ON(port_isset(execlists->port) &&
   !execlists_is_active(execlists, EXECLISTS_ACTIVE_USER));
-- 
2.17.0

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


[Intel-gfx] [PATCH v2 6/7] drm/i915/execlists: Direct submission from irq handler

2018-05-07 Thread Chris Wilson
Continuing the themem of bypassing ksoftirqd latency, also first try to
directly submit from the CS interrupt handler to clear the ELSP and
queue the next.

In the past, we have been hesitant to do this as the context switch
processing has been quite heavy, requiring forcewaked mmio. However, as
we now can read the GPU state from the cacheable HWSP, it is relatively
cheap!

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c | 13 ++---
 drivers/gpu/drm/i915/intel_guc_submission.c |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 16 
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f9bc3aaa90d0..775cf167d938 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1465,19 +1465,18 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir)
struct intel_engine_execlists * const execlists = >execlists;
bool tasklet = false;
 
-   if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
-   if (READ_ONCE(engine->execlists.active))
-   tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
-   >irq_posted);
-   }
+   if (iir & GT_CONTEXT_SWITCH_INTERRUPT && READ_ONCE(execlists->active))
+   tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
+   >irq_posted);
 
if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
-   tasklet |= USES_GUC_SUBMISSION(engine->i915);
+   if (!test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
+   tasklet = USES_GUC_SUBMISSION(engine->i915);
}
 
if (tasklet)
-   tasklet_hi_schedule(>tasklet);
+   execlists_tasklet(execlists);
 }
 
 static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 6bfe30af7826..7d4542b46f5e 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -782,6 +782,8 @@ static void guc_submission_tasklet(unsigned long data)
struct execlist_port *port = execlists->port;
struct i915_request *rq;
 
+   clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+
rq = port_request(port);
while (rq && i915_request_completed(rq)) {
trace_i915_request_out(rq);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index f5545391d76a..da7e00ff2c6b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -717,6 +717,22 @@ execlists_port_complete(struct intel_engine_execlists * 
const execlists,
return port;
 }
 
+static inline void
+execlists_tasklet(struct intel_engine_execlists * const execlists)
+{
+   struct tasklet_struct * const t = >tasklet;
+
+   if (unlikely(atomic_read(>count))) /* GPU reset active */
+   return;
+
+   if (tasklet_trylock(t)) {
+   t->func(t->data);
+   tasklet_unlock(t);
+   } else {
+   tasklet_hi_schedule(t);
+   }
+}
+
 static inline unsigned int
 intel_engine_flag(const struct intel_engine_cs *engine)
 {
-- 
2.17.0

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


[Intel-gfx] [PATCH v2 1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Chris Wilson
When called from process context tasklet_schedule() defers itself to
ksoftirqd. From experience this may cause unacceptable latencies of over
200ms in executing the submission tasklet, our goal is to reprioritise
the HW execution queue and trigger HW preemption immediately, so disable
bh over the call to schedule and force the tasklet to run afterwards if
scheduled.

v2: Keep rcu_read_lock() around for PREEMPT_RCU

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5ece6ae4bdff..89bf5d67cb74 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -578,10 +578,12 @@ static void __fence_set_priority(struct dma_fence *fence,
rq = to_request(fence);
engine = rq->engine;
 
-   rcu_read_lock();
+   local_bh_disable();
+   rcu_read_lock(); /* RCU serialisation for set-wedged protection */
if (engine->schedule)
engine->schedule(rq, attr);
rcu_read_unlock();
+   local_bh_enable(); /* kick the tasklets if queues were reprioritised */
 }
 
 static void fence_set_priority(struct dma_fence *fence,
-- 
2.17.0

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Enabling content-type setting for HDMI displays. (rev8)

2018-05-07 Thread Patchwork
== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev8)
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4150 -> Patchwork_8926 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41876/revisions/8/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8926 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-skl-guc: PASS -> FAIL (fdo#105900, fdo#104699) +1

igt@gem_ringfill@basic-default-hang:
  fi-pnv-d510:NOTRUN -> DMESG-WARN (fdo#101600)


 Possible fixes 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-skl-guc: FAIL (fdo#103928) -> PASS

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   DMESG-FAIL (fdo#102614, fdo#106103) -> PASS

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-skl-6700k2:  FAIL (fdo#103191, fdo#104724) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-glk-j4005:   DMESG-WARN (fdo#106097) -> PASS


  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104699 https://bugs.freedesktop.org/show_bug.cgi?id=104699
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103


== Participating hosts (38 -> 37) ==

  Additional (2): fi-kbl-7560u fi-pnv-d510 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4150 -> Patchwork_8926

  CI_DRM_4150: 93d32416ba4b1dae9451fec28aaa71915d770f51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4463: 91b5a3ef5516b29584ea4567b0f5ffa18219b29f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8926: 279113b4c78fe777697aaeb801ec4aeb407b56f4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4463: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

279113b4c78f i915: content-type property for HDMI connector
fbbcc8d1f453 drm: content-type property for HDMI connector

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8926/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enabling content-type setting for HDMI displays. (rev8)

2018-05-07 Thread Patchwork
== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev8)
URL   : https://patchwork.freedesktop.org/series/41876/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
fbbcc8d1f453 drm: content-type property for HDMI connector
-:129: CHECK:LINE_SPACING: Please don't use multiple blank lines
#129: FILE: drivers/gpu/drm/drm_connector.c:1007:
 
+

-:195: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"!dev->mode_config.content_type_property"
#195: FILE: drivers/gpu/drm/drm_connector.c:1330:
+   if (dev->mode_config.content_type_property == NULL)

-:274: CHECK:LINE_SPACING: Please don't use multiple blank lines
#274: FILE: drivers/gpu/drm/drm_edid.c:4936:
+
+

-:286: CHECK:LINE_SPACING: Please don't use multiple blank lines
#286: FILE: include/drm/drm_connector.h:421:
 
+

-:295: CHECK:LINE_SPACING: Please don't use multiple blank lines
#295: FILE: include/drm/drm_connector.h:430:
+
+

total: 0 errors, 0 warnings, 5 checks, 259 lines checked
279113b4c78f i915: content-type property for HDMI connector
-:79: CHECK:LINE_SPACING: Please don't use multiple blank lines
#79: FILE: drivers/gpu/drm/i915/intel_hdmi.c:463:
 
+

total: 0 errors, 0 warnings, 1 checks, 86 lines checked

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


Re: [Intel-gfx] [PATCH v13 08/10] drm: Expose modes with aspect ratio, only if requested

2018-05-07 Thread Daniel Vetter
On Fri, May 04, 2018 at 11:19:45PM +0300, Ville Syrjälä wrote:
> On Thu, May 03, 2018 at 08:26:26AM +0200, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 12:20:20PM +0530, Nautiyal, Ankit K wrote:
> > > From: Ankit Nautiyal 
> > > 
> > > We parse the EDID and add all the modes in the connector's modelist.
> > > This adds CEA modes with aspect ratio information too, regardless of
> > > whether user space requested this information or not.
> > > 
> > > This patch:
> > > -prunes the modes with aspect-ratio information, from a
> > >  connector's modelist, if the user-space has not set the aspect ratio
> > >  DRM client cap. However if such a mode is unique in the list, it is
> > >  kept in the list, with aspect-ratio flags reset.
> > > -prepares a list of exposed modes, which is used to find unique modes
> > >  if aspect-ratio is not allowed.
> > > -adds a new list_head 'exposed_head' in drm_mode_display, to traverse
> > >  the list of exposed modes.
> > > 
> > > Cc: Ville Syrjala 
> > > Cc: Shashank Sharma 
> > > Cc: Jose Abreu 
> > > 
> > > Signed-off-by: Ankit Nautiyal 
> > > 
> > > V3: As suggested by Ville, modified the mechanism of pruning of modes
> > > with aspect-ratio, if the aspect-ratio is not supported. Instead
> > > of straight away pruning such a mode, the mode is retained with
> > > aspect ratio bits set to zero, provided it is unique.
> > > V4: rebase
> > > V5: Addressed review comments from Ville:
> > > -used a pointer to store last valid mode.
> > > -avoided, modifying of picture_aspect_ratio in kernel mode,
> > >  instead only flags bits of user mode are reset (if aspect-ratio
> > >  is not supported).
> > > V6: As suggested by Ville, corrected the mode pruning logic and
> > > elaborated the mode pruning logic and the assumptions taken.
> > > V7: rebase
> > > V8: rebase
> > > V9: rebase
> > > V10: rebase
> > > V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
> > >  logic to correctly identify and prune modes with aspect-ratio,
> > >  if aspect-ratio cap is not set.
> > > V12: As suggested by Ville, added another list_head in
> > >  drm_mode_display to traverse the list of exposed modes and
> > >  avoided duplication of modes.
> > > V13: Minor modifications, as suggested by Ville.
> > > ---
> > >  drivers/gpu/drm/drm_connector.c | 45 
> > > ++---
> > >  include/drm/drm_modes.h | 13 
> > >  2 files changed, 51 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_connector.c 
> > > b/drivers/gpu/drm/drm_connector.c
> > > index dfc8ca1..8ca1149 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -1531,15 +1531,36 @@ static struct drm_encoder 
> > > *drm_connector_get_encoder(struct drm_connector *conne
> > >   return connector->encoder;
> > >  }
> > >  
> > > -static bool drm_mode_expose_to_userspace(const struct drm_display_mode 
> > > *mode,
> > > -  const struct drm_file *file_priv)
> > > +static bool
> > > +drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
> > > +  const struct list_head *export_list,
> > > +  const struct drm_file *file_priv)
> > >  {
> > >   /*
> > >* If user-space hasn't configured the driver to expose the stereo 3D
> > >* modes, don't expose them.
> > >*/
> > > +
> > >   if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
> > >   return false;
> > > + /*
> > > +  * If user-space hasn't configured the driver to expose the modes
> > > +  * with aspect-ratio, don't expose them. However if such a mode
> > > +  * is unique, let it be exposed, but reset the aspect-ratio flags
> > > +  * while preparing the list of user-modes.
> > > +  */
> > > + if (!file_priv->aspect_ratio_allowed &&
> > > + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
> > > + struct drm_display_mode *mode_itr;
> > > +
> > > + list_for_each_entry(mode_itr, export_list, export_head)
> > 
> > By walking the list of only the modes already added to the export list we
> > rely on ASPECT_NONE being first if present. That seems to be a bit
> > fragile. If we instead walk over all present modes (i.e. connector->modes)
> > then I think that's avoided.
> 
> I don't think that would work. If we just walk over all the modes then
> wouldn't we always find a duplicate when the same mode with two different
> aspect ratios is on the list? And then we'd export neither? Or maybe I
> misunderstood what you mean here.

We'd export both. Let's assume we have 2 modes, only difference is aspect
ratio.

1. We check the first mode, it has aspect_ratio != NONE. But because
there's no other exported mode yet on export_list, we export it (and
filter out 

Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

2018-05-07 Thread Chris Wilson
Quoting Feng Tang (2018-05-07 22:26:34)
> Hi Chris,
> 
> Thanks for the prompt review!
> 
> On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
> > Quoting Feng Tang (2018-05-07 11:36:09)
> > > To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
> > > from 7 to 32, which may hurt the boot/init time for some platforms,
> > > as the 32 retries may take hundreds of ms.
> > 
> > If we need that many retries, so be it. No modparam, the driver just has
> > to work.
> 
> I understand your point. The retry numer was originally 7, and worked
> fine untill the Dell 4K monitor which changes to 32.  According to my test,
> each retry will take about 8ms on the A3960 based NUC.
> 
> One of our product need to boot up within a given time limit, this
> 32 retries will take about 1/3 of the budget (about 270ms), that's
> why I would try to make it a parameter.

The essence is that probing whether a monitor is connected should not be
blocking boot. If an async probe tries and fails to find a monitor,
fine - no one will notice. If it does take 270ms to find a monitor, it
turns on 200ms after userspace kicks in, just like any other hotplug.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

2018-05-07 Thread Feng Tang
Hi Chris,

Thanks for the prompt review!

On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
> Quoting Feng Tang (2018-05-07 11:36:09)
> > To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
> > from 7 to 32, which may hurt the boot/init time for some platforms,
> > as the 32 retries may take hundreds of ms.
> 
> If we need that many retries, so be it. No modparam, the driver just has
> to work.

I understand your point. The retry numer was originally 7, and worked
fine untill the Dell 4K monitor which changes to 32.  According to my test,
each retry will take about 8ms on the A3960 based NUC.

One of our product need to boot up within a given time limit, this
32 retries will take about 1/3 of the budget (about 270ms), that's
why I would try to make it a parameter.

>  
> > This patch makes no functional change, but make the max retries
> > adjustable, so that concerned users/platforms can have an option
> > to short the wait time.
> > 
> > On a Intel Atom Processor A3960 based NUC, the i915_init() time could
> > be reduced from 450ms to 200ms.
> > 
> > retries = 3:
> > [0.457806] calling  i915_init+0x0/0x51 @ 1
> > [0.662307] initcall i915_init+0x0/0x51 returned 0 after 199694 
> > usecs
> > 
> > retries = 32:
> > [0.465818] calling  i915_init+0x0/0x51 @ 1
> > [0.925831] initcall i915_init+0x0/0x51 returned 0 after 449219 
> > usecs
> 
> Why is this synchronous anyway?

I don't know the reason, maybe some of kernel components depends on the GFX 
module.
But even we can put it to async, it is still the longest init one on our 
platform.

Thanks,
Feng

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


[Intel-gfx] [PATCH v9 2/2] i915: content-type property for HDMI connector

2018-05-07 Thread StanLis
From: Stanislav Lisovskiy 

Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.

This requires also manipulationg ITC bit, as stated in
HDMI spec.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c   | 24 ++--
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..61ddb5871d8a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..1080254a578b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -460,8 +460,10 @@ static void intel_write_infoframe(struct drm_encoder 
*encoder,
intel_dig_port->write_infoframe(encoder, crtc_state, frame->any.type, 
buffer, len);
 }
 
+
 static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
-const struct intel_crtc_state 
*crtc_state)
+const struct intel_crtc_state 
*crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
const struct drm_display_mode *adjusted_mode =
@@ -469,6 +471,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
struct drm_connector *connector = _hdmi->attached_connector->base;
bool is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
union hdmi_infoframe frame;
+   enum hdmi_content_type content_type;
+   bool itc;
int ret;
 
ret = drm_hdmi_avi_infoframe_from_display_mode(,
@@ -491,6 +495,13 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   /* convert generic content type property to HDMI specific */
+   itc = drm_hdmi_get_itc_bit_from_property(conn_state->content_type);
+   content_type = 
drm_hdmi_get_content_type_from_property(conn_state->content_type);
+
+   frame.avi.itc = itc;
+   frame.avi.content_type = content_type;
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -586,7 +597,7 @@ static void g4x_set_infoframes(struct drm_encoder *encoder,
I915_WRITE(reg, val);
POSTING_READ(reg);
 
-   intel_hdmi_set_avi_infoframe(encoder, crtc_state);
+   

[Intel-gfx] [PATCH v9 1/2] drm: content-type property for HDMI connector

2018-05-07 Thread StanLis
From: Stanislav Lisovskiy 

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/drm-kms.rst|  6 +++
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c |  4 ++
 drivers/gpu/drm/drm_connector.c  | 74 
 drivers/gpu/drm/drm_edid.c   | 55 +
 include/drm/drm_connector.h  | 12 +
 include/drm/drm_edid.h   |  6 +++
 include/drm/drm_mode_config.h|  5 ++
 include/uapi/drm/drm_mode.h  |  7 +++
 9 files changed, 170 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1dffd1ac4cd4..e233c2626bd0 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -517,6 +517,12 @@ Standard Connector Properties
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: standard connector properties
 
+HDMI Specific Connector Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: HDMI connector properties
+
 Plane Composition Properties
 
 
diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 07ed22ea3bd6..bfde04eddd14 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3d9ae057a6cd..6c1e1e774517 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1270,6 +1270,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1355,6 +1357,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->link_status;
} 

[Intel-gfx] [PATCH v9 0/2] Enabling content-type setting for HDMI displays.

2018-05-07 Thread StanLis
From: Stanislav Lisovskiy 

Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).

Stanislav Lisovskiy (2):
  drm: content-type property for HDMI connector
  i915: content-type property for HDMI connector

 Documentation/gpu/drm-kms.rst|  6 +++
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c |  4 ++
 drivers/gpu/drm/drm_connector.c  | 74 
 drivers/gpu/drm/drm_edid.c   | 55 +
 drivers/gpu/drm/i915/intel_atomic.c  |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c| 24 ++---
 include/drm/drm_connector.h  | 12 +
 include/drm/drm_edid.h   |  6 +++
 include/drm/drm_mode_config.h|  5 ++
 include/uapi/drm/drm_mode.h  |  7 +++
 11 files changed, 189 insertions(+), 6 deletions(-)

-- 
2.17.0

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


Re: [Intel-gfx] [PATCH v13 08/10] drm: Expose modes with aspect ratio, only if requested

2018-05-07 Thread Nautiyal, Ankit K



On 5/7/2018 5:58 PM, Ville Syrjälä wrote:

On Mon, May 07, 2018 at 10:34:53AM +0530, Nautiyal, Ankit K wrote:


On 5/5/2018 1:49 AM, Ville Syrjälä wrote:

On Thu, May 03, 2018 at 08:26:26AM +0200, Daniel Vetter wrote:

On Wed, May 02, 2018 at 12:20:20PM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.

This patch:
-prunes the modes with aspect-ratio information, from a
   connector's modelist, if the user-space has not set the aspect ratio
   DRM client cap. However if such a mode is unique in the list, it is
   kept in the list, with aspect-ratio flags reset.
-prepares a list of exposed modes, which is used to find unique modes
   if aspect-ratio is not allowed.
-adds a new list_head 'exposed_head' in drm_mode_display, to traverse
   the list of exposed modes.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of modes
  with aspect-ratio, if the aspect-ratio is not supported. Instead
  of straight away pruning such a mode, the mode is retained with
  aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
  -used a pointer to store last valid mode.
  -avoided, modifying of picture_aspect_ratio in kernel mode,
   instead only flags bits of user mode are reset (if aspect-ratio
   is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
  elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
   logic to correctly identify and prune modes with aspect-ratio,
   if aspect-ratio cap is not set.
V12: As suggested by Ville, added another list_head in
   drm_mode_display to traverse the list of exposed modes and
   avoided duplication of modes.
V13: Minor modifications, as suggested by Ville.
---
   drivers/gpu/drm/drm_connector.c | 45 
++---
   include/drm/drm_modes.h | 13 
   2 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dfc8ca1..8ca1149 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1531,15 +1531,36 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
   }
   
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,

-const struct drm_file *file_priv)
+static bool
+drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
+const struct list_head *export_list,
+const struct drm_file *file_priv)
   {
/*
 * If user-space hasn't configured the driver to expose the stereo 3D
 * modes, don't expose them.
 */
+
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them. However if such a mode
+* is unique, let it be exposed, but reset the aspect-ratio flags
+* while preparing the list of user-modes.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
+   struct drm_display_mode *mode_itr;
+
+   list_for_each_entry(mode_itr, export_list, export_head)

By walking the list of only the modes already added to the export list we
rely on ASPECT_NONE being first if present. That seems to be a bit
fragile. If we instead walk over all present modes (i.e. connector->modes)
then I think that's avoided.

I don't think that would work. If we just walk over all the modes then
wouldn't we always find a duplicate when the same mode with two different
aspect ratios is on the list? And then we'd export neither? Or maybe I
misunderstood what you mean here.

To me it seems like the correct option is to check against the
export_list unconditionally, no matter whether the current mode has the
aspect ratio set or not. If an identical mode is already on the list
we don't export again, if it's not there then we export.

Agreed. The current code does have a problem rightly pointed by Daniel
Vetter and the main reason
for that is - we are checking for duplicates only if the mode has some
aspect-ratio.
As you have suggested, If we can do away with the condition to check for
duplicates 

Re: [Intel-gfx] [PATCH v13 08/10] drm: Expose modes with aspect ratio, only if requested

2018-05-07 Thread Ville Syrjälä
On Mon, May 07, 2018 at 10:34:53AM +0530, Nautiyal, Ankit K wrote:
> 
> 
> On 5/5/2018 1:49 AM, Ville Syrjälä wrote:
> > On Thu, May 03, 2018 at 08:26:26AM +0200, Daniel Vetter wrote:
> >> On Wed, May 02, 2018 at 12:20:20PM +0530, Nautiyal, Ankit K wrote:
> >>> From: Ankit Nautiyal 
> >>>
> >>> We parse the EDID and add all the modes in the connector's modelist.
> >>> This adds CEA modes with aspect ratio information too, regardless of
> >>> whether user space requested this information or not.
> >>>
> >>> This patch:
> >>> -prunes the modes with aspect-ratio information, from a
> >>>   connector's modelist, if the user-space has not set the aspect ratio
> >>>   DRM client cap. However if such a mode is unique in the list, it is
> >>>   kept in the list, with aspect-ratio flags reset.
> >>> -prepares a list of exposed modes, which is used to find unique modes
> >>>   if aspect-ratio is not allowed.
> >>> -adds a new list_head 'exposed_head' in drm_mode_display, to traverse
> >>>   the list of exposed modes.
> >>>
> >>> Cc: Ville Syrjala 
> >>> Cc: Shashank Sharma 
> >>> Cc: Jose Abreu 
> >>>
> >>> Signed-off-by: Ankit Nautiyal 
> >>>
> >>> V3: As suggested by Ville, modified the mechanism of pruning of modes
> >>>  with aspect-ratio, if the aspect-ratio is not supported. Instead
> >>>  of straight away pruning such a mode, the mode is retained with
> >>>  aspect ratio bits set to zero, provided it is unique.
> >>> V4: rebase
> >>> V5: Addressed review comments from Ville:
> >>>  -used a pointer to store last valid mode.
> >>>  -avoided, modifying of picture_aspect_ratio in kernel mode,
> >>>   instead only flags bits of user mode are reset (if aspect-ratio
> >>>   is not supported).
> >>> V6: As suggested by Ville, corrected the mode pruning logic and
> >>>  elaborated the mode pruning logic and the assumptions taken.
> >>> V7: rebase
> >>> V8: rebase
> >>> V9: rebase
> >>> V10: rebase
> >>> V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
> >>>   logic to correctly identify and prune modes with aspect-ratio,
> >>>   if aspect-ratio cap is not set.
> >>> V12: As suggested by Ville, added another list_head in
> >>>   drm_mode_display to traverse the list of exposed modes and
> >>>   avoided duplication of modes.
> >>> V13: Minor modifications, as suggested by Ville.
> >>> ---
> >>>   drivers/gpu/drm/drm_connector.c | 45 
> >>> ++---
> >>>   include/drm/drm_modes.h | 13 
> >>>   2 files changed, 51 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_connector.c 
> >>> b/drivers/gpu/drm/drm_connector.c
> >>> index dfc8ca1..8ca1149 100644
> >>> --- a/drivers/gpu/drm/drm_connector.c
> >>> +++ b/drivers/gpu/drm/drm_connector.c
> >>> @@ -1531,15 +1531,36 @@ static struct drm_encoder 
> >>> *drm_connector_get_encoder(struct drm_connector *conne
> >>>   return connector->encoder;
> >>>   }
> >>>   
> >>> -static bool drm_mode_expose_to_userspace(const struct drm_display_mode 
> >>> *mode,
> >>> -  const struct drm_file *file_priv)
> >>> +static bool
> >>> +drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
> >>> +  const struct list_head *export_list,
> >>> +  const struct drm_file *file_priv)
> >>>   {
> >>>   /*
> >>>* If user-space hasn't configured the driver to expose the 
> >>> stereo 3D
> >>>* modes, don't expose them.
> >>>*/
> >>> +
> >>>   if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
> >>>   return false;
> >>> + /*
> >>> +  * If user-space hasn't configured the driver to expose the modes
> >>> +  * with aspect-ratio, don't expose them. However if such a mode
> >>> +  * is unique, let it be exposed, but reset the aspect-ratio flags
> >>> +  * while preparing the list of user-modes.
> >>> +  */
> >>> + if (!file_priv->aspect_ratio_allowed &&
> >>> + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
> >>> + struct drm_display_mode *mode_itr;
> >>> +
> >>> + list_for_each_entry(mode_itr, export_list, export_head)
> >> By walking the list of only the modes already added to the export list we
> >> rely on ASPECT_NONE being first if present. That seems to be a bit
> >> fragile. If we instead walk over all present modes (i.e. connector->modes)
> >> then I think that's avoided.
> > I don't think that would work. If we just walk over all the modes then
> > wouldn't we always find a duplicate when the same mode with two different
> > aspect ratios is on the list? And then we'd export neither? Or maybe I
> > misunderstood what you mean here.
> >
> > To me it seems like the correct option is to check against the
> > export_list 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Combine set-wedged protection and tasklet kicking

2018-05-07 Thread Chris Wilson
Quoting Mika Kuoppala (2018-05-07 13:09:20)
> Chris Wilson  writes:
> 
> > Around request submission, we protect the call to schedule with a
> > premption disable loop to prevent set-wedge chaning function pointers
> 
> s/premption/preemption
> s/chaning/changing
> 
> Also RCU read critical sections can be preempted if CONFIG_PREEMPT_RCU
> so it looks like we should have had explicit preempt_disable()
> before the rcu_read_lock(), if it is the preempt disable we rely on?

No, my mistake in not knowing about PREEMPT_RCU. So we need both. Sigh.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/7] drm/i915: Combine set-wedged protection and tasklet kicking

2018-05-07 Thread Mika Kuoppala
Chris Wilson  writes:

> Around request submission, we protect the call to schedule with a
> premption disable loop to prevent set-wedge chaning function pointers

s/premption/preemption
s/chaning/changing

Also RCU read critical sections can be preempted if CONFIG_PREEMPT_RCU
so it looks like we should have had explicit preempt_disable()
before the rcu_read_lock(), if it is the preempt disable we rely on?

-Mika

> underneath us. This also prevents the tasklet running on the local CPU,
> a trick we use immediately afterwards to forcibly execute the tasklet
> after submission. We can combine the two wlog, and ensure that the
> tasklet is only executed (on the local CPU) after we complete our
> updates to the submission queue (and not after an intermediate,
> incomplete update).
>
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_request.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index e4cf76ec14a6..88ee444679d4 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1110,12 +1110,9 @@ void __i915_request_add(struct i915_request *request, 
> bool flush_caches)
>* decide whether to preempt the entire chain so that it is ready to
>* run at the earliest possible convenience.
>*/
> - rcu_read_lock();
> + local_bh_disable();
>   if (engine->schedule)
>   engine->schedule(request, >ctx->sched);
> - rcu_read_unlock();
> -
> - local_bh_disable();
>   i915_sw_fence_commit(>submit);
>   local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
>  
> -- 
> 2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Chris Wilson
Quoting Mika Kuoppala (2018-05-07 12:15:58)
> Chris Wilson  writes:
> 
> > When called from process context tasklet_schedule() defers itself to
> > ksoftirqd. From experience this may cause unacceptable latencies of over
> > 200ms in executing the submission tasklet, our goal is to reprioritise
> > the HW execution queue and trigger preemption immediately, so convert
> 
> I would add 'execlists preemption' even tho the context points to it,
> as we are also quite intimately entangled here with kernel preemption
> too.

I'll settle for HW preemption.
 
> > the rcu protection over to include a kick of the tasklet.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 5ece6ae4bdff..03cd30001b5d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -578,10 +578,10 @@ static void __fence_set_priority(struct dma_fence 
> > *fence,
> >   rq = to_request(fence);
> >   engine = rq->engine;
> >  
> > - rcu_read_lock();
> > + local_bh_disable(); /* RCU serialisation for set-wedged protection */
> >   if (engine->schedule)
> >   engine->schedule(rq, attr);
> > - rcu_read_unlock();
> > + local_bh_enable(); /* kick the tasklets if queues were reprioritised 
> > */
> 
> Do we end up calling the tasklet->func() explicitly on the end of
> engine->schedule()?

We do tasklet_hi_schedule(). Well in the future, we might either call
 ->func() directly or schedule. In the former case, no softirq is raised
 and local_bh_enable is just a slightly heavier preempt_disable().
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Mika Kuoppala
Chris Wilson  writes:

> When called from process context tasklet_schedule() defers itself to
> ksoftirqd. From experience this may cause unacceptable latencies of over
> 200ms in executing the submission tasklet, our goal is to reprioritise
> the HW execution queue and trigger preemption immediately, so convert

I would add 'execlists preemption' even tho the context points to it,
as we are also quite intimately entangled here with kernel preemption
too.

> the rcu protection over to include a kick of the tasklet.
>
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 5ece6ae4bdff..03cd30001b5d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -578,10 +578,10 @@ static void __fence_set_priority(struct dma_fence 
> *fence,
>   rq = to_request(fence);
>   engine = rq->engine;
>  
> - rcu_read_lock();
> + local_bh_disable(); /* RCU serialisation for set-wedged protection */
>   if (engine->schedule)
>   engine->schedule(rq, attr);
> - rcu_read_unlock();
> + local_bh_enable(); /* kick the tasklets if queues were reprioritised */

Do we end up calling the tasklet->func() explicitly on the end of
engine->schedule()?

Reviewed-by: Mika Kuoppala 

>  }
>  
>  static void fence_set_priority(struct dma_fence *fence,
> -- 
> 2.17.0
___
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/dp: add module parameter for the dpcd access max retries

2018-05-07 Thread Patchwork
== Series Details ==

Series: drm/dp: add module parameter for the dpcd access max retries
URL   : https://patchwork.freedesktop.org/series/42803/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4150 -> Patchwork_8925 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8925 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8925, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42803/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8925:

  === IGT changes ===

 Possible regressions 

igt@drv_module_reload@basic-reload:
  fi-ilk-650: PASS -> DMESG-WARN +2


== Known issues ==

  Here are the changes found in Patchwork_8925 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@debugfs_test@read_all_entries:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)

igt@gem_ringfill@basic-default-hang:
  fi-pnv-d510:NOTRUN -> DMESG-WARN (fdo#101600)

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106235)


 Possible fixes 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-skl-guc: FAIL (fdo#103928) -> PASS

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   DMESG-FAIL (fdo#102614, fdo#106103) -> PASS

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-skl-6700k2:  FAIL (fdo#104724, fdo#103191) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-glk-j4005:   DMESG-WARN (fdo#106097) -> PASS


  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103
  fdo#106235 https://bugs.freedesktop.org/show_bug.cgi?id=106235


== Participating hosts (38 -> 37) ==

  Additional (2): fi-kbl-7560u fi-pnv-d510 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4150 -> Patchwork_8925

  CI_DRM_4150: 93d32416ba4b1dae9451fec28aaa71915d770f51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4463: 91b5a3ef5516b29584ea4567b0f5ffa18219b29f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8925: 20cc4fb19e8fad3e982aa5df72506553f9fe36ab @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4463: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

20cc4fb19e8f drm/dp: add module parameter for the dpcd access max retries

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8925/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

2018-05-07 Thread Chris Wilson
Quoting Feng Tang (2018-05-07 11:36:09)
> To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
> from 7 to 32, which may hurt the boot/init time for some platforms,
> as the 32 retries may take hundreds of ms.

If we need that many retries, so be it. No modparam, the driver just has
to work.
 
> This patch makes no functional change, but make the max retries
> adjustable, so that concerned users/platforms can have an option
> to short the wait time.
> 
> On a Intel Atom Processor A3960 based NUC, the i915_init() time could
> be reduced from 450ms to 200ms.
> 
> retries = 3:
> [0.457806] calling  i915_init+0x0/0x51 @ 1
> [0.662307] initcall i915_init+0x0/0x51 returned 0 after 199694 
> usecs
> 
> retries = 32:
> [0.465818] calling  i915_init+0x0/0x51 @ 1
> [0.925831] initcall i915_init+0x0/0x51 returned 0 after 449219 
> usecs

Why is this synchronous anyway?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

2018-05-07 Thread Feng Tang
To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
from 7 to 32, which may hurt the boot/init time for some platforms,
as the 32 retries may take hundreds of ms.

This patch makes no functional change, but make the max retries
adjustable, so that concerned users/platforms can have an option
to short the wait time.

On a Intel Atom Processor A3960 based NUC, the i915_init() time could
be reduced from 450ms to 200ms.

retries = 3:
[0.457806] calling  i915_init+0x0/0x51 @ 1
[0.662307] initcall i915_init+0x0/0x51 returned 0 after 199694 usecs

retries = 32:
[0.465818] calling  i915_init+0x0/0x51 @ 1
[0.925831] initcall i915_init+0x0/0x51 returned 0 after 449219 usecs

Signed-off-by: Feng Tang 
---
 drivers/gpu/drm/drm_dp_helper.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ffe14ec..6054067 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -171,6 +171,20 @@ EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
 
 #define AUX_RETRY_INTERVAL 500 /* us */
 
+/*
+ * The specification doesn't give any recommendation on how often to
+ * retry native transactions. We used to retry 7 times like for
+ * aux i2c transactions but real world devices this wasn't
+ * sufficient, bump to 32 which makes Dell 4k monitors happier.
+ *
+ * Since the retry may take quite some boot time, we make it a
+ * adjustable parameter for possible shorter retry time.
+ */
+static int dp_dpcd_max_retries __read_mostly = 32;
+module_param_unsafe(dp_dpcd_max_retries, int, 0644);
+MODULE_PARM_DESC(dp_dpcd_max_retries,
+"Max retry number for DPCD access (default 32)");
+
 /**
  * DOC: dp helpers
  *
@@ -198,13 +212,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
 
mutex_lock(>hw_mutex);
 
-   /*
-* The specification doesn't give any recommendation on how often to
-* retry native transactions. We used to retry 7 times like for
-* aux i2c transactions but real world devices this wasn't
-* sufficient, bump to 32 which makes Dell 4k monitors happier.
-*/
-   for (retry = 0; retry < 32; retry++) {
+   for (retry = 0; retry < dp_dpcd_max_retries; retry++) {
if (ret != 0 && ret != -ETIMEDOUT) {
usleep_range(AUX_RETRY_INTERVAL,
 AUX_RETRY_INTERVAL + 100);
-- 
2.7.4

___
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 [1/7] drm/i915: Flush submission tasklet after bumping priority (rev2)

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/7] drm/i915: Flush submission tasklet after 
bumping priority (rev2)
URL   : https://patchwork.freedesktop.org/series/42800/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4150 -> Patchwork_8924 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8924 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8924, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42800/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8924:

  === IGT changes ===

 Possible regressions 

igt@gem_exec_gttfill@basic:
  fi-skl-guc: PASS -> INCOMPLETE


== Known issues ==

  Here are the changes found in Patchwork_8924 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_ringfill@basic-default-hang:
  fi-pnv-d510:NOTRUN -> DMESG-WARN (fdo#101600)

igt@kms_chamelium@hdmi-hpd-fast:
  fi-kbl-7500u:   SKIP -> FAIL (fdo#102672, fdo#103841)


 Possible fixes 

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   DMESG-FAIL (fdo#102614, fdo#106103) -> PASS

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-skl-6700k2:  FAIL (fdo#103191, fdo#104724) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-glk-j4005:   DMESG-WARN (fdo#106097) -> PASS


  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103


== Participating hosts (38 -> 37) ==

  Additional (2): fi-kbl-7560u fi-pnv-d510 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4150 -> Patchwork_8924

  CI_DRM_4150: 93d32416ba4b1dae9451fec28aaa71915d770f51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4463: 91b5a3ef5516b29584ea4567b0f5ffa18219b29f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8924: a6ecf3114c11797b6f46d2e9fb7172d69a676305 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4463: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

a6ecf3114c11 drm/i915: Speed up idle detection by kicking the tasklets
637900fb273c drm/i915/execlists: Direct submission from irq handler
dbee74d26584 drm/i915/execlists: Direct submit onto idle engines
26afd02dbd15 drm/i915/guc: Make submission tasklet hardirq safe
9a183196dc0c drm/i915/execlists: Make submission tasklet hardirq safe
3fff19362e88 drm/i915: Combine set-wedged protection and tasklet kicking
a337a1138169 drm/i915: Flush submission tasklet after bumping priority

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8924/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915: Flush submission tasklet after bumping priority (rev2)

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/7] drm/i915: Flush submission tasklet after 
bumping priority (rev2)
URL   : https://patchwork.freedesktop.org/series/42800/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Flush submission tasklet after bumping priority
Okay!

Commit: drm/i915: Combine set-wedged protection and tasklet kicking
Okay!

Commit: drm/i915/execlists: Make submission tasklet hardirq safe
Okay!

Commit: drm/i915/guc: Make submission tasklet hardirq safe
Okay!

Commit: drm/i915/execlists: Direct submit onto idle engines
+drivers/gpu/drm/i915/intel_guc_submission.c:766:39: warning: context imbalance 
in 'guc_dequeue' - unexpected unlock
+drivers/gpu/drm/i915/intel_lrc.c:769:39: warning: context imbalance in 
'execlists_dequeue' - unexpected unlock
-O:drivers/gpu/drm/i915/intel_ringbuffer.h:651:23: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_ringbuffer.h:651:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_ringbuffer.h:658:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_ringbuffer.h:658:23: warning: expression using 
sizeof(void)

Commit: drm/i915/execlists: Direct submission from irq handler
Okay!

Commit: drm/i915: Speed up idle detection by kicking the tasklets
Okay!

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915: Flush submission tasklet after bumping priority (rev2)

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/7] drm/i915: Flush submission tasklet after 
bumping priority (rev2)
URL   : https://patchwork.freedesktop.org/series/42800/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a337a1138169 drm/i915: Flush submission tasklet after bumping priority
3fff19362e88 drm/i915: Combine set-wedged protection and tasklet kicking
-:7: WARNING:TYPO_SPELLING: 'premption' may be misspelled - perhaps 
'preemption'?
#7: 
premption disable loop to prevent set-wedge chaning function pointers

total: 0 errors, 1 warnings, 0 checks, 13 lines checked
9a183196dc0c drm/i915/execlists: Make submission tasklet hardirq safe
26afd02dbd15 drm/i915/guc: Make submission tasklet hardirq safe
dbee74d26584 drm/i915/execlists: Direct submit onto idle engines
-:25: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should 
also have an identifier name
#25: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:757:
+   unsigned long uninitialized_var(flags);

-:58: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should 
also have an identifier name
#58: FILE: drivers/gpu/drm/i915/intel_lrc.c:760:
+   unsigned long uninitialized_var(flags);

total: 0 errors, 2 warnings, 0 checks, 132 lines checked
637900fb273c drm/i915/execlists: Direct submission from irq handler
a6ecf3114c11 drm/i915: Speed up idle detection by kicking the tasklets

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


[Intel-gfx] ✓ Fi.CI.IGT: success for Enable NV12 support (rev5)

2018-05-07 Thread Patchwork
== Series Details ==

Series: Enable NV12 support (rev5)
URL   : https://patchwork.freedesktop.org/series/41674/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4150_full -> Patchwork_8922_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8922_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8922_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41674/revisions/5/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8922_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-render:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_8922_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_cursor_crc@cursor-128x128-suspend:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103313)

igt@kms_flip@2x-flip-vs-absolute-wf_vblank:
  shard-hsw:  PASS -> FAIL (fdo#100368) +1

igt@kms_rotation_crc@primary-rotation-270:
  shard-apl:  PASS -> DMESG-WARN (fdo#105127)

igt@kms_universal_plane@cursor-fb-leak-pipe-b:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103558, fdo#105602) +18


 Possible fixes 

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-kbl:  FAIL (fdo#100368) -> PASS

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +7

igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
  shard-apl:  FAIL (fdo#103166, fdo#104724) -> PASS

igt@kms_rotation_crc@primary-rotation-90:
  shard-apl:  FAIL (fdo#103925, fdo#104724) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105127 https://bugs.freedesktop.org/show_bug.cgi?id=105127
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602


== Participating hosts (6 -> 6) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4150 -> Patchwork_8922

  CI_DRM_4150: 93d32416ba4b1dae9451fec28aaa71915d770f51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4463: 91b5a3ef5516b29584ea4567b0f5ffa18219b29f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8922: f016aabaa90d06bf1e8864e8be93af778aec8f3b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4463: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8922/shards.html
___
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 [1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/7] drm/i915: Flush submission tasklet after 
bumping priority
URL   : https://patchwork.freedesktop.org/series/42800/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4150 -> Patchwork_8923 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8923 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8923, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42800/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8923:

  === IGT changes ===

 Possible regressions 

igt@gem_exec_parallel@basic:
  fi-skl-guc: PASS -> INCOMPLETE


== Known issues ==

  Here are the changes found in Patchwork_8923 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#105128)

igt@gem_ringfill@basic-default-hang:
  fi-pnv-d510:NOTRUN -> DMESG-WARN (fdo#101600)

igt@kms_flip@basic-flip-vs-modeset:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106097)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-cnl-y3:  PASS -> DMESG-WARN (fdo#104951)


 Possible fixes 

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   DMESG-FAIL (fdo#106103, fdo#102614) -> PASS

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-skl-6700k2:  FAIL (fdo#103191, fdo#104724) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-glk-j4005:   DMESG-WARN (fdo#106097) -> PASS


  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103


== Participating hosts (38 -> 37) ==

  Additional (2): fi-kbl-7560u fi-pnv-d510 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4150 -> Patchwork_8923

  CI_DRM_4150: 93d32416ba4b1dae9451fec28aaa71915d770f51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4463: 91b5a3ef5516b29584ea4567b0f5ffa18219b29f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8923: 813ac493c9e18c7e744dca193d7e512c38b41850 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4463: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

813ac493c9e1 drm/i915: Speed up idle detection by kicking the tasklets
1a157fc92a41 drm/i915/execlists: Direct submission from irq handler
52010b9a0967 drm/i915/execlists: Direct submit onto idle engines
260be6c60570 drm/i915/guc: Make submission tasklet hardirq safe
e4c720c38170 drm/i915/execlists: Make submission tasklet hardirq safe
a81b5d17707b drm/i915: Combine set-wedged protection and tasklet kicking
003f117f2171 drm/i915: Flush submission tasklet after bumping priority

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8923/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] dma-fence: Make ->enable_signaling optional

2018-05-07 Thread Maarten Lankhorst
Op 04-05-18 om 16:10 schreef Daniel Vetter:
> Many drivers have a trivial implementation for ->enable_signaling.
> Let's make it optional by assuming that signalling is already
> available when the callback isn't present.
>
> v2: Don't do the trick to set the ENABLE_SIGNAL_BIT
> unconditionally, it results in an expensive spinlock take for
> everyone. Instead just check if the callback is present. Suggested by
> Maarten.
>
> Also move misplaced kerneldoc hunk to the right patch.
>
> Cc: Maarten Lankhorst 
> Reviewed-by: Christian König  (v1)
> Signed-off-by: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: Gustavo Padovan 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
>  drivers/dma-buf/dma-fence.c | 9 +
>  include/linux/dma-fence.h   | 3 ++-
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 4edb9fd3cf47..dd01a1720be9 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -200,7 +200,8 @@ void dma_fence_enable_sw_signaling(struct dma_fence 
> *fence)
>  
>   if (!test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
> >flags) &&
> - !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
> + !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags) &&
> + fence->ops->enable_signaling) {
>   trace_dma_fence_enable_signal(fence);
>  
>   spin_lock_irqsave(fence->lock, flags);
> @@ -260,7 +261,7 @@ int dma_fence_add_callback(struct dma_fence *fence, 
> struct dma_fence_cb *cb,
>  
>   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
>   ret = -ENOENT;
> - else if (!was_set) {
> + else if (!was_set && fence->ops->enable_signaling) {
>   trace_dma_fence_enable_signal(fence);
>  
>   if (!fence->ops->enable_signaling(fence)) {
> @@ -388,7 +389,7 @@ dma_fence_default_wait(struct dma_fence *fence, bool 
> intr, signed long timeout)
>   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
>   goto out;
>  
> - if (!was_set) {
> + if (!was_set && fence->ops->enable_signaling) {
>   trace_dma_fence_enable_signal(fence);
>  
>   if (!fence->ops->enable_signaling(fence)) {
> @@ -560,7 +561,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
> dma_fence_ops *ops,
>  spinlock_t *lock, u64 context, unsigned seqno)
>  {
>   BUG_ON(!lock);
> - BUG_ON(!ops || !ops->wait || !ops->enable_signaling ||
> + BUG_ON(!ops || !ops->wait ||
>  !ops->get_driver_name || !ops->get_timeline_name);
>  
>   kref_init(>refcount);
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 111aefe1c956..c053d19e1e24 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -166,7 +166,8 @@ struct dma_fence_ops {
>* released when the fence is signalled (through e.g. the interrupt
>* handler).
>*
> -  * This callback is mandatory.
> +  * This callback is optional. If this callback is not present, then the
> +  * driver must always have signaling enabled.
>*/
>   bool (*enable_signaling)(struct dma_fence *fence);
>  

Much better. :)

Reviewed-by: Maarten Lankhorst 

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


[Intel-gfx] [PATCH v3] drm/i915: Speed up idle detection by kicking the tasklets

2018-05-07 Thread Chris Wilson
We rely on ksoftirqd to run in a timely fashion in order to drain the
execlists queue. Quite frequently, it does not. In some cases we may see
latencies of over 200ms triggering our idle timeouts and forcing us to
declare the driver wedged!

Thus we can speed up idle detection by bypassing ksoftirqd in these
cases and flush our tasklet to confirm if we are indeed still waiting
for the ELSP to drain.

v2: Put the execlists.first check back; it is required for handling
reset!
v3: Follow Mika's suggestion to try and limit kicking the tasklet to
only when we expect it to make a difference, i.e. in catch up after a CS
interrupt, and not just execute it everytime as that is likely just to
cover over our own bugs.

References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 70325e0824e3..27f6b30e032f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -944,11 +944,20 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (I915_SELFTEST_ONLY(engine->breadcrumbs.mock))
return true;
 
+   /*
+* ksoftirqd has notorious latency that may cause us to
+* timeout while waiting for the engine to idle as we wait for
+* ksoftirqd to run the execlists tasklet to drain the ELSP.
+* If we are expecting a context switch from the GPU, check now.
+*/
+   if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
+   execlists_tasklet(>execlists);
+
/* Waiting to drain ELSP? */
if (READ_ONCE(engine->execlists.active))
return false;
 
-   /* ELSP is empty, but there are ready requests? */
+   /* ELSP is empty, but there are ready requests? E.g. after reset */
if (READ_ONCE(engine->execlists.first))
return false;
 
-- 
2.17.0

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/7] drm/i915: Flush submission tasklet after 
bumping priority
URL   : https://patchwork.freedesktop.org/series/42800/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Flush submission tasklet after bumping priority
Okay!

Commit: drm/i915: Combine set-wedged protection and tasklet kicking
Okay!

Commit: drm/i915/execlists: Make submission tasklet hardirq safe
Okay!

Commit: drm/i915/guc: Make submission tasklet hardirq safe
Okay!

Commit: drm/i915/execlists: Direct submit onto idle engines
+drivers/gpu/drm/i915/intel_guc_submission.c:766:39: warning: context imbalance 
in 'guc_dequeue' - unexpected unlock
+drivers/gpu/drm/i915/intel_lrc.c:769:39: warning: context imbalance in 
'execlists_dequeue' - unexpected unlock
-O:drivers/gpu/drm/i915/intel_ringbuffer.h:651:23: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_ringbuffer.h:651:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_ringbuffer.h:658:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_ringbuffer.h:658:23: warning: expression using 
sizeof(void)

Commit: drm/i915/execlists: Direct submission from irq handler
Okay!

Commit: drm/i915: Speed up idle detection by kicking the tasklets
Okay!

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/7] drm/i915: Flush submission tasklet after 
bumping priority
URL   : https://patchwork.freedesktop.org/series/42800/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
003f117f2171 drm/i915: Flush submission tasklet after bumping priority
a81b5d17707b drm/i915: Combine set-wedged protection and tasklet kicking
-:7: WARNING:TYPO_SPELLING: 'premption' may be misspelled - perhaps 
'preemption'?
#7: 
premption disable loop to prevent set-wedge chaning function pointers

total: 0 errors, 1 warnings, 0 checks, 13 lines checked
e4c720c38170 drm/i915/execlists: Make submission tasklet hardirq safe
260be6c60570 drm/i915/guc: Make submission tasklet hardirq safe
52010b9a0967 drm/i915/execlists: Direct submit onto idle engines
-:25: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should 
also have an identifier name
#25: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:757:
+   unsigned long uninitialized_var(flags);

-:58: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should 
also have an identifier name
#58: FILE: drivers/gpu/drm/i915/intel_lrc.c:760:
+   unsigned long uninitialized_var(flags);

total: 0 errors, 2 warnings, 0 checks, 132 lines checked
1a157fc92a41 drm/i915/execlists: Direct submission from irq handler
813ac493c9e1 drm/i915: Speed up idle detection by kicking the tasklets

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


Re: [Intel-gfx] [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-05-07 Thread Maarten Lankhorst
Op 10-05-18 om 10:31 schreef Vidya Srinivas:
> From: Maarten Lankhorst 
>
> We skip src trunction/adjustments for
> NV12 case and handle the sizes directly.
> Without this, pipe fifo underruns are seen on APL/KBL.
>
> v2: For NV12, making the src coordinates multiplier of 4
>
> v3: Moving all the src coords handling code for NV12
> to skl_check_nv12_surface
>
> v4: Added RB from Mika
>
> v5: Rebased the series. Removed checks of mult of 4 in
> skl_update_scaler, Added NV12 condition in intel_check_sprite_plane
> where src x/w is being checked for mult of 2 for yuv planes.
>
> Reviewed-by: Mika Kahola 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 42 
> ++--
>  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
>  2 files changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index dfca71e..cca46f9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3102,6 +3102,42 @@ static int skl_check_main_surface(const struct 
> intel_crtc_state *crtc_state,
>   return 0;
>  }
>  
> +static int
> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> +struct intel_plane_state *plane_state)
> +{
> + int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> + int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> +
> + if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> + ((plane_state->base.src_y >> 16) % 4) != 0 ||
> + ((plane_state->base.src_w >> 16) % 4) != 0 ||
> + ((plane_state->base.src_h >> 16) % 4) != 0) {
> + DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
> + return -EINVAL;
> + }
> +
> + /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> + if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
> + (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
> + DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
> +   crtc_x2, crtc_y2,
> +   crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> + return -EINVAL;
> + }
Oops, wrong checks here..

skl_check_nv12_surface is only needed for Display WA #1106, so check might need 
to be something like:

static int
skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
   struct intel_plane_state *plane_state)
{
/* Display WA #1106 */
if (plane_state->base.rotation != (DRM_MODE_REFLECT_X | 
DRM_MODE_ROTATE_90) &&
plane_state->base.rotation != DRM_MODE_ROTATE_270)
return 0;

/* src coordinates are rotated here. We check height but report it as 
width. */
if (((drm_rect_height(_state->base.src) >> 16) % 4) != 0) {
DRM_DEBUG_KMS("src width must be multiple of 4 for rotated 
NV12\n");
return -EINVAL;
}

return 0;
}

Would this hit FIFO underruns?

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


[Intel-gfx] [PATCH 2/7] drm/i915: Combine set-wedged protection and tasklet kicking

2018-05-07 Thread Chris Wilson
Around request submission, we protect the call to schedule with a
premption disable loop to prevent set-wedge chaning function pointers
underneath us. This also prevents the tasklet running on the local CPU,
a trick we use immediately afterwards to forcibly execute the tasklet
after submission. We can combine the two wlog, and ensure that the
tasklet is only executed (on the local CPU) after we complete our
updates to the submission queue (and not after an intermediate,
incomplete update).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_request.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index e4cf76ec14a6..88ee444679d4 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1110,12 +1110,9 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
 * decide whether to preempt the entire chain so that it is ready to
 * run at the earliest possible convenience.
 */
-   rcu_read_lock();
+   local_bh_disable();
if (engine->schedule)
engine->schedule(request, >ctx->sched);
-   rcu_read_unlock();
-
-   local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
 
-- 
2.17.0

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


[Intel-gfx] [PATCH 3/7] drm/i915/execlists: Make submission tasklet hardirq safe

2018-05-07 Thread Chris Wilson
Prepare to allow the execlists submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets and context switches.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f9f4064dec0e..56d60e830d11 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -554,7 +554,7 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
 }
 
-static void execlists_dequeue(struct intel_engine_cs *engine)
+static bool __execlists_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
@@ -564,6 +564,8 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
struct rb_node *rb;
bool submit = false;
 
+   lockdep_assert_held(>timeline.lock);
+
/* Hardware submission is through 2 ports. Conceptually each port
 * has a (RING_START, RING_HEAD, RING_TAIL) tuple. RING_START is
 * static for a context, and unique to each, so we only execute
@@ -585,7 +587,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * and context switches) submission.
 */
 
-   spin_lock_irq(>timeline.lock);
rb = execlists->first;
GEM_BUG_ON(rb_first(>queue) != rb);
 
@@ -745,12 +746,24 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
 
 unlock:
-   spin_unlock_irq(>timeline.lock);
-
-   if (submit) {
+   if (last)
execlists_user_begin(execlists, execlists->port);
+
+   return submit;
+}
+
+static void execlists_dequeue(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+   unsigned long flags;
+   bool submit;
+
+   spin_lock_irqsave(>timeline.lock, flags);
+   submit = __execlists_dequeue(engine);
+   spin_unlock_irqrestore(>timeline.lock, flags);
+
+   if (submit)
execlists_submit_ports(engine);
-   }
 
GEM_BUG_ON(port_isset(execlists->port) &&
   !execlists_is_active(execlists, EXECLISTS_ACTIVE_USER));
-- 
2.17.0

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


[Intel-gfx] [PATCH 6/7] drm/i915/execlists: Direct submission from irq handler

2018-05-07 Thread Chris Wilson
Continuing the themem of bypassing ksoftirqd latency, also first try to
directly submit from the CS interrupt handler to clear the ELSP and
queue the next.

In the past, we have been hesitant to do this as the context switch
processing has been quite heavy, requiring forcewaked mmio. However, as
we now can read the GPU state from the cacheable HWSP, it is relatively
cheap!

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c | 10 --
 drivers/gpu/drm/i915/intel_ringbuffer.h | 11 +++
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f9bc3aaa90d0..ce5efb0cbb88 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1465,11 +1465,9 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir)
struct intel_engine_execlists * const execlists = >execlists;
bool tasklet = false;
 
-   if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
-   if (READ_ONCE(engine->execlists.active))
-   tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
-   >irq_posted);
-   }
+   if (iir & GT_CONTEXT_SWITCH_INTERRUPT && READ_ONCE(execlists->active))
+   tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
+   >irq_posted);
 
if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
@@ -1477,7 +1475,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir)
}
 
if (tasklet)
-   tasklet_hi_schedule(>tasklet);
+   execlists_tasklet(execlists);
 }
 
 static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index f5545391d76a..670b0837e2f6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -717,6 +717,17 @@ execlists_port_complete(struct intel_engine_execlists * 
const execlists,
return port;
 }
 
+static inline void
+execlists_tasklet(struct intel_engine_execlists * const execlists)
+{
+   if (tasklet_trylock(>tasklet)) {
+   execlists->tasklet.func(execlists->tasklet.data);
+   tasklet_unlock(>tasklet);
+   } else {
+   tasklet_hi_schedule(>tasklet);
+   }
+}
+
 static inline unsigned int
 intel_engine_flag(const struct intel_engine_cs *engine)
 {
-- 
2.17.0

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


[Intel-gfx] [PATCH 7/7] drm/i915: Speed up idle detection by kicking the tasklets

2018-05-07 Thread Chris Wilson
We rely on ksoftirqd to run in a timely fashion in order to drain the
execlists queue. Quite frequently, it does not. In some cases we may see
latencies of over 200ms triggering our idle timeouts and forcing us to
declare the driver wedged!

Thus we can speed up idle detection by bypassing ksoftirqd in these
cases and flush our tasklet to confirm if we are indeed still waiting
for the ELSP to drain.

v2: Put the execlists.first check back; it is required for handling
reset!

References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 70325e0824e3..0f45d6826c8e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -945,10 +945,19 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return true;
 
/* Waiting to drain ELSP? */
-   if (READ_ONCE(engine->execlists.active))
-   return false;
+   if (READ_ONCE(engine->execlists.active)) {
+   /*
+* ksoftirqd has notorious latency that may cause us to
+* timeout while waiting for the engine to idle as we wait for
+* ksoftirqd to run the execlists tasklet to drain the ELSP.
+* If we are expecting a context switch from the GPU, check now.
+*/
+   execlists_tasklet(>execlists);
+   if (READ_ONCE(engine->execlists.active))
+   return false;
+   }
 
-   /* ELSP is empty, but there are ready requests? */
+   /* ELSP is empty, but there are ready requests? E.g. after reset */
if (READ_ONCE(engine->execlists.first))
return false;
 
-- 
2.17.0

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


[Intel-gfx] [PATCH 5/7] drm/i915/execlists: Direct submit onto idle engines

2018-05-07 Thread Chris Wilson
Bypass using the tasklet to submit the first request to HW, as the
tasklet may be deferred unto ksoftirqd and at a minimum will add in
excess of 10us (and maybe tens of milliseconds) to our execution
latency. This latency reduction is most notable when execution flows
between engines.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 10 ++--
 drivers/gpu/drm/i915/intel_lrc.c| 52 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  7 +++
 3 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 97bd52fbd4e4..fc0799897162 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -754,12 +754,16 @@ static bool __guc_dequeue(struct intel_engine_cs *engine)
 
 static void guc_dequeue(struct intel_engine_cs *engine)
 {
-   unsigned long flags;
+   unsigned long uninitialized_var(flags);
bool submit;
 
-   spin_lock_irqsave(>timeline.lock, flags);
+   if (!intel_engine_direct_submit(engine))
+   spin_lock_irqsave(>timeline.lock, flags);
+
submit = __guc_dequeue(engine);
-   spin_unlock_irqrestore(>timeline.lock, flags);
+
+   if (!intel_engine_direct_submit(engine))
+   spin_unlock_irqrestore(>timeline.lock, flags);
 
if (submit)
guc_submit(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 56d60e830d11..fbe0a7ec8522 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -599,6 +599,8 @@ static bool __execlists_dequeue(struct intel_engine_cs 
*engine)
 */
GEM_BUG_ON(!execlists_is_active(execlists,
EXECLISTS_ACTIVE_USER));
+   GEM_BUG_ON(execlists_is_active(execlists,
+  EXECLISTS_ACTIVE_PREEMPT));
GEM_BUG_ON(!port_count([0]));
if (port_count([0]) > 1)
goto unlock;
@@ -755,12 +757,16 @@ static bool __execlists_dequeue(struct intel_engine_cs 
*engine)
 static void execlists_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
-   unsigned long flags;
+   unsigned long uninitialized_var(flags);
bool submit;
 
-   spin_lock_irqsave(>timeline.lock, flags);
+   if (!intel_engine_direct_submit(engine))
+   spin_lock_irqsave(>timeline.lock, flags);
+
submit = __execlists_dequeue(engine);
-   spin_unlock_irqrestore(>timeline.lock, flags);
+
+   if (!intel_engine_direct_submit(engine))
+   spin_unlock_irqrestore(>timeline.lock, flags);
 
if (submit)
execlists_submit_ports(engine);
@@ -1160,16 +1166,41 @@ static void queue_request(struct intel_engine_cs 
*engine,
  _priolist(engine, node, prio)->requests);
 }
 
-static void __submit_queue(struct intel_engine_cs *engine, int prio)
+static void __wakeup_queue(struct intel_engine_cs *engine, int prio)
 {
engine->execlists.queue_priority = prio;
+}
+
+static void __schedule_queue(struct intel_engine_cs *engine)
+{
tasklet_hi_schedule(>execlists.tasklet);
 }
 
+static void __submit_queue(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   GEM_BUG_ON(!engine->i915->gt.awake);
+
+   /* Directly submit the first request to reduce the initial latency */
+   if (!port_isset(execlists->port) &&
+   tasklet_trylock(>tasklet)) {
+   engine->flags |= I915_ENGINE_DIRECT_SUBMIT;
+   execlists->tasklet.func(execlists->tasklet.data);
+   engine->flags &= ~I915_ENGINE_DIRECT_SUBMIT;
+   tasklet_unlock(>tasklet);
+   return;
+   }
+
+   __schedule_queue(engine);
+}
+
 static void submit_queue(struct intel_engine_cs *engine, int prio)
 {
-   if (prio > engine->execlists.queue_priority)
-   __submit_queue(engine, prio);
+   if (prio > engine->execlists.queue_priority) {
+   __wakeup_queue(engine, prio);
+   __submit_queue(engine);
+   }
 }
 
 static void execlists_submit_request(struct i915_request *request)
@@ -1181,10 +1212,9 @@ static void execlists_submit_request(struct i915_request 
*request)
spin_lock_irqsave(>timeline.lock, flags);
 
queue_request(engine, >sched, rq_prio(request));
-   submit_queue(engine, rq_prio(request));
-
GEM_BUG_ON(!engine->execlists.first);
GEM_BUG_ON(list_empty(>sched.link));
+   submit_queue(engine, rq_prio(request));
 

[Intel-gfx] [PATCH 1/7] drm/i915: Flush submission tasklet after bumping priority

2018-05-07 Thread Chris Wilson
When called from process context tasklet_schedule() defers itself to
ksoftirqd. From experience this may cause unacceptable latencies of over
200ms in executing the submission tasklet, our goal is to reprioritise
the HW execution queue and trigger preemption immediately, so convert
the rcu protection over to include a kick of the tasklet.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5ece6ae4bdff..03cd30001b5d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -578,10 +578,10 @@ static void __fence_set_priority(struct dma_fence *fence,
rq = to_request(fence);
engine = rq->engine;
 
-   rcu_read_lock();
+   local_bh_disable(); /* RCU serialisation for set-wedged protection */
if (engine->schedule)
engine->schedule(rq, attr);
-   rcu_read_unlock();
+   local_bh_enable(); /* kick the tasklets if queues were reprioritised */
 }
 
 static void fence_set_priority(struct dma_fence *fence,
-- 
2.17.0

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


[Intel-gfx] [PATCH 4/7] drm/i915/guc: Make submission tasklet hardirq safe

2018-05-07 Thread Chris Wilson
Prepare to allow the GuC submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets and context switches.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 30 ++---
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 62828e39ee26..97bd52fbd4e4 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -669,7 +669,7 @@ static inline int port_prio(const struct execlist_port 
*port)
return rq_prio(port_request(port));
 }
 
-static void guc_dequeue(struct intel_engine_cs *engine)
+static bool __guc_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
@@ -679,7 +679,8 @@ static void guc_dequeue(struct intel_engine_cs *engine)
bool submit = false;
struct rb_node *rb;
 
-   spin_lock_irq(>timeline.lock);
+   lockdep_assert_held(>timeline.lock);
+
rb = execlists->first;
GEM_BUG_ON(rb_first(>queue) != rb);
 
@@ -694,13 +695,13 @@ static void guc_dequeue(struct intel_engine_cs *engine)
 EXECLISTS_ACTIVE_PREEMPT);
queue_work(engine->i915->guc.preempt_wq,
   _work->work);
-   goto unlock;
+   return false;
}
}
 
port++;
if (port_isset(port))
-   goto unlock;
+   return false;
}
GEM_BUG_ON(port_isset(port));
 
@@ -738,19 +739,30 @@ static void guc_dequeue(struct intel_engine_cs *engine)
 done:
execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
execlists->first = rb;
-   if (submit) {
+   if (submit)
port_assign(port, last);
+   if (last)
execlists_user_begin(execlists, execlists->port);
-   guc_submit(engine);
-   }
 
/* We must always keep the beast fed if we have work piled up */
GEM_BUG_ON(port_isset(execlists->port) &&
   !execlists_is_active(execlists, EXECLISTS_ACTIVE_USER));
GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
 
-unlock:
-   spin_unlock_irq(>timeline.lock);
+   return submit;
+}
+
+static void guc_dequeue(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+   bool submit;
+
+   spin_lock_irqsave(>timeline.lock, flags);
+   submit = __guc_dequeue(engine);
+   spin_unlock_irqrestore(>timeline.lock, flags);
+
+   if (submit)
+   guc_submit(engine);
 }
 
 static void guc_submission_tasklet(unsigned long data)
-- 
2.17.0

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Enable NV12 support (rev5)

2018-05-07 Thread Patchwork
== Series Details ==

Series: Enable NV12 support (rev5)
URL   : https://patchwork.freedesktop.org/series/41674/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4150 -> Patchwork_8922 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41674/revisions/5/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8922 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-skl-guc: PASS -> FAIL (fdo#105900, fdo#104699) +1

igt@gem_ringfill@basic-default-hang:
  fi-pnv-d510:NOTRUN -> DMESG-WARN (fdo#101600)

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
  fi-hsw-4770r:   PASS -> FAIL (fdo#103481)


 Possible fixes 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-skl-guc: FAIL (fdo#103928) -> PASS

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   DMESG-FAIL (fdo#102614, fdo#106103) -> PASS

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-skl-6700k2:  FAIL (fdo#103191, fdo#104724) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-glk-j4005:   DMESG-WARN (fdo#106097) -> PASS


  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104699 https://bugs.freedesktop.org/show_bug.cgi?id=104699
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103


== Participating hosts (38 -> 36) ==

  Additional (2): fi-kbl-7560u fi-pnv-d510 
  Missing(4): fi-byt-j1900 fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4150 -> Patchwork_8922

  CI_DRM_4150: 93d32416ba4b1dae9451fec28aaa71915d770f51 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4463: 91b5a3ef5516b29584ea4567b0f5ffa18219b29f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8922: f016aabaa90d06bf1e8864e8be93af778aec8f3b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4463: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

f016aabaa90d drm/i915: Add NV12 as supported format for sprite plane
13186f16b914 drm/i915: Add NV12 as supported format for primary plane
55476785ac40 drm/i915: Add NV12 support to intel_framebuffer_init
b20488dc6d37 drm/i915: Add skl_check_nv12_surface for NV12
d34c1535d7c0 drm/i915: Enable Display WA 0528
8c98580b339e drm/i915: Enable display workaround 827 for all planes, v2.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8922/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915: Speed up idle detection by kicking the tasklets

2018-05-07 Thread Chris Wilson
Quoting Mika Kuoppala (2018-05-07 09:54:27)
> Chris Wilson  writes:
> 
> > Quoting Mika Kuoppala (2018-05-07 09:34:24)
> >> Chris Wilson  writes:
> >> 
> >> > We rely on ksoftirqd to run in a timely fashion in order to drain the
> >> > execlists queue. Quite frequently, it does not. In some cases we may see
> >> > latencies of over 200ms triggering our idle timeouts and forcing us to
> >> > declare the driver wedged!
> >> >
> >> > Thus we can speed up idle detection by bypassing ksoftirqd in these
> >> > cases and flush our tasklet to confirm if we are indeed still waiting
> >> > for the ELSP to drain.
> >> >
> >> > v2: Put the execlists.first check back; it is required for handling
> >> > reset!
> >> >
> >> > References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
> >> > Signed-off-by: Chris Wilson 
> >> > Cc: Tvrtko Ursulin 
> >> > Cc: Mika Kuoppala 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_engine_cs.c | 15 ---
> >> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> >> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> > index 70325e0824e3..a3111511ea1d 100644
> >> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> >> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> > @@ -945,10 +945,19 @@ bool intel_engine_is_idle(struct intel_engine_cs 
> >> > *engine)
> >> >   return true;
> >> >  
> >> >   /* Waiting to drain ELSP? */
> >> > - if (READ_ONCE(engine->execlists.active))
> >> > - return false;
> >> > + if (READ_ONCE(engine->execlists.active)) {
> >> > + struct intel_engine_execlists *execlists = 
> >> > >execlists;
> >> > +
> >> > + if (tasklet_trylock(>tasklet)) {
> >> 
> >> Now that we have the lock, sample active again to catch
> >> the late tasklet run and skip running if so?
> >
> > It becomes a nop in the submission tasklet, it's not dangerous. So it
> > comes down to what looks less of a wart!
> 
> The nice side effect of this kick is that now the hangcheck also won't
> fall a victim.
> 
> Should we have a test which adds random and long tasklet delays?

We do, it's called userspace :)

We stumbled across a good way of using a RT hog to delay ksoftirqd
arbitrarily; it just has the requirement of forcing the tasklet onto the
ksoftirqd for the same cpu...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915: Speed up idle detection by kicking the tasklets

2018-05-07 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2018-05-07 09:34:24)
>> Chris Wilson  writes:
>> 
>> > We rely on ksoftirqd to run in a timely fashion in order to drain the
>> > execlists queue. Quite frequently, it does not. In some cases we may see
>> > latencies of over 200ms triggering our idle timeouts and forcing us to
>> > declare the driver wedged!
>> >
>> > Thus we can speed up idle detection by bypassing ksoftirqd in these
>> > cases and flush our tasklet to confirm if we are indeed still waiting
>> > for the ELSP to drain.
>> >
>> > v2: Put the execlists.first check back; it is required for handling
>> > reset!
>> >
>> > References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
>> > Signed-off-by: Chris Wilson 
>> > Cc: Tvrtko Ursulin 
>> > Cc: Mika Kuoppala 
>> > ---
>> >  drivers/gpu/drm/i915/intel_engine_cs.c | 15 ---
>> >  1 file changed, 12 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
>> > b/drivers/gpu/drm/i915/intel_engine_cs.c
>> > index 70325e0824e3..a3111511ea1d 100644
>> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>> > @@ -945,10 +945,19 @@ bool intel_engine_is_idle(struct intel_engine_cs 
>> > *engine)
>> >   return true;
>> >  
>> >   /* Waiting to drain ELSP? */
>> > - if (READ_ONCE(engine->execlists.active))
>> > - return false;
>> > + if (READ_ONCE(engine->execlists.active)) {
>> > + struct intel_engine_execlists *execlists = 
>> > >execlists;
>> > +
>> > + if (tasklet_trylock(>tasklet)) {
>> 
>> Now that we have the lock, sample active again to catch
>> the late tasklet run and skip running if so?
>
> It becomes a nop in the submission tasklet, it's not dangerous. So it
> comes down to what looks less of a wart!

The nice side effect of this kick is that now the hangcheck also won't
fall a victim.

Should we have a test which adds random and long tasklet delays?

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


Re: [Intel-gfx] [PATCH 1/2] x86/gpu: reserve ICL's graphics stolen memory

2018-05-07 Thread Joonas Lahtinen
Ingo, do you prefer to merge through our tree with your ack?

Quoting Paulo Zanoni (2018-05-04 23:32:51)
> ICL changes the registers and addresses to 64 bits.
> 
> I also briefly looked at implementing an u64 version of the PCI config
> read functions, but I concluded this wouldn't be trivial, so it's not
> worth doing it for a single user that can't have any racing problems
> while reading the register in two separate operations.
> 
> v2:
>  - Scrub the development (non-public) changelog (Joonas).
>  - Remove the i915.ko bits so this can be easily backported in order
>to properly avoid stolen memory even on machines without i915.ko
>(Joonas).
>  - CC stable for the reasons above.
> 
> Issue: VIZ-9250

Fixes: 412310019a20 ("drm/i915/icl: Add initial Icelake definitions.")

> CC: sta...@vger.kernel.org

This should not be needed, it was introduced in v4.17-rc1 only.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

> Cc: Ingo Molnar 
> Cc: H. Peter Anvin 
> Cc: x...@kernel.org
> Cc: Daniele Ceraolo Spurio 
> Cc: Joonas Lahtinen 
> Signed-off-by: Paulo Zanoni 
> ---
>  arch/x86/kernel/early-quirks.c | 18 ++
>  include/drm/i915_drm.h |  4 +++-
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index bae0d32e327b..72c2cf961d44 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -340,6 +340,18 @@ static resource_size_t __init gen3_stolen_base(int num, 
> int slot, int func,
> return bsm & INTEL_BSM_MASK;
>  }
>  
> +static resource_size_t __init gen11_stolen_base(int num, int slot, int func,
> +   resource_size_t stolen_size)
> +{
> +   u64 bsm;
> +
> +   bsm = read_pci_config(num, slot, func, INTEL_GEN11_BSM_DW0);
> +   bsm &= INTEL_BSM_MASK;
> +   bsm |= (u64)read_pci_config(num, slot, func, INTEL_GEN11_BSM_DW1) << 
> 32;
> +
> +   return bsm;
> +}
> +
>  static resource_size_t __init i830_stolen_size(int num, int slot, int func)
>  {
> u16 gmch_ctrl;
> @@ -500,6 +512,11 @@ static const struct intel_early_ops chv_early_ops 
> __initconst = {
> .stolen_size = chv_stolen_size,
>  };
>  
> +static const struct intel_early_ops gen11_early_ops __initconst = {
> +   .stolen_base = gen11_stolen_base,
> +   .stolen_size = gen9_stolen_size,
> +};
> +
>  static const struct pci_device_id intel_early_ids[] __initconst = {
> INTEL_I830_IDS(_early_ops),
> INTEL_I845G_IDS(_early_ops),
> @@ -531,6 +548,7 @@ static const struct pci_device_id intel_early_ids[] 
> __initconst = {
> INTEL_CFL_IDS(_early_ops),
> INTEL_GLK_IDS(_early_ops),
> INTEL_CNL_IDS(_early_ops),
> +   INTEL_ICL_11_IDS(_early_ops),
>  };
>  
>  struct resource intel_graphics_stolen_res __ro_after_init = 
> DEFINE_RES_MEM(0, 0);
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index c9e5a6621b95..c44703f471b3 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -95,7 +95,9 @@ extern struct resource intel_graphics_stolen_res;
>  #defineI845_TSEG_SIZE_512K (2 << 1)
>  #defineI845_TSEG_SIZE_1M   (3 << 1)
>  
> -#define INTEL_BSM 0x5c
> +#define INTEL_BSM  0x5c
> +#define INTEL_GEN11_BSM_DW00xc0
> +#define INTEL_GEN11_BSM_DW10xc4
>  #define   INTEL_BSM_MASK   (-(1u << 20))
>  
>  #endif /* _I915_DRM_H_ */
> -- 
> 2.14.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Flush submission tasklet after bumping priority (rev2)

2018-05-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Flush submission tasklet after 
bumping priority (rev2)
URL   : https://patchwork.freedesktop.org/series/42783/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4150_full -> Patchwork_8920_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8920_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8920_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42783/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8920_full:

  === IGT changes ===

 Possible regressions 

igt@drv_hangman@error-state-capture-bsd:
  shard-glk:  PASS -> DMESG-WARN +5

igt@gem_eio@reset-stress:
  shard-glk:  PASS -> DMESG-FAIL +1
  shard-kbl:  PASS -> DMESG-FAIL +1

igt@gem_eio@wait-immediate:
  shard-apl:  PASS -> DMESG-FAIL

igt@gem_ringfill@basic-default-hang:
  shard-kbl:  PASS -> DMESG-WARN +13

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt:
  shard-apl:  PASS -> FAIL +5

igt@kms_vblank@pipe-b-wait-busy-hang:
  shard-kbl:  PASS -> FAIL +3

igt@kms_vblank@pipe-c-query-forked-hang:
  shard-apl:  PASS -> DMESG-WARN +6

igt@pm_rpm@gem-idle:
  shard-glk:  PASS -> FAIL +5


 Warnings 

igt@gem_exec_schedule@preempt-hang-bsd:
  shard-glk:  PASS -> SKIP +1

igt@gem_mocs_settings@mocs-rc6-render:
  shard-kbl:  SKIP -> PASS +1

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP +2

igt@kms_flip@flip-vs-modeset-vs-hang:
  shard-apl:  PASS -> SKIP +1


== Known issues ==

  Here are the changes found in Patchwork_8920_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_contexts:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@drv_selftest@live_hangcheck:
  shard-apl:  PASS -> INCOMPLETE (fdo#103927)
  shard-glk:  PASS -> INCOMPLETE (k.org#198133, fdo#103359)

igt@gem_eio@execbuf:
  shard-glk:  PASS -> FAIL (fdo#105957) +19

igt@gem_eio@in-flight-immediate:
  shard-apl:  PASS -> FAIL (fdo#105957) +20

igt@gem_eio@suspend:
  shard-kbl:  PASS -> FAIL (fdo#105957) +18

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-apl:  PASS -> FAIL (fdo#106087)

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368) +1

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#105707)

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
  shard-hsw:  PASS -> FAIL (fdo#103481)

igt@kms_rotation_crc@sprite-rotation-180:
  shard-hsw:  PASS -> FAIL (fdo#104724, fdo#103925) +1


 Possible fixes 

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-kbl:  FAIL (fdo#100368) -> PASS

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_flip@plain-flip-fb-recreate:
  shard-glk:  FAIL (fdo#100368) -> PASS +2

igt@kms_frontbuffer_tracking@fbc-farfromfence:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +12

igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
  shard-apl:  FAIL (fdo#104724, fdo#103166) -> PASS

igt@kms_rotation_crc@primary-rotation-90:
  shard-apl:  FAIL (fdo#104724, fdo#103925) -> PASS


 Warnings 

igt@gem_eio@hibernate:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> FAIL 
(fdo#105957)


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957
  fdo#106087 

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 2:08 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> Op 07-05-18 om 10:34 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, May 7, 2018 1:59 PM
> >> To: Srinivas, Vidya ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >> supported format for sprite plane
> >>
> >> Op 07-05-18 om 10:29 schreef Srinivas, Vidya:
>  -Original Message-
>  From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>  Sent: Monday, May 7, 2018 1:55 PM
>  To: Srinivas, Vidya ; intel-
>  g...@lists.freedesktop.org
>  Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
>  supported format for sprite plane
> 
>  Op 07-05-18 om 10:20 schreef Srinivas, Vidya:
> >> -Original Message-
> >> From: Srinivas, Vidya
> >> Sent: Monday, May 7, 2018 1:46 PM
> >> To: 'Maarten Lankhorst' ;
> >> intel- g...@lists.freedesktop.org
> >> Subject: RE: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >> supported format for sprite plane
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Maarten Lankhorst
> >>> [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Monday, May 7, 2018 1:44 PM
> >>> To: Srinivas, Vidya ; intel-
> >>> g...@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>> supported format for sprite plane
> >>>
> >>> Op 07-05-18 om 10:11 schreef Srinivas, Vidya:
> > -Original Message-
> > From: Maarten Lankhorst
> > [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Monday, May 7, 2018 1:38 PM
> > To: Srinivas, Vidya ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> > supported format for sprite plane
> >
> > Op 06-05-18 om 19:44 schreef Vidya Srinivas:
> >> From: Chandra Konduru 
> >>
> >> This patch adds NV12 to list of supported formats for sprite
> plane.
> >>
> >> v2: Rebased (me)
> >>
> >> v3: Review comments by Ville addressed
> >> - Removed skl_plane_formats_with_nv12 and added
> >> NV12 case in existing skl_plane_formats
> >> - Added the 10bpc RGB formats
> >>
> >> v4: Addressed review comments from Clinton A Taylor "Why
> are
> >> we
> > adding
> >> 10 bit RGB formats with the NV12 series patches?
> >> Trying to set XR30 or AB30 results in error returned even
> >> though the modes are advertised for the planes"
> >> - Removed 10bit RGB formats added previously with NV12
> series
> >>
> >> v5: Missed the Tested-by/Reviewed-by in the previous series
> >> Adding the same to commit message in this version.
> >> Addressed review comments from Clinton A Taylor "Why are
> we
> >> adding
> >> 10 bit RGB formats with the NV12 series patches?
> >> Trying to set XR30 or AB30 results in error returned even
> >> though the modes are advertised for the planes"
> >> - Previous version has 10bit RGB format removed from VLV
> >> formats by mistake. Fixing that in this version.
> >> Removed 10bit RGB formats added previously with NV12 series
> >> for
> >> SKL.
> >> v6: Addressed review comments by Ville Restricting the NV12
> >> to BXT and PIPE A and B
> >>
> >> v7: Rebased (me)
> >>
> >> v8: Rebased (me)
> >> Restricting NV12 changes to BXT and KBL Restricting NV12
> >> changes for plane 0 (overlay)
> >>
> >> v9: Rebased (me)
> >>
> >> v10: Addressed review comments from Maarten.
> >> Adding NV12 to skl_plane_formats itself.
> >>
> >> v11: Addressed review comments from Shashank Sharma
> >>
> >> v12: Addressed review comments from Shashank Sharma Made
> >> the
> > condition
> >> in intel_sprite_plane_create simple and easy to read as
> >> suggested.
> >> v13: Adding reviewed by tag from Shashank Sharma Addressed
>  review
> >> comments from Juha-Pekka Heikkila
> >> "NV12 not to be supported by SKL"
> >>
> >> v14: Addressed review comments from Ville Added
> >> skl_planar_formats
> >> 

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Maarten Lankhorst
Op 07-05-18 om 10:34 schreef Srinivas, Vidya:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Monday, May 7, 2018 1:59 PM
>> To: Srinivas, Vidya ; intel-
>> g...@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
>> format for sprite plane
>>
>> Op 07-05-18 om 10:29 schreef Srinivas, Vidya:
 -Original Message-
 From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
 Sent: Monday, May 7, 2018 1:55 PM
 To: Srinivas, Vidya ; intel-
 g...@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
 supported format for sprite plane

 Op 07-05-18 om 10:20 schreef Srinivas, Vidya:
>> -Original Message-
>> From: Srinivas, Vidya
>> Sent: Monday, May 7, 2018 1:46 PM
>> To: 'Maarten Lankhorst' ; intel-
>> g...@lists.freedesktop.org
>> Subject: RE: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
>> supported format for sprite plane
>>
>>
>>
>>> -Original Message-
>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>>> Sent: Monday, May 7, 2018 1:44 PM
>>> To: Srinivas, Vidya ; intel-
>>> g...@lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
>>> supported format for sprite plane
>>>
>>> Op 07-05-18 om 10:11 schreef Srinivas, Vidya:
> -Original Message-
> From: Maarten Lankhorst
> [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 1:38 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> supported format for sprite plane
>
> Op 06-05-18 om 19:44 schreef Vidya Srinivas:
>> From: Chandra Konduru 
>>
>> This patch adds NV12 to list of supported formats for sprite plane.
>>
>> v2: Rebased (me)
>>
>> v3: Review comments by Ville addressed
>> - Removed skl_plane_formats_with_nv12 and added
>> NV12 case in existing skl_plane_formats
>> - Added the 10bpc RGB formats
>>
>> v4: Addressed review comments from Clinton A Taylor "Why are
>> we
> adding
>> 10 bit RGB formats with the NV12 series patches?
>> Trying to set XR30 or AB30 results in error returned even
>> though the modes are advertised for the planes"
>> - Removed 10bit RGB formats added previously with NV12 series
>>
>> v5: Missed the Tested-by/Reviewed-by in the previous series
>> Adding the same to commit message in this version.
>> Addressed review comments from Clinton A Taylor "Why are we
>> adding
>> 10 bit RGB formats with the NV12 series patches?
>> Trying to set XR30 or AB30 results in error returned even
>> though the modes are advertised for the planes"
>> - Previous version has 10bit RGB format removed from VLV
>> formats by mistake. Fixing that in this version.
>> Removed 10bit RGB formats added previously with NV12 series
>> for
>> SKL.
>> v6: Addressed review comments by Ville Restricting the NV12 to
>> BXT and PIPE A and B
>>
>> v7: Rebased (me)
>>
>> v8: Rebased (me)
>> Restricting NV12 changes to BXT and KBL Restricting NV12
>> changes for plane 0 (overlay)
>>
>> v9: Rebased (me)
>>
>> v10: Addressed review comments from Maarten.
>> Adding NV12 to skl_plane_formats itself.
>>
>> v11: Addressed review comments from Shashank Sharma
>>
>> v12: Addressed review comments from Shashank Sharma Made
>> the
> condition
>> in intel_sprite_plane_create simple and easy to read as
>> suggested.
>> v13: Adding reviewed by tag from Shashank Sharma Addressed
 review
>> comments from Juha-Pekka Heikkila
>> "NV12 not to be supported by SKL"
>>
>> v14: Addressed review comments from Ville Added
>> skl_planar_formats
>> to include NV12 and a check skl_plane_has_planar in sprite
>> create Added
>> NV12 format to skl_mod_supported. These were review
>> comments
>>> from
>> Kristian Høgsberg 
>>
>> v15: Added reviewed by from Juha-Pekka Heikkila
>>
>> v16: Rebased the series
>>
>> v17: Added all tiling under mod supported for NV12 Credits to
>> Megha Aggarwal
>>
>> v18: Added RB by Maarten and Kristian
>>
>> Credits-to: Megha Aggarwal 

Re: [Intel-gfx] [PATCH v2] drm/i915: Speed up idle detection by kicking the tasklets

2018-05-07 Thread Chris Wilson
Quoting Mika Kuoppala (2018-05-07 09:34:24)
> Chris Wilson  writes:
> 
> > We rely on ksoftirqd to run in a timely fashion in order to drain the
> > execlists queue. Quite frequently, it does not. In some cases we may see
> > latencies of over 200ms triggering our idle timeouts and forcing us to
> > declare the driver wedged!
> >
> > Thus we can speed up idle detection by bypassing ksoftirqd in these
> > cases and flush our tasklet to confirm if we are indeed still waiting
> > for the ELSP to drain.
> >
> > v2: Put the execlists.first check back; it is required for handling
> > reset!
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 15 ---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index 70325e0824e3..a3111511ea1d 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -945,10 +945,19 @@ bool intel_engine_is_idle(struct intel_engine_cs 
> > *engine)
> >   return true;
> >  
> >   /* Waiting to drain ELSP? */
> > - if (READ_ONCE(engine->execlists.active))
> > - return false;
> > + if (READ_ONCE(engine->execlists.active)) {
> > + struct intel_engine_execlists *execlists = >execlists;
> > +
> > + if (tasklet_trylock(>tasklet)) {
> 
> Now that we have the lock, sample active again to catch
> the late tasklet run and skip running if so?

It becomes a nop in the submission tasklet, it's not dangerous. So it
comes down to what looks less of a wart!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 1:59 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> Op 07-05-18 om 10:29 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, May 7, 2018 1:55 PM
> >> To: Srinivas, Vidya ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >> supported format for sprite plane
> >>
> >> Op 07-05-18 om 10:20 schreef Srinivas, Vidya:
>  -Original Message-
>  From: Srinivas, Vidya
>  Sent: Monday, May 7, 2018 1:46 PM
>  To: 'Maarten Lankhorst' ; intel-
>  g...@lists.freedesktop.org
>  Subject: RE: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
>  supported format for sprite plane
> 
> 
> 
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Monday, May 7, 2018 1:44 PM
> > To: Srinivas, Vidya ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> > supported format for sprite plane
> >
> > Op 07-05-18 om 10:11 schreef Srinivas, Vidya:
> >>> -Original Message-
> >>> From: Maarten Lankhorst
> >>> [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Monday, May 7, 2018 1:38 PM
> >>> To: Srinivas, Vidya ; intel-
> >>> g...@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>> supported format for sprite plane
> >>>
> >>> Op 06-05-18 om 19:44 schreef Vidya Srinivas:
>  From: Chandra Konduru 
> 
>  This patch adds NV12 to list of supported formats for sprite plane.
> 
>  v2: Rebased (me)
> 
>  v3: Review comments by Ville addressed
>  - Removed skl_plane_formats_with_nv12 and added
>  NV12 case in existing skl_plane_formats
>  - Added the 10bpc RGB formats
> 
>  v4: Addressed review comments from Clinton A Taylor "Why are
> we
> >>> adding
>  10 bit RGB formats with the NV12 series patches?
>  Trying to set XR30 or AB30 results in error returned even
>  though the modes are advertised for the planes"
>  - Removed 10bit RGB formats added previously with NV12 series
> 
>  v5: Missed the Tested-by/Reviewed-by in the previous series
>  Adding the same to commit message in this version.
>  Addressed review comments from Clinton A Taylor "Why are we
>  adding
>  10 bit RGB formats with the NV12 series patches?
>  Trying to set XR30 or AB30 results in error returned even
>  though the modes are advertised for the planes"
>  - Previous version has 10bit RGB format removed from VLV
>  formats by mistake. Fixing that in this version.
>  Removed 10bit RGB formats added previously with NV12 series
> for
>  SKL.
>  v6: Addressed review comments by Ville Restricting the NV12 to
>  BXT and PIPE A and B
> 
>  v7: Rebased (me)
> 
>  v8: Rebased (me)
>  Restricting NV12 changes to BXT and KBL Restricting NV12
>  changes for plane 0 (overlay)
> 
>  v9: Rebased (me)
> 
>  v10: Addressed review comments from Maarten.
>  Adding NV12 to skl_plane_formats itself.
> 
>  v11: Addressed review comments from Shashank Sharma
> 
>  v12: Addressed review comments from Shashank Sharma Made
> the
> >>> condition
>  in intel_sprite_plane_create simple and easy to read as
> suggested.
> 
>  v13: Adding reviewed by tag from Shashank Sharma Addressed
> >> review
>  comments from Juha-Pekka Heikkila
>  "NV12 not to be supported by SKL"
> 
>  v14: Addressed review comments from Ville Added
>  skl_planar_formats
>  to include NV12 and a check skl_plane_has_planar in sprite
>  create Added
>  NV12 format to skl_mod_supported. These were review
> comments
> > from
>  Kristian Høgsberg 
> 
>  v15: Added reviewed by from Juha-Pekka Heikkila
> 
>  v16: Rebased the series
> 
>  v17: Added all tiling under mod supported for NV12 Credits to
>  Megha Aggarwal
> 
>  v18: Added RB by Maarten and Kristian
> 
>  Credits-to: Megha Aggarwal 
>  

Re: [Intel-gfx] [PATCH v2] drm/i915: Speed up idle detection by kicking the tasklets

2018-05-07 Thread Mika Kuoppala
Chris Wilson  writes:

> We rely on ksoftirqd to run in a timely fashion in order to drain the
> execlists queue. Quite frequently, it does not. In some cases we may see
> latencies of over 200ms triggering our idle timeouts and forcing us to
> declare the driver wedged!
>
> Thus we can speed up idle detection by bypassing ksoftirqd in these
> cases and flush our tasklet to confirm if we are indeed still waiting
> for the ELSP to drain.
>
> v2: Put the execlists.first check back; it is required for handling
> reset!
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 70325e0824e3..a3111511ea1d 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -945,10 +945,19 @@ bool intel_engine_is_idle(struct intel_engine_cs 
> *engine)
>   return true;
>  
>   /* Waiting to drain ELSP? */
> - if (READ_ONCE(engine->execlists.active))
> - return false;
> + if (READ_ONCE(engine->execlists.active)) {
> + struct intel_engine_execlists *execlists = >execlists;
> +
> + if (tasklet_trylock(>tasklet)) {

Now that we have the lock, sample active again to catch
the late tasklet run and skip running if so?

-Mika

> + execlists->tasklet.func(execlists->tasklet.data);
> + tasklet_unlock(>tasklet);
> + }
> +
> + if (READ_ONCE(execlists->active))
> + return false;
> + }
>  
> - /* ELSP is empty, but there are ready requests? */
> + /* ELSP is empty, but there are ready requests? E.g. after reset */
>   if (READ_ONCE(engine->execlists.first))
>   return false;
>  
> -- 
> 2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


  1   2   >