Re: [Intel-gfx] [PATCH 1/6] drm/i915: Make a copy of the ggtt view for slave plane

2020-01-10 Thread Chris Wilson
Quoting Ville Syrjala (2020-01-10 18:32:23)
> From: Ville Syrjälä 
> 
> intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
> it is present. We copy that from the master plane to the slave plane,
> but we fail to copy the corresponding ggtt view. Thus when it comes time
> to pin the slave plane's fb we use some stale ggtt view left over from
> the last time the plane was used as a non-slave plane. If that previous
> use involved 90/270 degree rotation or remapping we'll try to shuffle
> the pages of the new fb around accordingingly. However the new
> fb may be backed by a bo with less pages than what the ggtt view
> rotation/remapped info requires, and so we we trip a GEM_BUG().
> 
> Steps to reproduce on icl:
> 1. plane 1: whatever
>plane 6: largish !NV12 fb + 90 degree rotation
> 2. plane 1: smallish NV12 fb
>plane 6: make invisible so it gets slaved to plane 1
> 3. GEM_BUG()
> 
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/951
> Fixes: 1f594b209fe1 ("drm/i915: Remove special case slave handling during hw 
> programming, v3.")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 59c375879186..fafb67689dee 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12366,6 +12366,7 @@ static int icl_check_nv12_planes(struct 
> intel_crtc_state *crtc_state)
> /* Copy parameters to slave plane */
> linked_state->ctl = plane_state->ctl | 
> PLANE_CTL_YUV420_Y_PLANE;
> linked_state->color_ctl = plane_state->color_ctl;
> +   linked_state->view = plane_state->view;
> memcpy(linked_state->color_plane, plane_state->color_plane,
>sizeof(linked_state->color_plane));

So this bit is just copying across the results of
intel_plane_compute_gtt()?

What happens for equivalent of intel_plane_needs_remap()?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add ops to intel_uc (rev3)

2020-01-10 Thread Patchwork
== Series Details ==

Series: Add ops to intel_uc (rev3)
URL   : https://patchwork.freedesktop.org/series/70716/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
bb5e4aea2877 drm/i915/uc: Add ops to intel_uc
-:142: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#142: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:73:
+#define intel_uc_ops_function(_NAME, _OPS, _TYPE, _RET) \
+static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
+{ \
+   if (uc->ops->_OPS) \
+   return uc->ops->_OPS(uc); \
+   return _RET; \
+}

-:142: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_OPS' - possible 
side-effects?
#142: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:73:
+#define intel_uc_ops_function(_NAME, _OPS, _TYPE, _RET) \
+static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
+{ \
+   if (uc->ops->_OPS) \
+   return uc->ops->_OPS(uc); \
+   return _RET; \
+}

-:142: CHECK:MACRO_ARG_PRECEDENCE: Macro argument '_OPS' may be better as 
'(_OPS)' to avoid precedence issues
#142: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:73:
+#define intel_uc_ops_function(_NAME, _OPS, _TYPE, _RET) \
+static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
+{ \
+   if (uc->ops->_OPS) \
+   return uc->ops->_OPS(uc); \
+   return _RET; \
+}

-:149: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#149: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:80:
+}
+intel_uc_ops_function(init_hw, init_hw, int, 0);

-:150: ERROR:SPACING: space prohibited before that close parenthesis ')'
#150: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:81:
+intel_uc_ops_function(fini_hw, fini_hw, void, );

total: 2 errors, 0 warnings, 3 checks, 117 lines checked
def878150533 drm/i915/uc: Add init_fw/fini_fw to to intel_uc_ops
-:87: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#87: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:80:
 }
+intel_uc_ops_function(fetch_firmwares, init_fw, void, );

-:87: ERROR:SPACING: space prohibited before that close parenthesis ')'
#87: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:80:
+intel_uc_ops_function(fetch_firmwares, init_fw, void, );

-:88: ERROR:SPACING: space prohibited before that close parenthesis ')'
#88: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:81:
+intel_uc_ops_function(cleanup_firmwares, fini_fw, void, );

total: 2 errors, 0 warnings, 1 checks, 63 lines checked
71565950a620 drm/i915/uc: Add init/fini to to intel_uc_ops
-:89: ERROR:SPACING: space prohibited before that close parenthesis ')'
#89: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:82:
+intel_uc_ops_function(init, init, void, );

-:90: ERROR:SPACING: space prohibited before that close parenthesis ')'
#90: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:83:
+intel_uc_ops_function(fini, fini, void, );

total: 2 errors, 0 warnings, 0 checks, 65 lines checked
0960b20d5549 drm/i915/uc: Add sanitize to to intel_uc_ops
-:74: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#74: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:80:
 }
+intel_uc_ops_function(sanitize, sanitize, int, 0);

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

___
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: Bump up CDCLK to eliminate underruns on TGL (rev4)

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev4)
URL   : https://patchwork.freedesktop.org/series/71760/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16060


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-8700k:   [PASS][1] -> [DMESG-WARN][2] ([i915#889])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8700k:   [PASS][3] -> [INCOMPLETE][4] ([i915#148])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-cfl-8700k/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-ivb-3770:[PASS][5] -> [DMESG-FAIL][6] ([i915#725])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-ivb-3770/igt@i915_selftest@live_blt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-ivb-3770/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [PASS][7] -> [DMESG-FAIL][8] ([i915#656])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][9] -> [INCOMPLETE][10] ([fdo#106070] / 
[i915#424])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][11] ([i915#816]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][13] ([i915#937]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-ehl-1/igt@gem_exec_gttf...@basic.html

  * igt@gem_render_linear_blits@basic:
- fi-icl-dsi: [DMESG-WARN][15] ([i915#109]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [INCOMPLETE][17] ([i915#472] / [i915#707]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-tgl-y/igt@gem_s...@basic-each.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][19] ([i915#553] / [i915#725]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [FAIL][21] -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16060/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#148]: https://gitlab.freedesktop.org/drm/intel/issues/148
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472
  [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#707]: https://gitlab.freedesktop.org/drm/intel/issues/707
  

[Intel-gfx] [PATCH 2/6] drm/i915: Clear old hw.fb & co. from slave plane's state

2020-01-10 Thread Ville Syrjala
From: Ville Syrjälä 

Let's do the intel_plane_copy_uapi_to_hw_state() before we bail out
due to both old and new uapi.crtc being NULL. This will drop the
reference to the old hw.fb for planes that are transitioning from
being a slave plane to simply being disabled.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_atomic_plane.c | 6 ++
 drivers/gpu/drm/i915/display/intel_display.c  | 2 ++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 3e97af682b1b..7c69b053005b 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -225,12 +225,9 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
struct intel_plane_state 
*new_plane_state)
 {
struct intel_plane *plane = to_intel_plane(new_plane_state->uapi.plane);
-   const struct drm_framebuffer *fb;
+   const struct drm_framebuffer *fb = new_plane_state->hw.fb;
int ret;
 
-   intel_plane_copy_uapi_to_hw_state(new_plane_state, new_plane_state);
-   fb = new_plane_state->hw.fb;
-
new_crtc_state->active_planes &= ~BIT(plane->id);
new_crtc_state->nv12_planes &= ~BIT(plane->id);
new_crtc_state->c8_planes &= ~BIT(plane->id);
@@ -292,6 +289,7 @@ int intel_plane_atomic_check(struct intel_atomic_state 
*state,
const struct intel_crtc_state *old_crtc_state;
struct intel_crtc_state *new_crtc_state;
 
+   intel_plane_copy_uapi_to_hw_state(new_plane_state, new_plane_state);
new_plane_state->uapi.visible = false;
if (!crtc)
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index fafb67689dee..0a1f2564dea0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16038,6 +16038,8 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
new_plane_state->uapi.crtc_w = crtc_w;
new_plane_state->uapi.crtc_h = crtc_h;
 
+   intel_plane_copy_uapi_to_hw_state(new_plane_state, new_plane_state);
+
ret = intel_plane_atomic_check_with_state(crtc_state, new_crtc_state,
  old_plane_state, 
new_plane_state);
if (ret)
-- 
2.24.1

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


[Intel-gfx] [PATCH 1/6] drm/i915: Make a copy of the ggtt view for slave plane

2020-01-10 Thread Ville Syrjala
From: Ville Syrjälä 

intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
it is present. We copy that from the master plane to the slave plane,
but we fail to copy the corresponding ggtt view. Thus when it comes time
to pin the slave plane's fb we use some stale ggtt view left over from
the last time the plane was used as a non-slave plane. If that previous
use involved 90/270 degree rotation or remapping we'll try to shuffle
the pages of the new fb around accordingingly. However the new
fb may be backed by a bo with less pages than what the ggtt view
rotation/remapped info requires, and so we we trip a GEM_BUG().

Steps to reproduce on icl:
1. plane 1: whatever
   plane 6: largish !NV12 fb + 90 degree rotation
2. plane 1: smallish NV12 fb
   plane 6: make invisible so it gets slaved to plane 1
3. GEM_BUG()

Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Closes: https://gitlab.freedesktop.org/drm/intel/issues/951
Fixes: 1f594b209fe1 ("drm/i915: Remove special case slave handling during hw 
programming, v3.")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 59c375879186..fafb67689dee 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12366,6 +12366,7 @@ static int icl_check_nv12_planes(struct 
intel_crtc_state *crtc_state)
/* Copy parameters to slave plane */
linked_state->ctl = plane_state->ctl | PLANE_CTL_YUV420_Y_PLANE;
linked_state->color_ctl = plane_state->color_ctl;
+   linked_state->view = plane_state->view;
memcpy(linked_state->color_plane, plane_state->color_plane,
   sizeof(linked_state->color_plane));
 
-- 
2.24.1

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


Re: [Intel-gfx] [PATCH 5/6] drm/i915: Balance prepare_fb/cleanup_fb

2020-01-10 Thread Chris Wilson
Quoting Ville Syrjala (2020-01-10 18:32:27)
> From: Ville Syrjälä 
> 
> intel_prepare_plane_fb() bails early if there is no fb (or rather
> no obj, which is the same thing). intel_cleanup_plane_fb() does not.
> This means the steps performed by intel_cleanup_plane_fb() aren't
> balanced with with what was done intel_prepare_plane_fb() if there
> is no fb for the plane. These hooks get called for every plane in
> the state regardless of whether they have an fb or not.
> 
> Add a matching null obj check to intel_cleanup_plane_fb() to restore
> the balance.
> 
> Note that intel_cleanup_plane_fb() has sufficient protections
> already in place that the imbalance doesn't cause any real problems.
> But having things be in balance seems nicer anyway, and might help
> avoid some surprises in the future.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 27b43822344b..f79a6376bbf0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15868,6 +15868,10 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
> struct intel_atomic_state *state =
> to_intel_atomic_state(old_plane_state->uapi.state);
> struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +   struct drm_i915_gem_object *obj = 
> intel_fb_obj(old_plane_state->hw.fb);
> +
> +   if (!obj)
> +   return;
>  
> if (state->rps_interactive) {
> intel_rps_mark_interactive(_priv->gt.rps, false);

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


Re: [Intel-gfx] [PATCH] drm/i915: add Wa_14010594013: icl,ehl

2020-01-10 Thread Rodrigo Vivi
On Fri, Jan 10, 2020 at 02:33:04PM +0530, Anshuamn Gupta wrote:
> On 2020-01-10 at 03:51:49 -0500, Matt Atwood wrote:
> > The bspec tells us we need to set this bit to avoid potential underruns.
> > 
> > Bspec: 33450
> > Bspec: 33451
> > Bspec: 33452
> It would be nice to add index 7386 which is having the bit for PMRSP.

Indeed. In the end 7386 was the only one that I needed here.
(Besides the HSD article)

Probably even better to have only the 7386. But up to Matt.

> > 
> > Signed-off-by: Matt Atwood 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 1 +
> >  drivers/gpu/drm/i915/intel_pm.c | 4 
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index cf770793be54..b9dc5e2ea606 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7785,6 +7785,7 @@ enum {
> >  
> >  #define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
> >  #define   SKL_SELECT_ALTERNATE_DC_EXIT (1 << 30)
> > +#define   CNL_DELAY_PMRSP  (1 << 22)
> >  #define   MASK_WAKEMEM (1 << 13)
> >  #define   CNL_DDI_CLOCK_REG_ACCESS_ON  (1 << 7)
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 148ac455dfa7..10714d43e8a3 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6610,6 +6610,10 @@ static void icl_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> > /* Wa_1407352427:icl,ehl */
> > intel_uncore_rmw(_priv->uncore, UNSLICE_UNIT_LEVEL_CLKGATE2,
> >  0, PSDUNIT_CLKGATE_DIS);
> > +
> > +   /*Wa_14010594013:icl, ehl */
> > +   I915_WRITE(GEN8_CHICKEN_DCPR_1,
> > +  I915_READ(GEN8_CHICKEN_DCPR_1) | CNL_DELAY_PMRSP);
> Is there any functional difference between Wa_14010594013 and above 
> Wa_1407352427

I couldn't find any hsd article with this new number
The one that Matt used seemed the correct one because it was the one
with all the info that I needed.

Reviewed-by: Rodrigo Vivi 

> using different family of writes, may be not related to this patch.
> Thanks,
> Anshuman Gupta.
> >  }
> >  
> >  static void tgl_init_clock_gating(struct drm_i915_private *dev_priv)
> > -- 
> > 2.21.1
> > 
> > ___
> > 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Validation rotated vma bounds are within the object (rev2)

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Validation rotated vma bounds are within the object (rev2)
URL   : https://patchwork.freedesktop.org/series/71827/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
933176d41e65 drm/i915/gt: Validate rotated vma bounds are within the object
-:25: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Matthew Auld 
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for Add ops to intel_uc (rev3)

2020-01-10 Thread Patchwork
== Series Details ==

Series: Add ops to intel_uc (rev3)
URL   : https://patchwork.freedesktop.org/series/70716/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16059


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#889])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-cfl-guc/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-cfl-guc/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [PASS][3] -> [DMESG-FAIL][4] ([i915#656])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_gt_engines:
- fi-cfl-8700k:   [PASS][5] -> [DMESG-FAIL][6] ([i915#889]) +7 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-cfl-8700k/igt@i915_selftest@live_gt_engines.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-cfl-8700k/igt@i915_selftest@live_gt_engines.html

  * igt@i915_selftest@live_gt_pm:
- fi-cfl-8700k:   [PASS][7] -> [DMESG-WARN][8] ([i915#889]) +23 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-cfl-8700k/igt@i915_selftest@live_gt_pm.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-cfl-8700k/igt@i915_selftest@live_gt_pm.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [PASS][9] -> [DMESG-WARN][10] ([i915#44])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][11] ([i915#937]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-ehl-1/igt@gem_exec_gttf...@basic.html

  * igt@gem_render_linear_blits@basic:
- fi-icl-dsi: [DMESG-WARN][13] ([i915#109]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [INCOMPLETE][15] ([i915#472] / [i915#707]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-tgl-y/igt@gem_s...@basic-each.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][17] ([i915#553] / [i915#725]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16059/fi-hsw-4770/igt@i915_selftest@live_blt.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44
  [i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472
  [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#707]: https://gitlab.freedesktop.org/drm/intel/issues/707
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#889]: https://gitlab.freedesktop.org/drm/intel/issues/889
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (47 -> 40)
--

  Additional (4): fi-hsw-4770r fi-ilk-650 fi-byt-n2820 fi-snb-2520m 
  Missing(11): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 
fi-kbl-7500u fi-ctg-p8600 fi-gdg-551 fi-ivb-3770 fi-byt-clapper fi-skl-6600u 
fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7721 -> Patchwork_16059

  CI-20190529: 20190529
  CI_DRM_7721: 3a2436c56fcf2d133d701a112eb1e0dfce0b846d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5364: b7cb6ffdb65cbd233f5ddee2f2dabf97b34fa640 @ 

Re: [Intel-gfx] [PATCH 4/6] drm/i915: s/intel_state/state/ in intel_{prepare, cleanup}_plane_fb()

2020-01-10 Thread Chris Wilson
Quoting Ville Syrjala (2020-01-10 18:32:26)
> From: Ville Syrjälä 
> 
> Drop the redundant intel_ prefix from our atomic state variable.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 22 ++--
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0df0719b0ac3..27b43822344b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15755,18 +15755,18 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> struct intel_plane *plane = to_intel_plane(_plane);
> struct intel_plane_state *new_plane_state =
> to_intel_plane_state(_new_plane_state);
> -   struct intel_atomic_state *intel_state =
> +   struct intel_atomic_state *state =

Ah, 3&4
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 6/6] drm/i915: Cleanup properly if the implicit fence setup fails

2020-01-10 Thread Ville Syrjala
From: Ville Syrjälä 

We've already pinned the vma and fence by the time we try to
deal with implicit fencing. Properly unpin the vma and fence
if the fence setup fails instead of just bailing straight out
from .prepare_fb(). As can be expected
drm_atomic_helper_prepare_planes() will not call .cleanup_fb()
for the plane whose .prepare_fb() failed so we must do the
cleanup ourself.

v2: Rebase

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f79a6376bbf0..96e71204b86f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15823,7 +15823,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
  false, I915_FENCE_TIMEOUT,
  GFP_KERNEL);
if (ret < 0)
-   return ret;
+   goto unpin_fb;
 
fence = dma_resv_get_excl_rcu(obj->base.resv);
if (fence) {
@@ -15850,6 +15850,11 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
}
 
return 0;
+
+unpin_fb:
+   intel_plane_unpin_fb(new_plane_state);
+
+   return ret;
 }
 
 /**
-- 
2.24.1

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


[Intel-gfx] [PATCH 5/6] drm/i915: Balance prepare_fb/cleanup_fb

2020-01-10 Thread Ville Syrjala
From: Ville Syrjälä 

intel_prepare_plane_fb() bails early if there is no fb (or rather
no obj, which is the same thing). intel_cleanup_plane_fb() does not.
This means the steps performed by intel_cleanup_plane_fb() aren't
balanced with with what was done intel_prepare_plane_fb() if there
is no fb for the plane. These hooks get called for every plane in
the state regardless of whether they have an fb or not.

Add a matching null obj check to intel_cleanup_plane_fb() to restore
the balance.

Note that intel_cleanup_plane_fb() has sufficient protections
already in place that the imbalance doesn't cause any real problems.
But having things be in balance seems nicer anyway, and might help
avoid some surprises in the future.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 27b43822344b..f79a6376bbf0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15868,6 +15868,10 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
struct intel_atomic_state *state =
to_intel_atomic_state(old_plane_state->uapi.state);
struct drm_i915_private *dev_priv = to_i915(plane->dev);
+   struct drm_i915_gem_object *obj = intel_fb_obj(old_plane_state->hw.fb);
+
+   if (!obj)
+   return;
 
if (state->rps_interactive) {
intel_rps_mark_interactive(_priv->gt.rps, false);
-- 
2.24.1

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


[Intel-gfx] [PATCH 3/6] drm/i915: Stop looking at plane->state in intel_prepare_plane_fb()

2020-01-10 Thread Ville Syrjala
From: Ville Syrjälä 

Switch over to using explicit old/new planes states instead of
digging the old state out via plane->state. The main issue is that
plane->state will point to the uapi state which we generally don't
even want to look at.

Also it sets a bad example as using plane->state during commit_tail()
would be a bug. Here we're still holding the modeset locks so it's
actually safe, but best not give people bad ideas.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0a1f2564dea0..0df0719b0ac3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15749,23 +15749,25 @@ static void fb_obj_bump_render_priority(struct 
drm_i915_gem_object *obj)
  * Returns 0 on success, negative error code on failure.
  */
 int
-intel_prepare_plane_fb(struct drm_plane *plane,
+intel_prepare_plane_fb(struct drm_plane *_plane,
   struct drm_plane_state *_new_plane_state)
 {
+   struct intel_plane *plane = to_intel_plane(_plane);
struct intel_plane_state *new_plane_state =
to_intel_plane_state(_new_plane_state);
struct intel_atomic_state *intel_state =
to_intel_atomic_state(new_plane_state->uapi.state);
-   struct drm_i915_private *dev_priv = to_i915(plane->dev);
-   struct drm_framebuffer *fb = new_plane_state->hw.fb;
-   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
-   struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   const struct intel_plane_state *old_plane_state =
+   intel_atomic_get_old_plane_state(intel_state, plane);
+   struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
+   struct drm_i915_gem_object *old_obj = 
intel_fb_obj(old_plane_state->hw.fb);
int ret;
 
if (old_obj) {
-   struct intel_crtc_state *crtc_state =
+   const struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(intel_state,
-   
to_intel_crtc(plane->state->crtc));
+   
to_intel_crtc(old_plane_state->hw.crtc));
 
/* Big Hammer, we also need to ensure that any pending
 * MI_WAIT_FOR_EVENT inside a user batch buffer on the
-- 
2.24.1

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


[Intel-gfx] [PATCH 4/6] drm/i915: s/intel_state/state/ in intel_{prepare, cleanup}_plane_fb()

2020-01-10 Thread Ville Syrjala
From: Ville Syrjälä 

Drop the redundant intel_ prefix from our atomic state variable.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 22 ++--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0df0719b0ac3..27b43822344b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15755,18 +15755,18 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
struct intel_plane *plane = to_intel_plane(_plane);
struct intel_plane_state *new_plane_state =
to_intel_plane_state(_new_plane_state);
-   struct intel_atomic_state *intel_state =
+   struct intel_atomic_state *state =
to_intel_atomic_state(new_plane_state->uapi.state);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct intel_plane_state *old_plane_state =
-   intel_atomic_get_old_plane_state(intel_state, plane);
+   intel_atomic_get_old_plane_state(state, plane);
struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
struct drm_i915_gem_object *old_obj = 
intel_fb_obj(old_plane_state->hw.fb);
int ret;
 
if (old_obj) {
const struct intel_crtc_state *crtc_state =
-   intel_atomic_get_new_crtc_state(intel_state,
+   intel_atomic_get_new_crtc_state(state,

to_intel_crtc(old_plane_state->hw.crtc));
 
/* Big Hammer, we also need to ensure that any pending
@@ -15781,7 +15781,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
 * can safely continue.
 */
if (needs_modeset(crtc_state)) {
-   ret = 
i915_sw_fence_await_reservation(_state->commit_ready,
+   ret = 
i915_sw_fence_await_reservation(>commit_ready,
  
old_obj->base.resv, NULL,
  false, 0,
  GFP_KERNEL);
@@ -15791,7 +15791,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
}
 
if (new_plane_state->uapi.fence) { /* explicit fencing */
-   ret = i915_sw_fence_await_dma_fence(_state->commit_ready,
+   ret = i915_sw_fence_await_dma_fence(>commit_ready,
new_plane_state->uapi.fence,
I915_FENCE_TIMEOUT,
GFP_KERNEL);
@@ -15818,7 +15818,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
if (!new_plane_state->uapi.fence) { /* implicit fencing */
struct dma_fence *fence;
 
-   ret = 
i915_sw_fence_await_reservation(_state->commit_ready,
+   ret = i915_sw_fence_await_reservation(>commit_ready,
  obj->base.resv, NULL,
  false, I915_FENCE_TIMEOUT,
  GFP_KERNEL);
@@ -15844,9 +15844,9 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
 * that are not quite steady state without resorting to forcing
 * maximum clocks following a vblank miss (see do_rps_boost()).
 */
-   if (!intel_state->rps_interactive) {
+   if (!state->rps_interactive) {
intel_rps_mark_interactive(_priv->gt.rps, true);
-   intel_state->rps_interactive = true;
+   state->rps_interactive = true;
}
 
return 0;
@@ -15865,13 +15865,13 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
 {
struct intel_plane_state *old_plane_state =
to_intel_plane_state(_old_plane_state);
-   struct intel_atomic_state *intel_state =
+   struct intel_atomic_state *state =
to_intel_atomic_state(old_plane_state->uapi.state);
struct drm_i915_private *dev_priv = to_i915(plane->dev);
 
-   if (intel_state->rps_interactive) {
+   if (state->rps_interactive) {
intel_rps_mark_interactive(_priv->gt.rps, false);
-   intel_state->rps_interactive = false;
+   state->rps_interactive = false;
}
 
/* Should only be called after a successful intel_prepare_plane_fb()! */
-- 
2.24.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 drm/i915/gt: Validation rotated vma bounds are within the object (rev2)

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Validation rotated vma bounds are within the object (rev2)
URL   : https://patchwork.freedesktop.org/series/71827/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7720 -> Patchwork_16056


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [PASS][1] -> [TIMEOUT][2] ([i915#816])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6770hq:  [PASS][3] -> [DMESG-WARN][4] ([i915#889])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[PASS][5] -> [DMESG-FAIL][6] ([i915#725])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][7] -> [INCOMPLETE][8] ([fdo#106070] / 
[i915#424])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html

  * igt@i915_selftest@live_hangcheck:
- fi-skl-guc: [PASS][9] -> [INCOMPLETE][10] ([fdo#108744])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-skl-guc/igt@i915_selftest@live_hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-skl-guc/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@dp-edid-read:
- fi-icl-u2:  [PASS][11] -> [FAIL][12] ([fdo#109635] / [i915#217])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][13] -> [FAIL][14] ([fdo#111096] / [i915#323])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_exec_parallel@basic:
- {fi-ehl-1}: [INCOMPLETE][15] ([i915#937]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-ehl-1/igt@gem_exec_paral...@basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-ehl-1/igt@gem_exec_paral...@basic.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770r:   [DMESG-FAIL][17] ([i915#770]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-hsw-4770r/igt@i915_selftest@live_blt.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [FAIL][19] ([i915#178]) -> [INCOMPLETE][20] 
([i915#151])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16056/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
  [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#770]: https://gitlab.freedesktop.org/drm/intel/issues/770
  [i915#816]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (rev3)

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block 
(rev3)
URL   : https://patchwork.freedesktop.org/series/71581/
State : failure

== Summary ==

Applying: drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block 
(v3)
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_dsi.h
M   drivers/gpu/drm/i915/display/intel_dsi_vbt.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

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


[Intel-gfx] [CI v4 3/4] drm/i915/uc: Add init/fini to to intel_uc_ops

2020-01-10 Thread Michal Wajdeczko
uC preparation and cleanup steps are only meaningful if we are
running with uC enabled. Make these functions part of the uc_ops.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  6 --
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index cd0742f9ba4d..105b7792c9a0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -273,14 +273,13 @@ static void __uc_cleanup_firmwares(struct intel_uc *uc)
intel_uc_fw_cleanup_fetch(>guc.fw);
 }
 
-void intel_uc_init(struct intel_uc *uc)
+static void __uc_init(struct intel_uc *uc)
 {
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
int ret;
 
-   if (!intel_uc_uses_guc(uc))
-   return;
+   GEM_BUG_ON(!intel_uc_uses_guc(uc));
 
/* XXX: GuC submission is unavailable for now */
GEM_BUG_ON(intel_uc_supports_guc_submission(uc));
@@ -295,7 +294,7 @@ void intel_uc_init(struct intel_uc *uc)
intel_huc_init(huc);
 }
 
-void intel_uc_fini(struct intel_uc *uc)
+static void __uc_fini(struct intel_uc *uc)
 {
intel_huc_fini(>huc);
intel_guc_fini(>guc);
@@ -619,6 +618,9 @@ static const struct intel_uc_ops uc_ops_on = {
.init_fw = __uc_fetch_firmwares,
.fini_fw = __uc_cleanup_firmwares,
 
+   .init = __uc_init,
+   .fini = __uc_fini,
+
.init_hw = __uc_init_hw,
.fini_hw = __uc_fini_hw,
 };
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 47c7c8add451..8c0ce0d9f190 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -15,6 +15,8 @@ struct intel_uc;
 struct intel_uc_ops {
void (*init_fw)(struct intel_uc *uc);
void (*fini_fw)(struct intel_uc *uc);
+   void (*init)(struct intel_uc *uc);
+   void (*fini)(struct intel_uc *uc);
int (*init_hw)(struct intel_uc *uc);
void (*fini_hw)(struct intel_uc *uc);
 };
@@ -32,8 +34,6 @@ void intel_uc_init_early(struct intel_uc *uc);
 void intel_uc_driver_late_release(struct intel_uc *uc);
 void intel_uc_init_mmio(struct intel_uc *uc);
 void intel_uc_sanitize(struct intel_uc *uc);
-void intel_uc_init(struct intel_uc *uc);
-void intel_uc_fini(struct intel_uc *uc);
 void intel_uc_reset_prepare(struct intel_uc *uc);
 void intel_uc_suspend(struct intel_uc *uc);
 void intel_uc_runtime_suspend(struct intel_uc *uc);
@@ -79,6 +79,8 @@ static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
 }
 intel_uc_ops_function(fetch_firmwares, init_fw, void, );
 intel_uc_ops_function(cleanup_firmwares, fini_fw, void, );
+intel_uc_ops_function(init, init, void, );
+intel_uc_ops_function(fini, fini, void, );
 intel_uc_ops_function(init_hw, init_hw, int, 0);
 intel_uc_ops_function(fini_hw, fini_hw, void, );
 #undef intel_uc_ops_function
-- 
2.19.2

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


[Intel-gfx] [CI v4 2/4] drm/i915/uc: Add init_fw/fini_fw to to intel_uc_ops

2020-01-10 Thread Michal Wajdeczko
Firmware fetching and cleanup steps are only meaningful if we are
running with uC enabled. Make these functions part of the uc_ops.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  6 --
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 9bcec6e0d370..cd0742f9ba4d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -253,12 +253,11 @@ static void guc_disable_communication(struct intel_guc 
*guc)
DRM_INFO("GuC communication disabled\n");
 }
 
-void intel_uc_fetch_firmwares(struct intel_uc *uc)
+static void __uc_fetch_firmwares(struct intel_uc *uc)
 {
int err;
 
-   if (!intel_uc_uses_guc(uc))
-   return;
+   GEM_BUG_ON(!intel_uc_uses_guc(uc));
 
err = intel_uc_fw_fetch(>guc.fw);
if (err)
@@ -268,7 +267,7 @@ void intel_uc_fetch_firmwares(struct intel_uc *uc)
intel_uc_fw_fetch(>huc.fw);
 }
 
-void intel_uc_cleanup_firmwares(struct intel_uc *uc)
+static void __uc_cleanup_firmwares(struct intel_uc *uc)
 {
intel_uc_fw_cleanup_fetch(>huc.fw);
intel_uc_fw_cleanup_fetch(>guc.fw);
@@ -617,6 +616,9 @@ static const struct intel_uc_ops uc_ops_off = {
 };
 
 static const struct intel_uc_ops uc_ops_on = {
+   .init_fw = __uc_fetch_firmwares,
+   .fini_fw = __uc_cleanup_firmwares,
+
.init_hw = __uc_init_hw,
.fini_hw = __uc_fini_hw,
 };
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index d5c2d4cf1d38..47c7c8add451 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -13,6 +13,8 @@
 struct intel_uc;
 
 struct intel_uc_ops {
+   void (*init_fw)(struct intel_uc *uc);
+   void (*fini_fw)(struct intel_uc *uc);
int (*init_hw)(struct intel_uc *uc);
void (*fini_hw)(struct intel_uc *uc);
 };
@@ -29,8 +31,6 @@ struct intel_uc {
 void intel_uc_init_early(struct intel_uc *uc);
 void intel_uc_driver_late_release(struct intel_uc *uc);
 void intel_uc_init_mmio(struct intel_uc *uc);
-void intel_uc_fetch_firmwares(struct intel_uc *uc);
-void intel_uc_cleanup_firmwares(struct intel_uc *uc);
 void intel_uc_sanitize(struct intel_uc *uc);
 void intel_uc_init(struct intel_uc *uc);
 void intel_uc_fini(struct intel_uc *uc);
@@ -77,6 +77,8 @@ static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
return uc->ops->_OPS(uc); \
return _RET; \
 }
+intel_uc_ops_function(fetch_firmwares, init_fw, void, );
+intel_uc_ops_function(cleanup_firmwares, fini_fw, void, );
 intel_uc_ops_function(init_hw, init_hw, int, 0);
 intel_uc_ops_function(fini_hw, fini_hw, void, );
 #undef intel_uc_ops_function
-- 
2.19.2

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


[Intel-gfx] [CI v4 1/4] drm/i915/uc: Add ops to intel_uc

2020-01-10 Thread Michal Wajdeczko
Instead of spreading multiple conditionals across the uC code
to find out current mode of uC operation, start using predefined
set of function pointers that reflect that mode.

Begin with pair of init_hw/fini_hw functions that are responsible
for uC hardware initialization and cleanup.

v2: drop ops_none, use macro to generate ops helpers
v3: reuse __uc_check_hw to avoid redundant comment
v4: forward declare ops struct vs functions

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 45 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc.h | 21 +++--
 2 files changed, 54 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 3ffc6267f96e..9bcec6e0d370 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -12,6 +12,9 @@
 
 #include "i915_drv.h"
 
+static const struct intel_uc_ops uc_ops_off;
+static const struct intel_uc_ops uc_ops_on;
+
 /* Reset GuC providing us with fresh state for both GuC and HuC.
  */
 static int __intel_uc_reset_hw(struct intel_uc *uc)
@@ -89,6 +92,11 @@ void intel_uc_init_early(struct intel_uc *uc)
intel_huc_init_early(>huc);
 
__confirm_options(uc);
+
+   if (intel_uc_uses_guc(uc))
+   uc->ops = _ops_on;
+   else
+   uc->ops = _ops_off;
 }
 
 void intel_uc_driver_late_release(struct intel_uc *uc)
@@ -380,13 +388,8 @@ static bool uc_is_wopcm_locked(struct intel_uc *uc)
   (intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET) & 
GUC_WOPCM_OFFSET_VALID);
 }
 
-int intel_uc_init_hw(struct intel_uc *uc)
+static int __uc_check_hw(struct intel_uc *uc)
 {
-   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
-   struct intel_guc *guc = >guc;
-   struct intel_huc *huc = >huc;
-   int ret, attempts;
-
if (!intel_uc_supports_guc(uc))
return 0;
 
@@ -395,11 +398,24 @@ int intel_uc_init_hw(struct intel_uc *uc)
 * before on this system after reboot, otherwise we risk GPU hangs.
 * To check if GuC was loaded before we look at WOPCM registers.
 */
-   if (!intel_uc_uses_guc(uc) && !uc_is_wopcm_locked(uc))
-   return 0;
+   if (uc_is_wopcm_locked(uc))
+   return -EIO;
+
+   return 0;
+}
+
+static int __uc_init_hw(struct intel_uc *uc)
+{
+   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+   int ret, attempts;
+
+   GEM_BUG_ON(!intel_uc_supports_guc(uc));
+   GEM_BUG_ON(!intel_uc_uses_guc(uc));
 
if (!intel_uc_fw_is_available(>fw)) {
-   ret = uc_is_wopcm_locked(uc) ||
+   ret = __uc_check_hw(uc) ||
  intel_uc_fw_is_overridden(>fw) ||
  intel_uc_supports_guc_submission(uc) ?
  intel_uc_fw_status_to_error(guc->fw.status) : 0;
@@ -495,7 +511,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
return -EIO;
 }
 
-void intel_uc_fini_hw(struct intel_uc *uc)
+static void __uc_fini_hw(struct intel_uc *uc)
 {
struct intel_guc *guc = >guc;
 
@@ -595,3 +611,12 @@ int intel_uc_runtime_resume(struct intel_uc *uc)
 */
return __uc_resume(uc, true);
 }
+
+static const struct intel_uc_ops uc_ops_off = {
+   .init_hw = __uc_check_hw,
+};
+
+static const struct intel_uc_ops uc_ops_on = {
+   .init_hw = __uc_init_hw,
+   .fini_hw = __uc_fini_hw,
+};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 527995c21196..d5c2d4cf1d38 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -10,7 +10,15 @@
 #include "intel_huc.h"
 #include "i915_params.h"
 
+struct intel_uc;
+
+struct intel_uc_ops {
+   int (*init_hw)(struct intel_uc *uc);
+   void (*fini_hw)(struct intel_uc *uc);
+};
+
 struct intel_uc {
+   struct intel_uc_ops const *ops;
struct intel_guc guc;
struct intel_huc huc;
 
@@ -25,8 +33,6 @@ void intel_uc_fetch_firmwares(struct intel_uc *uc);
 void intel_uc_cleanup_firmwares(struct intel_uc *uc);
 void intel_uc_sanitize(struct intel_uc *uc);
 void intel_uc_init(struct intel_uc *uc);
-int intel_uc_init_hw(struct intel_uc *uc);
-void intel_uc_fini_hw(struct intel_uc *uc);
 void intel_uc_fini(struct intel_uc *uc);
 void intel_uc_reset_prepare(struct intel_uc *uc);
 void intel_uc_suspend(struct intel_uc *uc);
@@ -64,4 +70,15 @@ static inline bool intel_uc_uses_huc(struct intel_uc *uc)
return intel_huc_is_enabled(>huc);
 }
 
+#define intel_uc_ops_function(_NAME, _OPS, _TYPE, _RET) \
+static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
+{ \
+   if (uc->ops->_OPS) \
+   return uc->ops->_OPS(uc); \
+   return _RET; \
+}

[Intel-gfx] [CI v4 0/4] Add ops to intel_uc

2020-01-10 Thread Michal Wajdeczko
Instead of spreading multiple conditionals across the uC code
to find out current mode of uC operation, start using predefined
set of function pointers that reflect that mode.

v2: rebased, using macro to generate ops helpers 
v3: reuse __uc_check_hw to avoid redundant comment
v4: forward declare ops struct vs functions

Michal Wajdeczko (4):
  drm/i915/uc: Add ops to intel_uc
  drm/i915/uc: Add init_fw/fini_fw to to intel_uc_ops
  drm/i915/uc: Add init/fini to to intel_uc_ops
  drm/i915/uc: Add sanitize to to intel_uc_ops

 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 75 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc.h | 36 ++---
 2 files changed, 78 insertions(+), 33 deletions(-)

-- 
2.19.2

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


[Intel-gfx] [CI v4 4/4] drm/i915/uc: Add sanitize to to intel_uc_ops

2020-01-10 Thread Michal Wajdeczko
uC sanitization is only meaningful if we are running with uC present
or enabled. Make this function part of the uc_ops.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  3 ++-
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 105b7792c9a0..64934a876a50 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -315,14 +315,6 @@ static int __uc_sanitize(struct intel_uc *uc)
return __intel_uc_reset_hw(uc);
 }
 
-void intel_uc_sanitize(struct intel_uc *uc)
-{
-   if (!intel_uc_supports_guc(uc))
-   return;
-
-   __uc_sanitize(uc);
-}
-
 /* Initialize and verify the uC regs related to uC positioning in WOPCM */
 static int uc_init_wopcm(struct intel_uc *uc)
 {
@@ -615,6 +607,8 @@ static const struct intel_uc_ops uc_ops_off = {
 };
 
 static const struct intel_uc_ops uc_ops_on = {
+   .sanitize = __uc_sanitize,
+
.init_fw = __uc_fetch_firmwares,
.fini_fw = __uc_cleanup_firmwares,
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 8c0ce0d9f190..49c913524686 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -13,6 +13,7 @@
 struct intel_uc;
 
 struct intel_uc_ops {
+   int (*sanitize)(struct intel_uc *uc);
void (*init_fw)(struct intel_uc *uc);
void (*fini_fw)(struct intel_uc *uc);
void (*init)(struct intel_uc *uc);
@@ -33,7 +34,6 @@ struct intel_uc {
 void intel_uc_init_early(struct intel_uc *uc);
 void intel_uc_driver_late_release(struct intel_uc *uc);
 void intel_uc_init_mmio(struct intel_uc *uc);
-void intel_uc_sanitize(struct intel_uc *uc);
 void intel_uc_reset_prepare(struct intel_uc *uc);
 void intel_uc_suspend(struct intel_uc *uc);
 void intel_uc_runtime_suspend(struct intel_uc *uc);
@@ -77,6 +77,7 @@ static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
return uc->ops->_OPS(uc); \
return _RET; \
 }
+intel_uc_ops_function(sanitize, sanitize, int, 0);
 intel_uc_ops_function(fetch_firmwares, init_fw, void, );
 intel_uc_ops_function(cleanup_firmwares, fini_fw, void, );
 intel_uc_ops_function(init, init, void, );
-- 
2.19.2

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


Re: [Intel-gfx] [PATCH 14/14] drm/i915/execlists: Offline error capture

2020-01-10 Thread kbuild test robot
Hi Chris,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20200109]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip v5.5-rc5 v5.5-rc4 
v5.5-rc3 v5.5-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-gt-Push-context-state-allocation-earlier/20200110-090110
base:85cff1ab64327cee3090050b3dd6b5f1df3e5e1f
config: x86_64-randconfig-a003-20200109 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/i915/i915_drv.h:97:0,
from drivers/gpu/drm/i915/gt/intel_lrc.c:136:
   drivers/gpu/drm/i915/i915_gpu_error.h:312:6: error: conflicting types for 
'i915_vma_compress_prepare'
void i915_vma_compress_prepare(struct i915_vma_compress *compress)
 ^
   drivers/gpu/drm/i915/i915_gpu_error.h:307:1: note: previous definition of 
'i915_vma_compress_prepare' was here
i915_vma_compress_prepare(struct intel_gt_coredump *gt)
^
   drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'execlists_capture_work':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2471:10: error: implicit declaration of 
>> function 'i915_vma_capture_prepare' [-Werror=implicit-function-declaration]
  comp = i915_vma_capture_prepare(gt);
 ^
   drivers/gpu/drm/i915/gt/intel_lrc.c:2471:8: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
  comp = i915_vma_capture_prepare(gt);
   ^
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2474:4: error: implicit declaration of 
>> function 'i915_vma_capture_finish' [-Werror=implicit-function-declaration]
   i915_vma_capture_finish(gt, comp);
   ^
   drivers/gpu/drm/i915/gt/intel_lrc.c:2481:25: error: passing argument 1 of 
'i915_error_state_store' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 i915_error_state_store(cap->error);
^
   In file included from drivers/gpu/drm/i915/i915_drv.h:97:0,
from drivers/gpu/drm/i915/gt/intel_lrc.c:136:
   drivers/gpu/drm/i915/i915_gpu_error.h:317:1: note: expected 'struct 
drm_i915_private *' but argument is of type 'struct i915_gpu_coredump *'
i915_error_state_store(struct drm_i915_private *i915,
^
   drivers/gpu/drm/i915/gt/intel_lrc.c:2481:2: error: too few arguments to 
function 'i915_error_state_store'
 i915_error_state_store(cap->error);
 ^
   In file included from drivers/gpu/drm/i915/i915_drv.h:97:0,
from drivers/gpu/drm/i915/gt/intel_lrc.c:136:
   drivers/gpu/drm/i915/i915_gpu_error.h:317:1: note: declared here
i915_error_state_store(struct drm_i915_private *i915,
^
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2482:2: error: implicit declaration of 
>> function 'i915_gpu_coredump_put' [-Werror=implicit-function-declaration]
 i915_gpu_coredump_put(cap->error);
 ^
   cc1: some warnings being treated as errors

vim +/i915_vma_capture_prepare +2471 drivers/gpu/drm/i915/gt/intel_lrc.c

  2458  
  2459  static void execlists_capture_work(struct work_struct *work)
  2460  {
  2461  struct execlists_capture *cap = container_of(work, 
typeof(*cap), work);
  2462  const gfp_t gfp = GFP_KERNEL | __GFP_RETRY_MAYFAIL | 
__GFP_NOWARN;
  2463  struct intel_engine_cs *engine = cap->rq->engine;
  2464  struct intel_gt_coredump *gt = cap->error->gt;
  2465  struct intel_engine_capture_vma *vma;
  2466  
  2467  vma = intel_engine_coredump_add_request(gt->engine, cap->rq, 
gfp);
  2468  if (vma) {
  2469  struct i915_vma_compress *comp;
  2470  
> 2471  comp = i915_vma_capture_prepare(gt);
  2472  if (comp) {
  2473  intel_engine_coredump_add_vma(gt->engine, vma, 
comp);
> 2474  i915_vma_capture_finish(gt, comp);
  2475  }
  2476  }
  2477  
  2478  gt->simulated = gt->engine->simulated;
  2479  cap->error->simulated = gt->simulated;
  2480  
  2481  i915_error_state_store(cap->error);
> 2482  i915_gpu_coredump_put(cap->error);
  2483  
  2484  execlists_unhold(engine, cap->rq);
  2485  
  2486  kfree(cap);
  2487  }
  2488  

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corp

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/uc: Add ops to intel_uc

2020-01-10 Thread Michal Wajdeczko
On Fri, 10 Jan 2020 17:57:22 +0100, Chris Wilson  
 wrote:



Quoting Michal Wajdeczko (2020-01-10 16:29:27)

Instead of spreading multiple conditionals across the uC code
to find out current mode of uC operation, start using predefined
set of function pointers that reflect that mode.

Begin with pair of init_hw/fini_hw functions that are responsible
for uC hardware initialization and cleanup.

v2: drop ops_none, use macro to generate ops helpers

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 45 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc.h | 21 +++--
 2 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c  
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c

index 3ffc6267f96e..da401e97bba3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -12,6 +12,19 @@

 #include "i915_drv.h"

+static int __uc_check_hw(struct intel_uc *uc);
+static int __uc_init_hw(struct intel_uc *uc);
+static void __uc_fini_hw(struct intel_uc *uc);
+
+static const struct intel_uc_ops uc_ops_off = {
+   .init_hw = __uc_check_hw,
+};
+
+static const struct intel_uc_ops uc_ops_on = {
+   .init_hw = __uc_init_hw,
+   .fini_hw = __uc_fini_hw,
+};
+
 /* Reset GuC providing us with fresh state for both GuC and HuC.
  */
 static int __intel_uc_reset_hw(struct intel_uc *uc)
@@ -89,6 +102,11 @@ void intel_uc_init_early(struct intel_uc *uc)
intel_huc_init_early(>huc);

__confirm_options(uc);
+
+   if (intel_uc_uses_guc(uc))
+   uc->ops = _ops_on;
+   else
+   uc->ops = _ops_off;
 }

 void intel_uc_driver_late_release(struct intel_uc *uc)
@@ -380,24 +398,37 @@ static bool uc_is_wopcm_locked(struct intel_uc  
*uc)
   (intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET) &  
GUC_WOPCM_OFFSET_VALID);

 }

-int intel_uc_init_hw(struct intel_uc *uc)
+static int __uc_check_hw(struct intel_uc *uc)
+{
+   if (!intel_uc_supports_guc(uc))
+   return 0;
+
+   /*
+* We can silently continue without GuC only if it was never  
enabled
+* before on this system after reboot, otherwise we risk GPU  
hangs.

+* To check if GuC was loaded before we look at WOPCM registers.
+*/
+   if (uc_is_wopcm_locked(uc))
+   return -EIO;
+
+   return 0;
+}
+
+static int __uc_init_hw(struct intel_uc *uc)
 {
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
int ret, attempts;

-   if (!intel_uc_supports_guc(uc))
-   return 0;
+   GEM_BUG_ON(!intel_uc_supports_guc(uc));
+   GEM_BUG_ON(!intel_uc_uses_guc(uc));

/*
 * We can silently continue without GuC only if it was never  
enabled
 * before on this system after reboot, otherwise we risk GPU  
hangs.

 * To check if GuC was loaded before we look at WOPCM registers.
 */


This comment still required?
Shouldn't there be a call here to __uc_check_hw() instead?


ok, will replace below call to uc_is_wopcm_locked() with __uc_check_hw()
to avoid redundant (but otherwise still valid) comment




-   if (!intel_uc_uses_guc(uc) && !uc_is_wopcm_locked(uc))
-   return 0;
-
if (!intel_uc_fw_is_available(>fw)) {
ret = uc_is_wopcm_locked(uc) ||


 ^^


  intel_uc_fw_is_overridden(>fw) ||
@@ -495,7 +526,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
return -EIO;
 }

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


[Intel-gfx] [PATCH v3 1/4] drm/i915/uc: Add ops to intel_uc

2020-01-10 Thread Michal Wajdeczko
Instead of spreading multiple conditionals across the uC code
to find out current mode of uC operation, start using predefined
set of function pointers that reflect that mode.

Begin with pair of init_hw/fini_hw functions that are responsible
for uC hardware initialization and cleanup.

v2: drop ops_none, use macro to generate ops helpers
v3: reuse __uc_check_hw to avoid redundant comment

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 46 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc.h | 21 ++--
 2 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 3ffc6267f96e..5e9b3fa7bc74 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -12,6 +12,19 @@
 
 #include "i915_drv.h"
 
+static int __uc_check_hw(struct intel_uc *uc);
+static int __uc_init_hw(struct intel_uc *uc);
+static void __uc_fini_hw(struct intel_uc *uc);
+
+static const struct intel_uc_ops uc_ops_off = {
+   .init_hw = __uc_check_hw,
+};
+
+static const struct intel_uc_ops uc_ops_on = {
+   .init_hw = __uc_init_hw,
+   .fini_hw = __uc_fini_hw,
+};
+
 /* Reset GuC providing us with fresh state for both GuC and HuC.
  */
 static int __intel_uc_reset_hw(struct intel_uc *uc)
@@ -89,6 +102,11 @@ void intel_uc_init_early(struct intel_uc *uc)
intel_huc_init_early(>huc);
 
__confirm_options(uc);
+
+   if (intel_uc_uses_guc(uc))
+   uc->ops = _ops_on;
+   else
+   uc->ops = _ops_off;
 }
 
 void intel_uc_driver_late_release(struct intel_uc *uc)
@@ -380,13 +398,8 @@ static bool uc_is_wopcm_locked(struct intel_uc *uc)
   (intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET) & 
GUC_WOPCM_OFFSET_VALID);
 }
 
-int intel_uc_init_hw(struct intel_uc *uc)
+static int __uc_check_hw(struct intel_uc *uc)
 {
-   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
-   struct intel_guc *guc = >guc;
-   struct intel_huc *huc = >huc;
-   int ret, attempts;
-
if (!intel_uc_supports_guc(uc))
return 0;
 
@@ -395,11 +408,24 @@ int intel_uc_init_hw(struct intel_uc *uc)
 * before on this system after reboot, otherwise we risk GPU hangs.
 * To check if GuC was loaded before we look at WOPCM registers.
 */
-   if (!intel_uc_uses_guc(uc) && !uc_is_wopcm_locked(uc))
-   return 0;
+   if (uc_is_wopcm_locked(uc))
+   return -EIO;
+
+   return 0;
+}
+
+static int __uc_init_hw(struct intel_uc *uc)
+{
+   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+   int ret, attempts;
+
+   GEM_BUG_ON(!intel_uc_supports_guc(uc));
+   GEM_BUG_ON(!intel_uc_uses_guc(uc));
 
if (!intel_uc_fw_is_available(>fw)) {
-   ret = uc_is_wopcm_locked(uc) ||
+   ret = __uc_check_hw(uc) ||
  intel_uc_fw_is_overridden(>fw) ||
  intel_uc_supports_guc_submission(uc) ?
  intel_uc_fw_status_to_error(guc->fw.status) : 0;
@@ -495,7 +521,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
return -EIO;
 }
 
-void intel_uc_fini_hw(struct intel_uc *uc)
+static void __uc_fini_hw(struct intel_uc *uc)
 {
struct intel_guc *guc = >guc;
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 527995c21196..d5c2d4cf1d38 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -10,7 +10,15 @@
 #include "intel_huc.h"
 #include "i915_params.h"
 
+struct intel_uc;
+
+struct intel_uc_ops {
+   int (*init_hw)(struct intel_uc *uc);
+   void (*fini_hw)(struct intel_uc *uc);
+};
+
 struct intel_uc {
+   struct intel_uc_ops const *ops;
struct intel_guc guc;
struct intel_huc huc;
 
@@ -25,8 +33,6 @@ void intel_uc_fetch_firmwares(struct intel_uc *uc);
 void intel_uc_cleanup_firmwares(struct intel_uc *uc);
 void intel_uc_sanitize(struct intel_uc *uc);
 void intel_uc_init(struct intel_uc *uc);
-int intel_uc_init_hw(struct intel_uc *uc);
-void intel_uc_fini_hw(struct intel_uc *uc);
 void intel_uc_fini(struct intel_uc *uc);
 void intel_uc_reset_prepare(struct intel_uc *uc);
 void intel_uc_suspend(struct intel_uc *uc);
@@ -64,4 +70,15 @@ static inline bool intel_uc_uses_huc(struct intel_uc *uc)
return intel_huc_is_enabled(>huc);
 }
 
+#define intel_uc_ops_function(_NAME, _OPS, _TYPE, _RET) \
+static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
+{ \
+   if (uc->ops->_OPS) \
+   return uc->ops->_OPS(uc); \
+   return _RET; \
+}
+intel_uc_ops_function(init_hw, init_hw, int, 0);
+intel_uc_ops_function(fini_hw, fini_hw, void, );
+#undef intel_uc_ops_function
+
 #endif
-- 
2.19.2


[Intel-gfx] [PATCH] drm/i915/dp/tgl+: Update combo phy vswing tables

2020-01-10 Thread José Roberto de Souza
TGL has now a table for RBR and HBR and another table for HBR2 over
combo phys. The HBR2 one has some small changes comparing to the ICL
one, so adding two new tables and adding a function to return TGL
combo phy tables.

v2:
- reordered the tgl_combo_phy_ddi_translations_dp_hbr2 to reduce diff
(Matt)
- removed definition of rates, kept using raw number(Jani and Ville)
- changed code to use icl_get_combo_buf_trans() for non-DP as those
are equal between TGL and ICL(Matt)

BSpec: 49291
Cc: Lucas De Marchi 
Cc: Matt Roper 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 55 ++--
 1 file changed, 51 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index fbc13f36f76f..41c433cdf60c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -622,6 +622,34 @@ static const struct tgl_dkl_phy_ddi_buf_trans 
tgl_dkl_phy_hdmi_ddi_trans[] = {
{ 0x0, 0x0, 0xA },  /* 10   Full-3 dB */
 };
 
+static const struct cnl_ddi_buf_trans tgl_combo_phy_ddi_translations_dp_hbr[] 
= {
+   /* NT mV Trans mV db*/
+   { 0xA, 0x32, 0x3F, 0x00, 0x00 },/* 350   350  0.0   */
+   { 0xA, 0x4F, 0x37, 0x00, 0x08 },/* 350   500  3.1   */
+   { 0xC, 0x71, 0x2F, 0x00, 0x10 },/* 350   700  6.0   */
+   { 0x6, 0x7D, 0x2B, 0x00, 0x14 },/* 350   900  8.2   */
+   { 0xA, 0x4C, 0x3F, 0x00, 0x00 },/* 500   500  0.0   */
+   { 0xC, 0x73, 0x34, 0x00, 0x0B },/* 500   700  2.9   */
+   { 0x6, 0x7F, 0x2F, 0x00, 0x10 },/* 500   900  5.1   */
+   { 0xC, 0x6C, 0x3C, 0x00, 0x03 },/* 650   700  0.6   */
+   { 0x6, 0x7F, 0x35, 0x00, 0x0A },/* 600   900  3.5   */
+   { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900   900  0.0   */
+};
+
+static const struct cnl_ddi_buf_trans tgl_combo_phy_ddi_translations_dp_hbr2[] 
= {
+   /* NT mV Trans mV db*/
+   { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350   350  0.0   */
+   { 0xA, 0x4F, 0x37, 0x00, 0x08 },/* 350   500  3.1   */
+   { 0xC, 0x63, 0x2F, 0x00, 0x10 },/* 350   700  6.0   */
+   { 0x6, 0x7F, 0x2B, 0x00, 0x14 },/* 350   900  8.2   */
+   { 0xA, 0x47, 0x3F, 0x00, 0x00 },/* 500   500  0.0   */
+   { 0xC, 0x63, 0x34, 0x00, 0x0B },/* 500   700  2.9   */
+   { 0x6, 0x7F, 0x2F, 0x00, 0x10 },/* 500   900  5.1   */
+   { 0xC, 0x61, 0x3C, 0x00, 0x03 },/* 650   700  0.6   */
+   { 0x6, 0x7B, 0x35, 0x00, 0x0A },/* 600   900  3.5   */
+   { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900   900  0.0   */
+};
+
 static const struct ddi_buf_trans *
 bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
 {
@@ -901,6 +929,21 @@ icl_get_combo_buf_trans(struct drm_i915_private *dev_priv, 
int type, int rate,
return icl_combo_phy_ddi_translations_dp_hbr2;
 }
 
+static const struct cnl_ddi_buf_trans *
+tgl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int type, int rate,
+   int *n_entries)
+{
+   if (type != INTEL_OUTPUT_DP) {
+   return icl_get_combo_buf_trans(dev_priv, type, rate, n_entries);
+   } else if (rate > 27) {
+   *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
+   return tgl_combo_phy_ddi_translations_dp_hbr2;
+   }
+
+   *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
+   return tgl_combo_phy_ddi_translations_dp_hbr;
+}
+
 static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv, enum port 
port)
 {
struct ddi_vbt_port_info *port_info = 
_priv->vbt.ddi_port_info[port];
@@ -909,7 +952,7 @@ static int intel_ddi_hdmi_level(struct drm_i915_private 
*dev_priv, enum port por
 
if (INTEL_GEN(dev_priv) >= 12) {
if (intel_phy_is_combo(dev_priv, phy))
-   icl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
+   tgl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
0, _entries);
else
n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
@@ -2372,7 +2415,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder)
 
if (INTEL_GEN(dev_priv) >= 12) {
if (intel_phy_is_combo(dev_priv, phy))
-   icl_get_combo_buf_trans(dev_priv, encoder->type,
+   tgl_get_combo_buf_trans(dev_priv, encoder->type,
intel_dp->link_rate, 
_entries);
else
n_entries = 

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/uc: Add ops to intel_uc

2020-01-10 Thread Chris Wilson
Quoting Michal Wajdeczko (2020-01-10 18:47:50)
> On Fri, 10 Jan 2020 17:57:22 +0100, Chris Wilson  
>  wrote:
> 
> > Quoting Michal Wajdeczko (2020-01-10 16:29:27)
> >> Instead of spreading multiple conditionals across the uC code
> >> to find out current mode of uC operation, start using predefined
> >> set of function pointers that reflect that mode.
> >>
> >> Begin with pair of init_hw/fini_hw functions that are responsible
> >> for uC hardware initialization and cleanup.
> >>
> >> v2: drop ops_none, use macro to generate ops helpers
> >>
> >> Signed-off-by: Michal Wajdeczko 
> >> Cc: Joonas Lahtinen 
> >> Cc: Chris Wilson 
> >> Cc: Daniele Ceraolo Spurio 
> >> ---
> >>  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 45 ++-
> >>  drivers/gpu/drm/i915/gt/uc/intel_uc.h | 21 +++--
> >>  2 files changed, 57 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c  
> >> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> index 3ffc6267f96e..da401e97bba3 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> @@ -12,6 +12,19 @@
> >>
> >>  #include "i915_drv.h"
> >>
> >> +static int __uc_check_hw(struct intel_uc *uc);
> >> +static int __uc_init_hw(struct intel_uc *uc);
> >> +static void __uc_fini_hw(struct intel_uc *uc);
> >> +
> >> +static const struct intel_uc_ops uc_ops_off = {
> >> +   .init_hw = __uc_check_hw,
> >> +};
> >> +
> >> +static const struct intel_uc_ops uc_ops_on = {
> >> +   .init_hw = __uc_init_hw,
> >> +   .fini_hw = __uc_fini_hw,
> >> +};
> >> +
> >>  /* Reset GuC providing us with fresh state for both GuC and HuC.
> >>   */
> >>  static int __intel_uc_reset_hw(struct intel_uc *uc)
> >> @@ -89,6 +102,11 @@ void intel_uc_init_early(struct intel_uc *uc)
> >> intel_huc_init_early(>huc);
> >>
> >> __confirm_options(uc);
> >> +
> >> +   if (intel_uc_uses_guc(uc))
> >> +   uc->ops = _ops_on;
> >> +   else
> >> +   uc->ops = _ops_off;
> >>  }
> >>
> >>  void intel_uc_driver_late_release(struct intel_uc *uc)
> >> @@ -380,24 +398,37 @@ static bool uc_is_wopcm_locked(struct intel_uc  
> >> *uc)
> >>(intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET) &  
> >> GUC_WOPCM_OFFSET_VALID);
> >>  }
> >>
> >> -int intel_uc_init_hw(struct intel_uc *uc)
> >> +static int __uc_check_hw(struct intel_uc *uc)
> >> +{
> >> +   if (!intel_uc_supports_guc(uc))
> >> +   return 0;
> >> +
> >> +   /*
> >> +* We can silently continue without GuC only if it was never  
> >> enabled
> >> +* before on this system after reboot, otherwise we risk GPU  
> >> hangs.
> >> +* To check if GuC was loaded before we look at WOPCM registers.
> >> +*/
> >> +   if (uc_is_wopcm_locked(uc))
> >> +   return -EIO;
> >> +
> >> +   return 0;
> >> +}
> >> +
> >> +static int __uc_init_hw(struct intel_uc *uc)
> >>  {
> >> struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
> >> struct intel_guc *guc = >guc;
> >> struct intel_huc *huc = >huc;
> >> int ret, attempts;
> >>
> >> -   if (!intel_uc_supports_guc(uc))
> >> -   return 0;
> >> +   GEM_BUG_ON(!intel_uc_supports_guc(uc));
> >> +   GEM_BUG_ON(!intel_uc_uses_guc(uc));
> >>
> >> /*
> >>  * We can silently continue without GuC only if it was never  
> >> enabled
> >>  * before on this system after reboot, otherwise we risk GPU  
> >> hangs.
> >>  * To check if GuC was loaded before we look at WOPCM registers.
> >>  */
> >
> > This comment still required?
> > Shouldn't there be a call here to __uc_check_hw() instead?
> 
> ok, will replace below call to uc_is_wopcm_locked() with __uc_check_hw()
> to avoid redundant (but otherwise still valid) comment
> 
> >
> >> -   if (!intel_uc_uses_guc(uc) && !uc_is_wopcm_locked(uc))
> >> -   return 0;
> >> -
> >> if (!intel_uc_fw_is_available(>fw)) {
> >> ret = uc_is_wopcm_locked(uc) ||
> 
>   ^^

Ah, I see.

I think I still like the chaining up to __uc_check_hw() for the
continuity aspect, and only being scared once by the warning.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/uc: Add sanitize to to intel_uc_ops

2020-01-10 Thread Chris Wilson
Quoting Michal Wajdeczko (2020-01-10 16:29:30)
> uC sanitization is only meaningful if we are running with uC present
> or enabled. Make this function part of the uc_ops.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Daniele Ceraolo Spurio 

Series is 
Reviewed-by: Chris Wilson 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 ++
>  drivers/gpu/drm/i915/gt/uc/intel_uc.h |  3 ++-
>  2 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index 1b07135a8515..c1d5af775713 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -12,6 +12,7 @@
>  
>  #include "i915_drv.h"
>  
> +static int __uc_sanitize(struct intel_uc *uc);
>  static void __uc_fetch_firmwares(struct intel_uc *uc);
>  static void __uc_cleanup_firmwares(struct intel_uc *uc);
>  static void __uc_init(struct intel_uc *uc);
> @@ -25,6 +26,7 @@ static const struct intel_uc_ops uc_ops_off = {
>  };
>  
>  static const struct intel_uc_ops uc_ops_on = {
> +   .sanitize = __uc_sanitize,
> .init_fw = __uc_fetch_firmwares,
> .fini_fw = __uc_cleanup_firmwares,
> .init = __uc_init,

The only nit is that I would use whitespace here more consistently here
to break up the phases, and I would suggest making the ops forwards
declared rather than every function.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/6] drm/i915: Stop looking at plane->state in intel_prepare_plane_fb()

2020-01-10 Thread Chris Wilson
Quoting Ville Syrjala (2020-01-10 18:32:25)
> From: Ville Syrjälä 
> 
> Switch over to using explicit old/new planes states instead of
> digging the old state out via plane->state. The main issue is that
> plane->state will point to the uapi state which we generally don't
> even want to look at.
> 
> Also it sets a bad example as using plane->state during commit_tail()
> would be a bug. Here we're still holding the modeset locks so it's
> actually safe, but best not give people bad ideas.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0a1f2564dea0..0df0719b0ac3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15749,23 +15749,25 @@ static void fb_obj_bump_render_priority(struct 
> drm_i915_gem_object *obj)
>   * Returns 0 on success, negative error code on failure.
>   */
>  int
> -intel_prepare_plane_fb(struct drm_plane *plane,
> +intel_prepare_plane_fb(struct drm_plane *_plane,
>struct drm_plane_state *_new_plane_state)
>  {
> +   struct intel_plane *plane = to_intel_plane(_plane);
> struct intel_plane_state *new_plane_state =
> to_intel_plane_state(_new_plane_state);
> struct intel_atomic_state *intel_state =
> to_intel_atomic_state(new_plane_state->uapi.state);
> -   struct drm_i915_private *dev_priv = to_i915(plane->dev);
> -   struct drm_framebuffer *fb = new_plane_state->hw.fb;
> -   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> -   struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
> +   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> +   const struct intel_plane_state *old_plane_state =
> +   intel_atomic_get_old_plane_state(intel_state, plane);
> +   struct drm_i915_gem_object *obj = 
> intel_fb_obj(new_plane_state->hw.fb);
> +   struct drm_i915_gem_object *old_obj = 
> intel_fb_obj(old_plane_state->hw.fb);

intel_state being the old one out. Often called just state in other
functions?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER

2020-01-10 Thread José Roberto de Souza
Renaming to match the BSpec and struct name.

BSpec: 20150
Cc: Jani Nikula 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
 drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 8beac06e3f10..9a891ef72118 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -686,7 +686,7 @@ parse_power_conservation_features(struct drm_i915_private 
*dev_priv,
if (bdb->version < 228)
return;
 
-   power = find_section(bdb, BDB_LVDS_POWER);
+   power = find_section(bdb, BDB_LFP_POWER);
if (!power)
return;
 
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 4d0c23b29248..05c7cbe32eb4 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -111,7 +111,7 @@ enum bdb_block_id {
BDB_LVDS_LFP_DATA_PTRS  = 41,
BDB_LVDS_LFP_DATA   = 42,
BDB_LVDS_BACKLIGHT  = 43,
-   BDB_LVDS_POWER  = 44,
+   BDB_LFP_POWER   = 44,
BDB_MIPI_CONFIG = 52,
BDB_MIPI_SEQUENCE   = 53,
BDB_COMPRESSION_PARAMETERS  = 56,
-- 
2.24.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 Add ops to intel_uc (rev4)

2020-01-10 Thread Patchwork
== Series Details ==

Series: Add ops to intel_uc (rev4)
URL   : https://patchwork.freedesktop.org/series/70716/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16061


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16061/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2:  [PASS][1] -> [INCOMPLETE][2] ([i915#671])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16061/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_execlists:
- fi-skl-6770hq:  [PASS][3] -> [DMESG-FAIL][4] ([i915#841])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-skl-6770hq/igt@i915_selftest@live_execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16061/fi-skl-6770hq/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_gem_contexts:
- fi-hsw-peppy:   [PASS][5] -> [DMESG-FAIL][6] ([i915#722])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16061/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][7] ([i915#937]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16061/fi-ehl-1/igt@gem_exec_gttf...@basic.html

  * igt@gem_render_linear_blits@basic:
- fi-icl-dsi: [DMESG-WARN][9] ([i915#109]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16061/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [FAIL][11] -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16061/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#671]: https://gitlab.freedesktop.org/drm/intel/issues/671
  [i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722
  [i915#841]: https://gitlab.freedesktop.org/drm/intel/issues/841
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (47 -> 41)
--

  Additional (5): fi-hsw-4770r fi-bdw-5557u fi-ilk-650 fi-snb-2520m 
fi-byt-n2820 
  Missing(11): fi-hsw-4200u fi-glk-dsi fi-byt-squawks fi-bwr-2160 
fi-bsw-cyan fi-ctg-p8600 fi-blb-e6850 fi-tgl-y fi-byt-clapper fi-bsw-nick 
fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7721 -> Patchwork_16061

  CI-20190529: 20190529
  CI_DRM_7721: 3a2436c56fcf2d133d701a112eb1e0dfce0b846d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5364: b7cb6ffdb65cbd233f5ddee2f2dabf97b34fa640 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16061: ab06f9906171849a5fc250a85df38475c9058094 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ab06f9906171 drm/i915/uc: Add sanitize to to intel_uc_ops
cb2532cf174b drm/i915/uc: Add init/fini to to intel_uc_ops
f899ba846e7d drm/i915/uc: Add init_fw/fini_fw to to intel_uc_ops
2e1f188d8ce3 drm/i915/uc: Add ops to intel_uc

== Logs ==

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


Re: [Intel-gfx] [PATCH 6/6] drm/i915: Cleanup properly if the implicit fence setup fails

2020-01-10 Thread Chris Wilson
Quoting Ville Syrjala (2020-01-10 18:32:28)
> From: Ville Syrjälä 
> 
> We've already pinned the vma and fence by the time we try to
> deal with implicit fencing. Properly unpin the vma and fence
> if the fence setup fails instead of just bailing straight out
> from .prepare_fb(). As can be expected
> drm_atomic_helper_prepare_planes() will not call .cleanup_fb()
> for the plane whose .prepare_fb() failed so we must do the
> cleanup ourself.
> 
> v2: Rebase
> 
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
-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: Fix MST disable sequence

2020-01-10 Thread Souza, Jose
On Wed, 2020-01-08 at 18:20 +0200, Ville Syrjälä wrote:
> On Wed, Jan 08, 2020 at 04:09:31PM +, Souza, Jose wrote:
> > On Wed, 2020-01-08 at 16:45 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > When moving the pipe disable & co. function calls from
> > > haswell_crtc_disable() into the encoder .post_disable() hooks I
> > > neglected to account for the MST vs. DDI interactions properly.
> > > This now leads us to call these functions two times for the last
> > > MST stream (once from the MST code and a second time from the DDI
> > > code). The calls from the DDI code should only be done for SST
> > > and not MST. Add the proper check for that.
> > 
> > Oohh I forgot that too.
> > 
> > > This results in an MCE on ICL. My vague theory is that we turn
> > > off
> > > the transcoder clock from the MST code and then we proceed to
> > > touch
> > > something in the DDI code which still depends on that clock
> > > causing
> > > the hardware to become upset. Though I can't really explain why
> > > Stan's hack of omitting the pipe disable in the MST code would
> > > avoid
> > > the MCE since we should still be turning off the transcoder
> > > clock.
> > > But maybe there's something magic in the hw that keeps the clock
> > > on
> > > as long as the pipe is on. Or maybe the clock isn't the problem
> > > and
> > > we now touch something in the DDI disable code that really does
> > > need
> > > the pipe to be still enabled.
> > > 
> > > v2: Rebase to latest drm-tip
> > > 
> > > Cc: José Roberto de Souza 
> > > Cc: Manasi Navare 
> > > Reported-by: Stanislav Lisovskiy 
> > > Closes: https://gitlab.freedesktop.org/drm/intel/issues/901
> > > Fixes: 773b4b54351c ("drm/i915: Move stuff from
> > > haswell_crtc_disable() into encoder .post_disable()")
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_ddi.c | 22 
> > > --
> > >  1 file changed, 12 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 07acd0daca25..6e0a75d1e6ca 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -3897,21 +3897,23 @@ static void intel_ddi_post_disable(struct
> > > intel_encoder *encoder,
> > >   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> > >   bool is_tc_port = intel_phy_is_tc(dev_priv, phy);
> > >  
> > > - intel_crtc_vblank_off(old_crtc_state);
> > > + if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
> > > {
> > > + intel_crtc_vblank_off(old_crtc_state);
> > >  
> > > - intel_disable_pipe(old_crtc_state);
> > > + intel_disable_pipe(old_crtc_state);
> > >  
> > > - if (INTEL_GEN(dev_priv) >= 11)
> > > - icl_disable_transcoder_port_sync(old_crtc_state);
> > > + if (INTEL_GEN(dev_priv) >= 11)
> > > + icl_disable_transcoder_port_sync(old_crtc_state
> > > );
> > >  
> > > - intel_ddi_disable_transcoder_func(old_crtc_state);
> > > + intel_ddi_disable_transcoder_func(old_crtc_state);
> > >  
> > > - intel_dsc_disable(old_crtc_state);
> > > + intel_dsc_disable(old_crtc_state);
> > >  
> > > - if (INTEL_GEN(dev_priv) >= 9)
> > > - skl_scaler_disable(old_crtc_state);
> > > - else
> > > - ilk_pfit_disable(old_crtc_state);
> > > + if (INTEL_GEN(dev_priv) >= 9)
> > > + skl_scaler_disable(old_crtc_state);
> > > + else
> > > + ilk_pfit_disable(old_crtc_state);
> > > + }
> > 
> > Other option would be replace
> > intel_dig_port->base.post_disable(_dig_port->base,
> > old_crtc_state, NULL);
> > in intel_mst_post_disable_dp() by:
> > 
> > 
> > intel_ddi_post_disable_dp(encoder, old_crtc_state, old_conn_state);
> > 
> > if (INTEL_GEN(dev_priv) >= 11)
> > icl_unmap_plls_to_ports(encoder);
> > 
> > if (intel_crtc_has_dp_encoder(old_crtc_state) || is_tc_port)
> > intel_display_power_put_unchecked(dev_priv,
> > intel_ddi_main_link_aux_domain(dig_port));
> > 
> > if (is_tc_port)
> > intel_tc_port_put_link(dig_port);
> 
> Yeah, the current way is a bit of a mess. We probably want to think
> of
> ways to make it less sucky.

Can I go forward and implement the above and undoing this patch?

> 
> > I guess this goes more with changes that you did in the patch
> > fixed.
> 
> Indeed, a more mechanichal change for now seems more in line with the
> original patch.
> 
> > 
> > Anyway your changes looks good.
> > 
> > Reviewed-by: José Roberto de Souza 
> 
> Ta.
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)

2020-01-10 Thread Matt Roper
On Fri, Jan 10, 2020 at 10:11:23AM -0800, Vivek Kasireddy wrote:
> Parsing the i2c element is mainly done to transfer the payload from the
> MIPI sequence block to the relevant slave device. In some cases, the
> commands that are part of the payload can be used to turn on the backlight.
> 
> This patch is actually a refactored version of this old patch:
> https://lists.freedesktop.org/archives/intel-gfx/2014-December/056897.html
> 
> In addition to the refactoring, the original patch is augmented by looking up
> the i2c bus from ACPI NS instead of relying on the bus number provided
> in the VBT.
> 
> This patch was tested on Aava Mobile's Inari 10 tablet. It enabled
> turning on the backlight by transfering the payload to the device.
> 
> v2:
> - Add DRM_DEV_ERROR for invalid adapter and failed transfer and also
>   drop the DRM_DEBUG that existed originally. (Hans)
> - Add two gotos instead of one to clean things up properly.
> 
> v3:
> - Identify the device on which this patch was tested in the commit
>   message (Ville)
> 
> Cc: Hans de Goede 
> Cc: Nabendu Maiti 
> Cc: Matt Roper 
> Cc: Bob Paauwe 
> Cc: Ville Syrjälä 
> Reviewed-by: Hans de Goede 
> Signed-off-by: Vivek Kasireddy 

Since v3 is identical to v2 except for the commit message, I think we
can apply this based on v2's CI results.  The only CI failure was an
incomplete on a non-DSI TGL system and the incomplete happened long
after the VBT parsing changes here would have had any effect.

Applied to dinq.  Thanks for the patch and review.


Matt

> ---
>  drivers/gpu/drm/i915/display/intel_dsi.h |  3 +
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 99 +++-
>  2 files changed, 100 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h 
> b/drivers/gpu/drm/i915/display/intel_dsi.h
> index 7481a5aa3084..6cef1356b4e6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> @@ -69,6 +69,9 @@ struct intel_dsi {
>   /* number of DSI lanes */
>   unsigned int lane_count;
>  
> + /* i2c bus associated with the slave device */
> + int i2c_bus_num;
> +
>   /*
>* video mode pixel format
>*
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> index 0032161e0f76..89fb0d90b694 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> @@ -86,6 +86,12 @@ static struct gpio_map vlv_gpio_table[] = {
>   { VLV_GPIO_NC_11_PANEL1_BKLTCTL },
>  };
>  
> +struct i2c_adapter_lookup {
> + u16 slave_addr;
> + struct intel_dsi *intel_dsi;
> + acpi_handle dev_handle;
> +};
> +
>  #define CHV_GPIO_IDX_START_N 0
>  #define CHV_GPIO_IDX_START_E 73
>  #define CHV_GPIO_IDX_START_SW100
> @@ -378,11 +384,98 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   return data;
>  }
>  
> +static int i2c_adapter_lookup(struct acpi_resource *ares, void *data)
> +{
> + struct i2c_adapter_lookup *lookup = data;
> + struct intel_dsi *intel_dsi = lookup->intel_dsi;
> + struct acpi_resource_i2c_serialbus *sb;
> + struct i2c_adapter *adapter;
> + acpi_handle adapter_handle;
> + acpi_status status;
> +
> + if (intel_dsi->i2c_bus_num >= 0 ||
> + !i2c_acpi_get_i2c_resource(ares, ))
> + return 1;
> +
> + if (lookup->slave_addr != sb->slave_address)
> + return 1;
> +
> + status = acpi_get_handle(lookup->dev_handle,
> +  sb->resource_source.string_ptr,
> +  _handle);
> + if (ACPI_FAILURE(status))
> + return 1;
> +
> + adapter = i2c_acpi_find_adapter_by_handle(adapter_handle);
> + if (adapter)
> + intel_dsi->i2c_bus_num = adapter->nr;
> +
> + return 1;
> +}
> +
>  static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
>  {
> - DRM_DEBUG_KMS("Skipping I2C element execution\n");
> + struct drm_device *drm_dev = intel_dsi->base.base.dev;
> + struct device *dev = _dev->pdev->dev;
> + struct i2c_adapter *adapter;
> + struct acpi_device *acpi_dev;
> + struct list_head resource_list;
> + struct i2c_adapter_lookup lookup;
> + struct i2c_msg msg;
> + int ret;
> + u8 vbt_i2c_bus_num = *(data + 2);
> + u16 slave_addr = *(u16 *)(data + 3);
> + u8 reg_offset = *(data + 5);
> + u8 payload_size = *(data + 6);
> + u8 *payload_data;
> +
> + if (intel_dsi->i2c_bus_num < 0) {
> + intel_dsi->i2c_bus_num = vbt_i2c_bus_num;
> +
> + acpi_dev = ACPI_COMPANION(dev);
> + if (acpi_dev) {
> + memset(, 0, sizeof(lookup));
> + lookup.slave_addr = slave_addr;
> + lookup.intel_dsi = intel_dsi;
> + lookup.dev_handle = 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex
URL   : https://patchwork.freedesktop.org/series/71889/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7720 -> Patchwork_16054


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_render_linear_blits@basic:
- fi-icl-dsi: [PASS][1] -> [DMESG-WARN][2] ([i915#109])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-x1275:   [PASS][3] -> [INCOMPLETE][4] ([i915#879])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-kbl-x1275/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/fi-kbl-x1275/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820:   [PASS][5] -> [DMESG-FAIL][6] ([i915#722])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [FAIL][7] ([i915#178]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-byt-j1900:   [DMESG-FAIL][9] ([i915#725]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-byt-j1900/igt@i915_selftest@live_blt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/fi-byt-j1900/igt@i915_selftest@live_blt.html
- fi-hsw-4770r:   [DMESG-FAIL][11] ([i915#770]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/fi-hsw-4770r/igt@i915_selftest@live_blt.html

  
 Warnings 

  * igt@runner@aborted:
- fi-kbl-8809g:   [FAIL][13] ([i915#858]) -> [FAIL][14] ([i915#192] / 
[i915#193] / [i915#194])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7720/fi-kbl-8809g/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/fi-kbl-8809g/igt@run...@aborted.html

  
  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#770]: https://gitlab.freedesktop.org/drm/intel/issues/770
  [i915#858]: https://gitlab.freedesktop.org/drm/intel/issues/858
  [i915#879]: https://gitlab.freedesktop.org/drm/intel/issues/879


Participating hosts (51 -> 42)
--

  Additional (1): fi-tgl-u 
  Missing(10): fi-bdw-5557u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ilk-650 fi-ctg-p8600 fi-byt-clapper fi-kbl-r fi-skl-6600u fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7720 -> Patchwork_16054

  CI-20190529: 20190529
  CI_DRM_7720: 3770105165843883b1422bb3bc5bc8601dfc8051 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5364: b7cb6ffdb65cbd233f5ddee2f2dabf97b34fa640 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16054: 11b779254a261dd0dbe14311b76e2f4fb12b7423 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

11b779254a26 drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16054/index.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 i915: ggtt: include asm/smp.h

2020-01-10 Thread Patchwork
== Series Details ==

Series: i915: ggtt: include asm/smp.h
URL   : https://patchwork.freedesktop.org/series/71892/
State : failure

== Summary ==

Applying: i915: ggtt: include asm/smp.h
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gt/intel_ggtt.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/gt/intel_ggtt.c
No changes -- Patch already applied.

___
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: Bump up CDCLK to eliminate underruns on TGL (rev3)

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev3)
URL   : https://patchwork.freedesktop.org/series/71760/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16045_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-hsw:  NOTRUN -> [TIMEOUT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-hsw5/igt@gem_b...@close-race.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vcs1-dirty-create:
- shard-iclb: [PASS][2] -> [SKIP][3] ([fdo#109276] / [fdo#112080])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb1/igt@gem_ctx_isolat...@vcs1-dirty-create.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-iclb7/igt@gem_ctx_isolat...@vcs1-dirty-create.html

  * igt@gem_ctx_isolation@vecs0-s3:
- shard-kbl:  [PASS][4] -> [INCOMPLETE][5] ([fdo#103665])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-kbl7/igt@gem_ctx_isolat...@vecs0-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-kbl4/igt@gem_ctx_isolat...@vecs0-s3.html

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#110841])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_ctx_shared@q-smoketest-bsd2:
- shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#461])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-tglb5/igt@gem_ctx_sha...@q-smoketest-bsd2.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-tglb4/igt@gem_ctx_sha...@q-smoketest-bsd2.html

  * igt@gem_eio@in-flight-1us:
- shard-snb:  [PASS][10] -> [FAIL][11] ([i915#490])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-snb1/igt@gem_...@in-flight-1us.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-snb4/igt@gem_...@in-flight-1us.html

  * igt@gem_eio@kms:
- shard-snb:  [PASS][12] -> [INCOMPLETE][13] ([i915#82]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-snb2/igt@gem_...@kms.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-snb1/igt@gem_...@kms.html

  * igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#112146]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb5/igt@gem_exec_as...@concurrent-writes-bsd.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#110854])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-iclb7/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_parallel@vcs1:
- shard-tglb: [PASS][18] -> [INCOMPLETE][19] ([fdo#111593] / 
[i915#472])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-tglb7/igt@gem_exec_paral...@vcs1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-tglb5/igt@gem_exec_paral...@vcs1.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][20] -> [SKIP][21] ([i915#677])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-iclb1/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_persistent_relocs@forked-interruptible-thrash-inactive:
- shard-hsw:  [PASS][22] -> [TIMEOUT][23] ([i915#530])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-hsw5/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html
   [23]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Make a copy of the ggtt view for slave plane

2020-01-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915: Make a copy of the ggtt view for 
slave plane
URL   : https://patchwork.freedesktop.org/series/71896/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16058


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_mmap_gtt@basic:
- fi-glk-dsi: [PASS][1] -> [INCOMPLETE][2] ([i915#58] / 
[k.org#198133])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-glk-dsi/igt@gem_mmap_...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-glk-dsi/igt@gem_mmap_...@basic.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([i915#217])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][5] -> [FAIL][6] ([fdo#111096] / [i915#323])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][7] ([i915#816]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][9] ([i915#937]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-ehl-1/igt@gem_exec_gttf...@basic.html

  * igt@gem_render_linear_blits@basic:
- fi-icl-dsi: [DMESG-WARN][11] ([i915#109]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [INCOMPLETE][13] ([i915#472] / [i915#707]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-tgl-y/igt@gem_s...@basic-each.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [FAIL][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  
 Warnings 

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][17] ([i915#553] / [i915#725]) -> 
[DMESG-FAIL][18] ([i915#725])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16058/fi-hsw-4770/igt@i915_selftest@live_blt.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472
  [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
  [i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
  [i915#707]: https://gitlab.freedesktop.org/drm/intel/issues/707
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (47 -> 47)
--

  Additional (5): fi-hsw-4770r fi-bdw-5557u fi-ilk-650 fi-snb-2520m 
fi-byt-n2820 
  Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 
fi-byt-clapper 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7721 -> Patchwork_16058

  CI-20190529: 20190529
  CI_DRM_7721: 3a2436c56fcf2d133d701a112eb1e0dfce0b846d @ 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add ops to intel_uc (rev4)

2020-01-10 Thread Patchwork
== Series Details ==

Series: Add ops to intel_uc (rev4)
URL   : https://patchwork.freedesktop.org/series/70716/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2e1f188d8ce3 drm/i915/uc: Add ops to intel_uc
-:147: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#147: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:73:
+#define intel_uc_ops_function(_NAME, _OPS, _TYPE, _RET) \
+static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
+{ \
+   if (uc->ops->_OPS) \
+   return uc->ops->_OPS(uc); \
+   return _RET; \
+}

-:147: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_OPS' - possible 
side-effects?
#147: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:73:
+#define intel_uc_ops_function(_NAME, _OPS, _TYPE, _RET) \
+static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
+{ \
+   if (uc->ops->_OPS) \
+   return uc->ops->_OPS(uc); \
+   return _RET; \
+}

-:147: CHECK:MACRO_ARG_PRECEDENCE: Macro argument '_OPS' may be better as 
'(_OPS)' to avoid precedence issues
#147: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:73:
+#define intel_uc_ops_function(_NAME, _OPS, _TYPE, _RET) \
+static inline _TYPE intel_uc_##_NAME(struct intel_uc *uc) \
+{ \
+   if (uc->ops->_OPS) \
+   return uc->ops->_OPS(uc); \
+   return _RET; \
+}

-:154: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#154: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:80:
+}
+intel_uc_ops_function(init_hw, init_hw, int, 0);

-:155: ERROR:SPACING: space prohibited before that close parenthesis ')'
#155: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:81:
+intel_uc_ops_function(fini_hw, fini_hw, void, );

total: 2 errors, 0 warnings, 3 checks, 119 lines checked
f899ba846e7d drm/i915/uc: Add init_fw/fini_fw to to intel_uc_ops
-:79: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#79: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:80:
 }
+intel_uc_ops_function(fetch_firmwares, init_fw, void, );

-:79: ERROR:SPACING: space prohibited before that close parenthesis ')'
#79: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:80:
+intel_uc_ops_function(fetch_firmwares, init_fw, void, );

-:80: ERROR:SPACING: space prohibited before that close parenthesis ')'
#80: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:81:
+intel_uc_ops_function(cleanup_firmwares, fini_fw, void, );

total: 2 errors, 0 warnings, 1 checks, 55 lines checked
cb2532cf174b drm/i915/uc: Add init/fini to to intel_uc_ops
-:81: ERROR:SPACING: space prohibited before that close parenthesis ')'
#81: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:82:
+intel_uc_ops_function(init, init, void, );

-:82: ERROR:SPACING: space prohibited before that close parenthesis ')'
#82: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:83:
+intel_uc_ops_function(fini, fini, void, );

total: 2 errors, 0 warnings, 0 checks, 57 lines checked
ab06f9906171 drm/i915/uc: Add sanitize to to intel_uc_ops
-:67: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#67: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:80:
 }
+intel_uc_ops_function(sanitize, sanitize, int, 0);

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

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


Re: [Intel-gfx] [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

2020-01-10 Thread Masami Hiramatsu
On Fri, 10 Jan 2020 13:45:31 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:
> > On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra  
> > wrote:
> > > Again, this only allows attaching to previously created kprobes, it does
> > > not allow creating kprobes, right?
> 
> > > That is; I don't think CAP_SYS_PERFMON should be allowed to create
> > > kprobes.
> 
> > > As might be clear; I don't actually know what the user-ABI is for
> > > creating kprobes.
> 
> > There are 2 ABIs nowadays, ftrace and ebpf. perf-probe uses ftrace 
> > interface to
> > define new kprobe events, and those events are treated as completely same as
> > tracepoint events. On the other hand, ebpf tries to define new probe event
> > via perf_event interface. Above one is that interface. IOW, it creates new 
> > kprobe.
> 
> Masami, any plans to make 'perf probe' use the perf_event_open()
> interface for creating kprobes/uprobes?

Would you mean perf probe to switch to perf_event_open()?
No, perf probe is for setting up the ftrace probe events. I think we can add an
option to use perf_event_open(). But current kprobe creation from 
perf_event_open()
is separated from ftrace by design.

I think the reason why ebpf uses perf_event_open() interface is to avoid 
conflict
with ftrace users. Those probes are temporally used by ebpf, but if it is 
appeared on
ftrace, it is easy to be used by ftrace. In that case, it can not be removed 
when
the ebpf exits.

Thank you,

-- 
Masami Hiramatsu 
___
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/dp/tgl+: Update combo phy vswing tables

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915/dp/tgl+: Update combo phy vswing tables
URL   : https://patchwork.freedesktop.org/series/71909/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16062


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16062/index.html

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_parallel@basic:
- {fi-ehl-1}: NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16062/fi-ehl-1/igt@gem_exec_paral...@basic.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_blt:
- fi-bsw-nick:[PASS][2] -> [DMESG-FAIL][3] ([i915#723])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-bsw-nick/igt@i915_selftest@live_blt.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16062/fi-bsw-nick/igt@i915_selftest@live_blt.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][4] ([i915#937]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16062/fi-ehl-1/igt@gem_exec_gttf...@basic.html

  * igt@gem_render_linear_blits@basic:
- fi-icl-dsi: [DMESG-WARN][6] ([i915#109]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16062/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [INCOMPLETE][8] ([i915#472] / [i915#707]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-tgl-y/igt@gem_s...@basic-each.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16062/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [FAIL][10] -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16062/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472
  [i915#707]: https://gitlab.freedesktop.org/drm/intel/issues/707
  [i915#723]: https://gitlab.freedesktop.org/drm/intel/issues/723
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (47 -> 42)
--

  Additional (5): fi-hsw-4770r fi-bdw-5557u fi-ilk-650 fi-kbl-7560u 
fi-byt-n2820 
  Missing(10): fi-hsw-4200u fi-bsw-n3050 fi-hsw-peppy fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-whl-u fi-skl-lmem fi-byt-clapper fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7721 -> Patchwork_16062

  CI-20190529: 20190529
  CI_DRM_7721: 3a2436c56fcf2d133d701a112eb1e0dfce0b846d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5364: b7cb6ffdb65cbd233f5ddee2f2dabf97b34fa640 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16062: 9cf64dd8e186bcd181b14d0c077f243b8c2eefe8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9cf64dd8e186 drm/i915/dp/tgl+: Update combo phy vswing tables

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915/dp/tgl+: Update combo phy vswing tables

2020-01-10 Thread Matt Roper
On Fri, Jan 10, 2020 at 03:39:02PM -0800, José Roberto de Souza wrote:
> TGL has now a table for RBR and HBR and another table for HBR2 over
> combo phys. The HBR2 one has some small changes comparing to the ICL
> one, so adding two new tables and adding a function to return TGL
> combo phy tables.
> 
> v2:
> - reordered the tgl_combo_phy_ddi_translations_dp_hbr2 to reduce diff
> (Matt)
> - removed definition of rates, kept using raw number(Jani and Ville)
> - changed code to use icl_get_combo_buf_trans() for non-DP as those
> are equal between TGL and ICL(Matt)
> 
> BSpec: 49291
> Cc: Lucas De Marchi 
> Cc: Matt Roper 
> Cc: Ville Syrjälä 
> Cc: Jani Nikula 
> Signed-off-by: José Roberto de Souza 

Matches the spec.

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 55 ++--
>  1 file changed, 51 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index fbc13f36f76f..41c433cdf60c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -622,6 +622,34 @@ static const struct tgl_dkl_phy_ddi_buf_trans 
> tgl_dkl_phy_hdmi_ddi_trans[] = {
>   { 0x0, 0x0, 0xA },  /* 10   Full-3 dB */
>  };
>  
> +static const struct cnl_ddi_buf_trans 
> tgl_combo_phy_ddi_translations_dp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0xA, 0x32, 0x3F, 0x00, 0x00 },/* 350   350  0.0   */
> + { 0xA, 0x4F, 0x37, 0x00, 0x08 },/* 350   500  3.1   */
> + { 0xC, 0x71, 0x2F, 0x00, 0x10 },/* 350   700  6.0   */
> + { 0x6, 0x7D, 0x2B, 0x00, 0x14 },/* 350   900  8.2   */
> + { 0xA, 0x4C, 0x3F, 0x00, 0x00 },/* 500   500  0.0   */
> + { 0xC, 0x73, 0x34, 0x00, 0x0B },/* 500   700  2.9   */
> + { 0x6, 0x7F, 0x2F, 0x00, 0x10 },/* 500   900  5.1   */
> + { 0xC, 0x6C, 0x3C, 0x00, 0x03 },/* 650   700  0.6   */
> + { 0x6, 0x7F, 0x35, 0x00, 0x0A },/* 600   900  3.5   */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900   900  0.0   */
> +};
> +
> +static const struct cnl_ddi_buf_trans 
> tgl_combo_phy_ddi_translations_dp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350   350  0.0   */
> + { 0xA, 0x4F, 0x37, 0x00, 0x08 },/* 350   500  3.1   */
> + { 0xC, 0x63, 0x2F, 0x00, 0x10 },/* 350   700  6.0   */
> + { 0x6, 0x7F, 0x2B, 0x00, 0x14 },/* 350   900  8.2   */
> + { 0xA, 0x47, 0x3F, 0x00, 0x00 },/* 500   500  0.0   */
> + { 0xC, 0x63, 0x34, 0x00, 0x0B },/* 500   700  2.9   */
> + { 0x6, 0x7F, 0x2F, 0x00, 0x10 },/* 500   900  5.1   */
> + { 0xC, 0x61, 0x3C, 0x00, 0x03 },/* 650   700  0.6   */
> + { 0x6, 0x7B, 0x35, 0x00, 0x0A },/* 600   900  3.5   */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900   900  0.0   */
> +};
> +
>  static const struct ddi_buf_trans *
>  bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
>  {
> @@ -901,6 +929,21 @@ icl_get_combo_buf_trans(struct drm_i915_private 
> *dev_priv, int type, int rate,
>   return icl_combo_phy_ddi_translations_dp_hbr2;
>  }
>  
> +static const struct cnl_ddi_buf_trans *
> +tgl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int type, int 
> rate,
> + int *n_entries)
> +{
> + if (type != INTEL_OUTPUT_DP) {
> + return icl_get_combo_buf_trans(dev_priv, type, rate, n_entries);
> + } else if (rate > 27) {
> + *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
> + return tgl_combo_phy_ddi_translations_dp_hbr2;
> + }
> +
> + *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
> + return tgl_combo_phy_ddi_translations_dp_hbr;
> +}
> +
>  static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv, enum port 
> port)
>  {
>   struct ddi_vbt_port_info *port_info = 
> _priv->vbt.ddi_port_info[port];
> @@ -909,7 +952,7 @@ static int intel_ddi_hdmi_level(struct drm_i915_private 
> *dev_priv, enum port por
>  
>   if (INTEL_GEN(dev_priv) >= 12) {
>   if (intel_phy_is_combo(dev_priv, phy))
> - icl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
> + tgl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
>   0, _entries);
>   else
>   n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
> @@ -2372,7 +2415,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder 
> *encoder)
>  
>   if (INTEL_GEN(dev_priv) >= 12) {
>   if (intel_phy_is_combo(dev_priv, phy))
> - 

[Intel-gfx] [PATCH] drm/i915/gen11: Add additional pcode status values

2020-01-10 Thread Matt Roper
I don't think we've ever hit these new error codes, but they're
documented in the gen11 pcode document, so we might as well add them to
the handler.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_reg.h   | 2 ++
 drivers/gpu/drm/i915/intel_sideband.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6cc55c103f67..e5071af4a3b3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8987,6 +8987,8 @@ enum {
 #define GEN6_PCODE_UNIMPLEMENTED_CMD   0xFF
 #define GEN7_PCODE_TIMEOUT 0x2
 #define GEN7_PCODE_ILLEGAL_DATA0x3
+#define GEN11_PCODE_ILLEGAL_SUBCOMMAND 0x4
+#define GEN11_PCODE_LOCKED 0x6
 #define GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE 0x10
 #define   GEN6_PCODE_WRITE_RC6VIDS 0x4
 #define   GEN6_PCODE_READ_RC6VIDS  0x5
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index cbfb7171d62d..3361fdc41ee1 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -365,6 +365,10 @@ static inline int gen7_check_mailbox_status(u32 mbox)
return -ETIMEDOUT;
case GEN7_PCODE_ILLEGAL_DATA:
return -EINVAL;
+   case GEN11_PCODE_ILLEGAL_SUBCOMMAND:
+   return -ENXIO;
+   case GEN11_PCODE_LOCKED:
+   return -EBUSY;
case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
return -EOVERFLOW;
default:
-- 
2.23.0

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


[Intel-gfx] [drm-intel:for-linux-next 4/7] drivers/gpu/drm/i915/selftests/../i915_gpu_error.h:317:6: error: conflicting types for 'i915_vma_compress_prepare'

2020-01-10 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   1a8585bd774c4058038ad827c9e93847ff509cf3
commit: 742379c0c4001fd2a6e02005c1ffa1ff611b28fa [4/7] drm/i915: Start chopping 
up the GPU error capture
config: x86_64-randconfig-s1-20200111 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2
reproduce:
git checkout 742379c0c4001fd2a6e02005c1ffa1ff611b28fa
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/i915/selftests/../i915_drv.h:97:0,
from drivers/gpu/drm/i915/selftests/igt_reset.c:12:
>> drivers/gpu/drm/i915/selftests/../i915_gpu_error.h:317:6: error: conflicting 
>> types for 'i915_vma_compress_prepare'
void i915_vma_compress_prepare(struct i915_vma_compress *compress)
 ^
   drivers/gpu/drm/i915/selftests/../i915_gpu_error.h:312:1: note: previous 
definition of 'i915_vma_compress_prepare' was here
i915_vma_compress_prepare(struct intel_gt_coredump *gt)
^

vim +/i915_vma_compress_prepare +317 
drivers/gpu/drm/i915/selftests/../i915_gpu_error.h

   316  
 > 317  void i915_vma_compress_prepare(struct i915_vma_compress *compress)
   318  {
   319  }
   320  

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


.config.gz
Description: application/gzip
___
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/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER
URL   : https://patchwork.freedesktop.org/series/71912/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16063


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2:  [PASS][1] -> [INCOMPLETE][2] ([i915#671])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
- fi-bxt-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#889])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-bxt-dsi/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-bxt-dsi/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [PASS][5] -> [FAIL][6] ([i915#178])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-ivb-3770:[PASS][7] -> [DMESG-FAIL][8] ([i915#725])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-ivb-3770/igt@i915_selftest@live_blt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-ivb-3770/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [PASS][9] -> [DMESG-FAIL][10] ([i915#656])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][11] ([i915#816]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@gem_render_linear_blits@basic:
- fi-icl-dsi: [DMESG-WARN][13] ([i915#109]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [INCOMPLETE][15] ([i915#472] / [i915#707]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-tgl-y/igt@gem_s...@basic-each.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][17] ([i915#553] / [i915#725]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [FAIL][19] -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16063/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  
  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472
  [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#671]: https://gitlab.freedesktop.org/drm/intel/issues/671
  [i915#707]: https://gitlab.freedesktop.org/drm/intel/issues/707
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
  [i915#889]: https://gitlab.freedesktop.org/drm/intel/issues/889


Participating hosts (47 -> 46)
--

  Additional (5): fi-hsw-4770r fi-bdw-5557u fi-ilk-650 fi-snb-2520m 
fi-byt-n2820 
  Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 
fi-byt-clapper fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7721 -> Patchwork_16063

  CI-20190529: 20190529
  CI_DRM_7721: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Add additional pcode status values

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm/i915/gen11: Add additional pcode status values
URL   : https://patchwork.freedesktop.org/series/71915/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16064


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16064/index.html

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][1] ([i915#816]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16064/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@gem_render_linear_blits@basic:
- fi-icl-dsi: [DMESG-WARN][3] ([i915#109]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16064/fi-icl-dsi/igt@gem_render_linear_bl...@basic.html

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [INCOMPLETE][5] ([i915#472] / [i915#707]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-tgl-y/igt@gem_s...@basic-each.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16064/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][7] ([i915#553] / [i915#725]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16064/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [FAIL][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7721/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16064/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472
  [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
  [i915#707]: https://gitlab.freedesktop.org/drm/intel/issues/707
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (47 -> 41)
--

  Additional (5): fi-hsw-4770r fi-bdw-5557u fi-ilk-650 fi-snb-2520m 
fi-byt-n2820 
  Missing(11): fi-bsw-n3050 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-ivb-3770 fi-byt-clapper fi-bsw-nick fi-skl-6600u 
fi-kbl-r 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7721 -> Patchwork_16064

  CI-20190529: 20190529
  CI_DRM_7721: 3a2436c56fcf2d133d701a112eb1e0dfce0b846d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5364: b7cb6ffdb65cbd233f5ddee2f2dabf97b34fa640 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16064: 0be96c28820e8b0ddd44b1d2862463288afce773 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0be96c28820e drm/i915/gen11: Add additional pcode status values

== Logs ==

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


Re: [Intel-gfx] [PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs

2020-01-10 Thread Jani Nikula
On Fri, 10 Jan 2020, Thomas Zimmermann  wrote:
> The new callback get_scanout_position() reads the current location of
> the scanout process. The operation is currentyl located in struct
> drm_driver, but really belongs to the CRTC. Drivers will be converted
> in separate patches.
>
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_vblank.c | 24 
>  include/drm/drm_drv.h|  7 +---
>  include/drm/drm_modeset_helper_vtables.h | 47 
>  3 files changed, 65 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 1659b13b178c..c12f0b333e14 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -590,7 +591,7 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
>   * Implements calculation of exact vblank timestamps from given 
> drm_display_mode
>   * timings and current video scanout position of a CRTC. This can be directly
>   * used as the _driver.get_vblank_timestamp implementation of a kms 
> driver
> - * if _driver.get_scanout_position is implemented.
> + * if _crtc_helper_funcs.get_scanout_position is implemented.
>   *
>   * The current implementation only handles standard video modes. For double 
> scan
>   * and interlaced modes the driver is supposed to adjust the hardware mode
> @@ -632,8 +633,9 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
> drm_device *dev,
>   }
>  
>   /* Scanout position query not supported? Should not happen. */
> - if (!dev->driver->get_scanout_position) {
> - DRM_ERROR("Called from driver w/o get_scanout_position()!?\n");
> + if (!dev->driver->get_scanout_position ||
> + !crtc->helper_private->get_scanout_position) {

ITYM s/||/&&/

BR,
Jani.


> + DRM_ERROR("Called from CRTC w/o get_scanout_position()!?\n");
>   return false;
>   }
>  
> @@ -664,11 +666,17 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
> drm_device *dev,
>* Get vertical and horizontal scanout position vpos, hpos,
>* and bounding timestamps stime, etime, pre/post query.
>*/
> - vbl_status = dev->driver->get_scanout_position(dev, pipe,
> -in_vblank_irq,
> -, ,
> -, ,
> -mode);
> + if (crtc->helper_private->get_scanout_position) {
> + vbl_status =
> + crtc->helper_private->get_scanout_position(
> + crtc, in_vblank_irq, , ,
> + , , mode);
> + } else {
> + vbl_status =
> + dev->driver->get_scanout_position(
> + dev, pipe, in_vblank_irq, ,
> + , , , mode);
> + }
>  
>   /* Return as no-op if scanout query unsupported or failed. */
>   if (!vbl_status) {
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index cf13470810a5..d0049e5786fc 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -362,11 +362,8 @@ struct drm_driver {
>* True on success, false if a reliable scanout position counter could
>* not be read out.
>*
> -  * FIXME:
> -  *
> -  * Since this is a helper to implement @get_vblank_timestamp, we should
> -  * move it to  drm_crtc_helper_funcs, like all the other
> -  * helper-internal hooks.
> +  * This is deprecated and should not be used by new drivers.
> +  * Use _crtc_helper_funcs.get_scanout_position instead.
>*/
>   bool (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
> bool in_vblank_irq, int *vpos, int *hpos,
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index 5a87f1bd7a3f..e398512bfd5f 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -450,6 +450,53 @@ struct drm_crtc_helper_funcs {
>*/
>   void (*atomic_disable)(struct drm_crtc *crtc,
>  struct drm_crtc_state *old_crtc_state);
> +
> + /**
> +  * @get_scanout_position:
> +  *
> +  * Called by vblank timestamping code.
> +  *
> +  * Returns the current display scanout position from a CRTC and an
> +  * optional accurate ktime_get() timestamp of when the position was
> +  * measured. Note that this is a helper callback which is only used
> +  * if a driver uses 

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Drop the shadow ring state from the error capture

2020-01-10 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2020-01-09 09:04:31)
>> Chris Wilson  writes:
>> 
>> > The shadow ring regs (ring->head, ring->tail) are meaningless in the
>> > post-mortem dump as they do not related to anything on HW. Remove them
>> > from the coredump.
>> 
>> We have been dumping these just to check that our bookkeepping matches?
>
> Kind off, but they never really match since the ring->head is very lazy,
> and ring->tail is wherever the user got up to. We have the relevant
> information from the request where we expect to be in the ring for the
> error, and the HW tells us where it was executing.
> -Chris

Ok, based on that and that  don't remember a single case where,
from external reports, these would have provided anything of value.

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 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()

2020-01-10 Thread Jani Nikula
On Fri, 10 Jan 2020, Thomas Zimmermann  wrote:
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position().
>
> i915 doesn't use CRTC helpers. The patch duplicates the caller
> drm_calc_vbltimestamp_from_scanoutpos() for i915, such that the callback
> function is not needed.
>
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |   3 +-
>  drivers/gpu/drm/i915/i915_irq.c | 117 ++--
>  drivers/gpu/drm/i915/i915_irq.h |   9 +--
>  3 files changed, 119 insertions(+), 10 deletions(-)

Not really enthusiastic about the diffstat in a "cleanup" series.

I wonder if you could add a generic helper version of
drm_calc_vbltimestamp_from_scanoutpos where you pass the
get_scanout_position function as a parameter. Both
drm_calc_vbltimestamp_from_scanoutpos and the new
i915_calc_vbltimestamp_from_scanoutpos would then be fairly thin
wrappers passing in the relevant get_scanout_position function.

This would reduce the almost identical duplication of the function in
i915.

BR,
Jani.

>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f7385abdd74b..4a0a7fb85c53 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2769,8 +2769,7 @@ static struct drm_driver driver = {
>   .gem_prime_export = i915_gem_prime_export,
>   .gem_prime_import = i915_gem_prime_import,
>  
> - .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> - .get_scanout_position = i915_get_crtc_scanoutpos,
> + .get_vblank_timestamp = i915_calc_vbltimestamp_from_scanoutpos,
>  
>   .dumb_create = i915_gem_dumb_create,
>   .dumb_map_offset = i915_gem_dumb_mmap_offset,
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index afc6aad9bf8c..99d0c3b0feae 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -52,6 +52,11 @@
>  #include "i915_trace.h"
>  #include "intel_pm.h"
>  
> +/* Retry timestamp calculation up to 3 times to satisfy
> + * drm_timestamp_precision before giving up.
> + */
> +#define I915_TIMESTAMP_MAXRETRIES 3
> +
>  /**
>   * DOC: interrupt handling
>   *
> @@ -762,10 +767,11 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
> *crtc)
>   return (position + crtc->scanline_offset) % vtotal;
>  }
>  
> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int index,
> -   bool in_vblank_irq, int *vpos, int *hpos,
> -   ktime_t *stime, ktime_t *etime,
> -   const struct drm_display_mode *mode)
> +static bool i915_get_crtc_scanoutpos(struct drm_device *dev,
> +  unsigned int index, bool in_vblank_irq,
> +  int *vpos, int *hpos,
> +  ktime_t *stime, ktime_t *etime,
> +  const struct drm_display_mode *mode)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *crtc = to_intel_crtc(drm_crtc_from_index(dev, 
> index));
> @@ -879,6 +885,109 @@ bool i915_get_crtc_scanoutpos(struct drm_device *dev, 
> unsigned int index,
>   return true;
>  }
>  
> +bool i915_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
> + unsigned int pipe,
> + int *max_error,
> + ktime_t *vblank_time,
> + bool in_vblank_irq)
> +{
> + struct timespec64 ts_etime, ts_vblank_time;
> + ktime_t stime, etime;
> + bool vbl_status;
> + struct drm_crtc *crtc;
> + const struct drm_display_mode *mode;
> + struct drm_vblank_crtc *vblank = >vblank[pipe];
> + int vpos, hpos, i;
> + int delta_ns, duration_ns;
> +
> + crtc = drm_crtc_from_index(dev, pipe);
> +
> + if (pipe >= dev->num_crtcs || !crtc) {
> + DRM_ERROR("Invalid crtc %u\n", pipe);
> + return false;
> + }
> +
> + if (drm_drv_uses_atomic_modeset(dev))
> + mode = >hwmode;
> + else
> + mode = >hwmode;
> +
> + /* If mode timing undefined, just return as no-op:
> +  * Happens during initial modesetting of a crtc.
> +  */
> + if (mode->crtc_clock == 0) {
> + DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
> + WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
> +
> + return false;
> + }
> +
> + /* Get current scanout position with system timestamp.
> +  * Repeat query up to DRM_TIMESTAMP_MAXRETRIES times
> +  * if single query takes longer than max_error nanoseconds.
> +  *
> +  * This guarantees a tight bound on maximum error if
> +  * code gets preempted or delayed for some reason.
> +  */
> + for (i = 0; i < 

[Intel-gfx] [CI 1/4] drm/i915: Start chopping up the GPU error capture

2020-01-10 Thread Chris Wilson
In the near future, we will want to start a GPU error capture from a new
context, from inside the softirq region of a forced preemption. To do
so requires us to break up the monolithic error capture to provide new
entry points with finer control; in particular focusing on one
engine/gt, and being able to compose an error state from little pieces
of HW capture.

Signed-off-by: Chris Wilson 
Cc: Andi Shyti 
Acked-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_engine.h   |2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c|6 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |3 +
 drivers/gpu/drm/i915/gt/intel_gtt.h  |1 +
 drivers/gpu/drm/i915/gt/intel_reset.c|2 +-
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |   14 +-
 drivers/gpu/drm/i915/i915_drv.h  |2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c| 1179 ++
 drivers/gpu/drm/i915/i915_gpu_error.h|  328 +++--
 drivers/gpu/drm/i915/i915_sysfs.c|6 +-
 11 files changed, 873 insertions(+), 672 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 71f1bcdfc92f..5df003061e44 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -202,7 +202,7 @@ void intel_engine_set_hwsp_writemask(struct intel_engine_cs 
*engine, u32 mask);
 u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
 u64 intel_engine_get_last_batch_head(const struct intel_engine_cs *engine);
 
-void intel_engine_get_instdone(struct intel_engine_cs *engine,
+void intel_engine_get_instdone(const struct intel_engine_cs *engine,
   struct intel_instdone *instdone);
 
 void intel_engine_init_execlists(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 825c94e7ca0b..f451ef376548 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -914,8 +914,8 @@ const char *i915_cache_level_str(struct drm_i915_private 
*i915, int type)
 }
 
 static u32
-read_subslice_reg(struct intel_engine_cs *engine, int slice, int subslice,
- i915_reg_t reg)
+read_subslice_reg(const struct intel_engine_cs *engine,
+ int slice, int subslice, i915_reg_t reg)
 {
struct drm_i915_private *i915 = engine->i915;
struct intel_uncore *uncore = engine->uncore;
@@ -959,7 +959,7 @@ read_subslice_reg(struct intel_engine_cs *engine, int 
slice, int subslice,
 }
 
 /* NB: please notice the memset */
-void intel_engine_get_instdone(struct intel_engine_cs *engine,
+void intel_engine_get_instdone(const struct intel_engine_cs *engine,
   struct intel_instdone *instdone)
 {
struct drm_i915_private *i915 = engine->i915;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 795cd267e28e..5dba7344d7ab 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -495,6 +495,7 @@ static void cleanup_init_ggtt(struct i915_ggtt *ggtt)
ggtt_release_guc_top(ggtt);
if (drm_mm_node_allocated(>error_capture))
drm_mm_remove_node(>error_capture);
+   mutex_destroy(>error_mutex);
 }
 
 static int init_ggtt(struct i915_ggtt *ggtt)
@@ -526,6 +527,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
if (ret)
return ret;
 
+   mutex_init(>error_mutex);
if (ggtt->mappable_end) {
/* Reserve a mappable slot for our lockless error capture */
ret = drm_mm_insert_node_in_range(>vm.mm,
@@ -716,6 +718,7 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
 
if (drm_mm_node_allocated(>error_capture))
drm_mm_remove_node(>error_capture);
+   mutex_destroy(>error_mutex);
 
ggtt_release_guc_top(ggtt);
intel_vgt_deballoon(ggtt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 029363cbdf49..7da7681c20b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -345,6 +345,7 @@ struct i915_ggtt {
/* Manual runtime pm autosuspend delay for user GGTT mmaps */
struct intel_wakeref_auto userfault_wakeref;
 
+   struct mutex error_mutex;
struct drm_mm_node error_capture;
struct drm_mm_node uc_fw;
 };
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 76de33ae9efe..beee0cf89bce 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1230,7 +1230,7 @@ void intel_gt_handle_error(struct intel_gt *gt,
engine_mask &= INTEL_INFO(gt->i915)->engine_mask;
 
if (flags & I915_ERROR_CAPTURE) {
-   i915_capture_error_state(gt->i915, 

[Intel-gfx] [CI 2/4] drm/i915: Drop the shadow w/a batch buffer

2020-01-10 Thread Chris Wilson
While this is technically the batch as executed by the HW (in part at
least), it is confusing, and only used for a minority of gen.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
Acked-by: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index faa93c4296a7..b2b34be8eb0a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1428,8 +1428,6 @@ intel_engine_coredump_add_request(struct 
intel_engine_coredump *ee,
vma = capture_user(vma, rq, gfp);
vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
vma = capture_vma(vma, rq->context->state, "HW context", gfp);
-   if (HAS_BROKEN_CS_TLB(rq->i915))
-   vma = capture_vma(vma, ee->engine->gt->scratch, "WA batch", 
gfp);
 
ee->cpu_ring_head = rq->ring->head;
ee->cpu_ring_tail = rq->ring->tail;
-- 
2.25.0.rc2

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


[Intel-gfx] [CI 3/4] drm/i915: Drop the shadow ring state from the error capture

2020-01-10 Thread Chris Wilson
The shadow ring regs (ring->head, ring->tail) are meaningless in the
post-mortem dump as they do not related to anything on HW. Remove them
from the coredump.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 5 -
 drivers/gpu/drm/i915/i915_gpu_error.h | 4 
 2 files changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index b2b34be8eb0a..79eae3708602 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -553,8 +553,6 @@ static void error_print_engine(struct 
drm_i915_error_state_buf *m,
   ee->vm_info.pp_dir_base);
}
}
-   err_printf(m, "  ring->head: 0x%08x\n", ee->cpu_ring_head);
-   err_printf(m, "  ring->tail: 0x%08x\n", ee->cpu_ring_tail);
err_printf(m, "  engine reset count: %u\n", ee->reset_count);
 
for (n = 0; n < ee->num_ports; n++) {
@@ -1429,9 +1427,6 @@ intel_engine_coredump_add_request(struct 
intel_engine_coredump *ee,
vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
vma = capture_vma(vma, rq->context->state, "HW context", gfp);
 
-   ee->cpu_ring_head = rq->ring->head;
-   ee->cpu_ring_tail = rq->ring->tail;
-
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
ee->rq_tail = rq->tail;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 0df9d8c32056..8f4579d64d8c 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -66,10 +66,6 @@ struct intel_engine_coredump {
/* position of active request inside the ring */
u32 rq_head, rq_post, rq_tail;
 
-   /* our own tracking of ring head and tail */
-   u32 cpu_ring_head;
-   u32 cpu_ring_tail;
-
/* Register state */
u32 ccid;
u32 start;
-- 
2.25.0.rc2

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


[Intel-gfx] [CI 4/4] drm/i915: Drop request list from error state

2020-01-10 Thread Chris Wilson
The list of requests from after the hang tells little about the hang
itself, only how busy userspace was after the fact. As it pertains
nothing to the HW state, drop it from the error state.

Signed-off-by: Chris Wilson 
Acked-by: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 75 +++
 drivers/gpu/drm/i915/i915_gpu_error.h |  3 +-
 2 files changed, 8 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 79eae3708602..95635daca4c4 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -669,7 +669,7 @@ static void err_print_gt(struct drm_i915_error_state_buf *m,
 struct intel_gt_coredump *gt)
 {
const struct intel_engine_coredump *ee;
-   int i, j;
+   int i;
 
err_printf(m, "GT awake: %s\n", yesno(gt->awake));
err_printf(m, "EIR: 0x%08x\n", gt->eir);
@@ -715,17 +715,8 @@ static void err_print_gt(struct drm_i915_error_state_buf 
*m,
const struct i915_vma_coredump *vma;
 
error_print_engine(m, ee);
-
for (vma = ee->vma; vma; vma = vma->next)
print_error_vma(m, ee->engine, vma);
-
-   if (ee->num_requests) {
-   err_printf(m, "%s --- %d requests\n",
-  ee->engine->name,
-  ee->num_requests);
-   for (j = 0; j < ee->num_requests; j++)
-   error_print_request(m, " ", >requests[j]);
-   }
}
 
if (gt->uc)
@@ -936,7 +927,6 @@ static void cleanup_gt(struct intel_gt_coredump *gt)
gt->engine = ee->next;
 
i915_vma_coredump_free(ee->vma);
-   kfree(ee->requests);
kfree(ee);
}
 
@@ -1221,54 +1211,6 @@ static void record_request(const struct i915_request 
*request,
rcu_read_unlock();
 }
 
-static void engine_record_requests(const struct intel_engine_cs *engine,
-  struct i915_request *first,
-  struct intel_engine_coredump *ee)
-{
-   struct i915_request *request;
-   int count;
-
-   count = 0;
-   request = first;
-   list_for_each_entry_from(request, >active.requests, sched.link)
-   count++;
-   if (!count)
-   return;
-
-   ee->requests = kcalloc(count, sizeof(*ee->requests), ATOMIC_MAYFAIL);
-   if (!ee->requests)
-   return;
-
-   ee->num_requests = count;
-
-   count = 0;
-   request = first;
-   list_for_each_entry_from(request,
->active.requests, sched.link) {
-   if (count >= ee->num_requests) {
-   /*
-* If the ring request list was changed in
-* between the point where the error request
-* list was created and dimensioned and this
-* point then just exit early to avoid crashes.
-*
-* We don't need to communicate that the
-* request list changed state during error
-* state capture and that the error state is
-* slightly incorrect as a consequence since we
-* are typically only interested in the request
-* list state at the point of error state
-* capture, not in any changes happening during
-* the capture.
-*/
-   break;
-   }
-
-   record_request(request, >requests[count++]);
-   }
-   ee->num_requests = count;
-}
-
 static void engine_record_execlists(struct intel_engine_coredump *ee)
 {
const struct intel_engine_execlists * const el = >engine->execlists;
@@ -1480,7 +1422,7 @@ static struct intel_engine_coredump *
 capture_engine(struct intel_engine_cs *engine,
   struct i915_vma_compress *compress)
 {
-   struct intel_engine_capture_vma *capture;
+   struct intel_engine_capture_vma *capture = NULL;
struct intel_engine_coredump *ee;
struct i915_request *rq;
unsigned long flags;
@@ -1490,19 +1432,16 @@ capture_engine(struct intel_engine_cs *engine,
return NULL;
 
spin_lock_irqsave(>active.lock, flags);
-
rq = intel_engine_find_active_request(engine);
-   if (!rq) {
-   spin_unlock_irqrestore(>active.lock, flags);
+   if (rq)
+   capture = intel_engine_coredump_add_request(ee, rq,
+   ATOMIC_MAYFAIL);
+   spin_unlock_irqrestore(>active.lock, flags);
+   if (!capture) {
kfree(ee);
return NULL;
  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Clean up VBLANK callbacks in struct drm_driver

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm: Clean up VBLANK callbacks in struct drm_driver
URL   : https://patchwork.freedesktop.org/series/71873/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
Okay!

Commit: drm/amdgpu: Convert to struct 
drm_crtc_helper_funcs.get_scanout_position()
-drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4937:6: warning: 
symbol 'dm_drm_plane_destroy_state' was not declared. Should it be static?
+drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4938:6: warning: 
symbol 'dm_drm_plane_destroy_state' was not declared. Should it be static?
-drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8232:6: warning: 
symbol 'amdgpu_dm_psr_enable' was not declared. Should it be static?
+drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8233:6: warning: 
symbol 'amdgpu_dm_psr_enable' was not declared. Should it be static?

Commit: drm/i915: Don't use struct drm_driver.get_scanout_position()
Okay!

Commit: drm/nouveau: Convert to struct 
drm_crtc_helper_funcs.get_scanout_position()
Okay!

Commit: drm/radeon: Convert to struct 
drm_crtc_helper_funcs.get_scanout_position()
Okay!

Commit: drm/msm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()
Okay!

Commit: drm/vc4: Convert to struct drm_crtc_helper_funcs.get_scanout_position()
Okay!

Commit: drm/stm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()
Okay!

Commit: drm: Remove struct drm_driver.get_scanout_position()
Okay!

Commit: drm: Evaluate struct drm_device.vblank_disable_immediate on each use
Okay!

Commit: drm: Add get_vblank_timestamp() to struct drm_crtc_funcs
Okay!

Commit: drm/amdgpu: Convert to CRTC VBLANK callbacks
-drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4938:6: warning: 
symbol 'dm_drm_plane_destroy_state' was not declared. Should it be static?
+drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4940:6: warning: 
symbol 'dm_drm_plane_destroy_state' was not declared. Should it be static?
-drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8233:6: warning: 
symbol 'amdgpu_dm_psr_enable' was not declared. Should it be static?
+drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8235:6: warning: 
symbol 'amdgpu_dm_psr_enable' was not declared. Should it be static?

Commit: drm/gma500: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/i915: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/msm: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/nouveau: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/radeon: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/sti: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/stm: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/vc4: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/vkms: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm/vmwgfx: Convert to CRTC VBLANK callbacks
Okay!

Commit: drm: Cleanup VBLANK callbacks in struct drm_driver
Okay!

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


Re: [Intel-gfx] [PATCH 12/14] drm/i915: Drop the shadow w/a batch buffer

2020-01-10 Thread Andi Shyti
Hi Chris,

On Thu, Jan 09, 2020 at 08:58:37AM +, Chris Wilson wrote:
> While this is technically the batch as executed by the HW (in part at
> least), it is confusing, and only used for a minority of gen.
> 
> Signed-off-by: Chris Wilson 

Acked-by: Andi Shyti 

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


Re: [Intel-gfx] [PATCH] drm/i915/pmu: Do not use colon characters in PMU names

2020-01-10 Thread Tvrtko Ursulin



On 10/01/2020 11:32, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-01-10 11:27:55)


On 10/01/2020 11:21, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-01-10 11:11:26)

From: Tvrtko Ursulin 

We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs. But since tools/perf reserves a special meaning to
the colon character we need to transliterate them to something else. We
choose a dash.

Signed-off-by: Tvrtko Ursulin 
Reported-by: Dmitry Rogozhkin 
Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Andi Kleen 
---
   drivers/gpu/drm/i915/i915_pmu.c | 14 --
   1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f3ef6700a5f2..ecbd0e1f1a90 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -1117,12 +1117,22 @@ void i915_pmu_register(struct drm_i915_private *i915)
  hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
  pmu->timer.function = i915_sample;
   
-   if (!is_igp(i915))

+   if (!is_igp(i915)) {
  pmu->name = kasprintf(GFP_KERNEL,
"i915-%s",
dev_name(i915->drm.dev));
-   else
+   if (pmu->name) {


/* tools/perf reserves colons as special. */
strreplace(pmu->name, ':', '-');


I didn't know this exists, thanks.


I worry because the err_idx pointed to the '-'. We may have to use _


What is err_idx? But yes.. it would had served me well to test before
sending. :) I just find identifiers with a mix of underscores and dashes
so visually unappealing. :(


event syntax error: 'i915-:00:02.0/bcs0-busy/'
  \___ parser error

The parser sets err_idx on the character it failed at, and the error
message includes it. So unless we lost whitespace in all the cutting and
pasting, that says it barfed at '-'


Oh right, interesting that it has no problem with a dash in event name. 
In v2 full event string is:


  i915__00_02.0/vcs0-busy/

A bit ugly but seems to work.

Regards,

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reduce warning for i915_vma_pin_iomap() without runtime-pm

2020-01-10 Thread Mika Kuoppala
Chris Wilson  writes:

> Access through the GGTT (iomap) into the vma does require the device to
> be awake. However, we often take the i915_vma_pin_iomap() as an early
> preparatory step that is long before we use the iomap. Asserting that
> the device is awake at pin time does not protect us, and is merely a
> nuisance.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

I do remember stamping this. No matter, i have plenty of ink.

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_vma.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index cbd783c31adb..43d5c270bdb0 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -423,8 +423,6 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
>   void __iomem *ptr;
>   int err;
>  
> - /* Access through the GTT requires the device to be awake. */
> - assert_rpm_wakelock_held(vma->vm->gt->uncore->rpm);
>   if (GEM_WARN_ON(!i915_vma_is_map_and_fenceable(vma))) {
>   err = -ENODEV;
>   goto err;
> @@ -456,6 +454,8 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
>   goto err_unpin;
>  
>   i915_vma_set_ggtt_write(vma);
> +
> + /* NB Access through the GTT requires the device to be awake. */
>   return ptr;
>  
>  err_unpin:
> -- 
> 2.25.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()

2020-01-10 Thread Thomas Zimmermann
Hi

Am 10.01.20 um 12:59 schrieb Jani Nikula:
> On Fri, 10 Jan 2020, Thomas Zimmermann  wrote:
>> The callback struct drm_driver.get_scanout_position() is deprecated in
>> favor of struct drm_crtc_helper_funcs.get_scanout_position().
>>
>> i915 doesn't use CRTC helpers. The patch duplicates the caller
>> drm_calc_vbltimestamp_from_scanoutpos() for i915, such that the callback
>> function is not needed.
>>
>> Signed-off-by: Thomas Zimmermann 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.c |   3 +-
>>  drivers/gpu/drm/i915/i915_irq.c | 117 ++--
>>  drivers/gpu/drm/i915/i915_irq.h |   9 +--
>>  3 files changed, 119 insertions(+), 10 deletions(-)
> 
> Not really enthusiastic about the diffstat in a "cleanup" series.

Well, the cleanup is about the content of drm_driver :)

> 
> I wonder if you could add a generic helper version of
> drm_calc_vbltimestamp_from_scanoutpos where you pass the
> get_scanout_position function as a parameter. Both
> drm_calc_vbltimestamp_from_scanoutpos and the new
> i915_calc_vbltimestamp_from_scanoutpos would then be fairly thin
> wrappers passing in the relevant get_scanout_position function.

Of course. Will be in v2 of the series.

Best regards
Thomas

> 
> This would reduce the almost identical duplication of the function in
> i915.
> 
> BR,
> Jani.
> 
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index f7385abdd74b..4a0a7fb85c53 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -2769,8 +2769,7 @@ static struct drm_driver driver = {
>>  .gem_prime_export = i915_gem_prime_export,
>>  .gem_prime_import = i915_gem_prime_import,
>>  
>> -.get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
>> -.get_scanout_position = i915_get_crtc_scanoutpos,
>> +.get_vblank_timestamp = i915_calc_vbltimestamp_from_scanoutpos,
>>  
>>  .dumb_create = i915_gem_dumb_create,
>>  .dumb_map_offset = i915_gem_dumb_mmap_offset,
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index afc6aad9bf8c..99d0c3b0feae 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -52,6 +52,11 @@
>>  #include "i915_trace.h"
>>  #include "intel_pm.h"
>>  
>> +/* Retry timestamp calculation up to 3 times to satisfy
>> + * drm_timestamp_precision before giving up.
>> + */
>> +#define I915_TIMESTAMP_MAXRETRIES 3
>> +
>>  /**
>>   * DOC: interrupt handling
>>   *
>> @@ -762,10 +767,11 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
>> *crtc)
>>  return (position + crtc->scanline_offset) % vtotal;
>>  }
>>  
>> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int index,
>> -  bool in_vblank_irq, int *vpos, int *hpos,
>> -  ktime_t *stime, ktime_t *etime,
>> -  const struct drm_display_mode *mode)
>> +static bool i915_get_crtc_scanoutpos(struct drm_device *dev,
>> + unsigned int index, bool in_vblank_irq,
>> + int *vpos, int *hpos,
>> + ktime_t *stime, ktime_t *etime,
>> + const struct drm_display_mode *mode)
>>  {
>>  struct drm_i915_private *dev_priv = to_i915(dev);
>>  struct intel_crtc *crtc = to_intel_crtc(drm_crtc_from_index(dev, 
>> index));
>> @@ -879,6 +885,109 @@ bool i915_get_crtc_scanoutpos(struct drm_device *dev, 
>> unsigned int index,
>>  return true;
>>  }
>>  
>> +bool i915_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
>> +unsigned int pipe,
>> +int *max_error,
>> +ktime_t *vblank_time,
>> +bool in_vblank_irq)
>> +{
>> +struct timespec64 ts_etime, ts_vblank_time;
>> +ktime_t stime, etime;
>> +bool vbl_status;
>> +struct drm_crtc *crtc;
>> +const struct drm_display_mode *mode;
>> +struct drm_vblank_crtc *vblank = >vblank[pipe];
>> +int vpos, hpos, i;
>> +int delta_ns, duration_ns;
>> +
>> +crtc = drm_crtc_from_index(dev, pipe);
>> +
>> +if (pipe >= dev->num_crtcs || !crtc) {
>> +DRM_ERROR("Invalid crtc %u\n", pipe);
>> +return false;
>> +}
>> +
>> +if (drm_drv_uses_atomic_modeset(dev))
>> +mode = >hwmode;
>> +else
>> +mode = >hwmode;
>> +
>> +/* If mode timing undefined, just return as no-op:
>> + * Happens during initial modesetting of a crtc.
>> + */
>> +if (mode->crtc_clock == 0) {
>> +DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
>> +WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
>> +
>> +return false;
>> +}
>> +
>> +/* Get current scanout position with system timestamp.
>> + * Repeat query up to 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Clean up VBLANK callbacks in struct drm_driver

2020-01-10 Thread Patchwork
== Series Details ==

Series: drm: Clean up VBLANK callbacks in struct drm_driver
URL   : https://patchwork.freedesktop.org/series/71873/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7715 -> Patchwork_16048


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-skl-6700k2:  [PASS][1] -> [INCOMPLETE][2] ([i915#198])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-bxt-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#889])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-bxt-dsi/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-bxt-dsi/igt@i915_module_l...@reload-with-fault-injection.html
- fi-kbl-x1275:   [PASS][5] -> [INCOMPLETE][6] ([i915#879])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-kbl-x1275/igt@i915_module_l...@reload-with-fault-injection.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-kbl-x1275/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-hsw-4770:[PASS][7] -> [INCOMPLETE][8] ([i915#151])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-hsw-4770/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-hsw-4770/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770r:   [PASS][9] -> [DMESG-FAIL][10] ([i915#563])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-hsw-4770r/igt@i915_selftest@live_blt.html
- fi-hsw-peppy:   [PASS][11] -> [DMESG-FAIL][12] ([i915#553] / 
[i915#725])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [FAIL][13] ([i915#178]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [DMESG-FAIL][15] ([i915#656]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_gem_contexts:
- fi-hsw-peppy:   [DMESG-FAIL][17] ([i915#722]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7715/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16048/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html

  
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
  [i915#563]: https://gitlab.freedesktop.org/drm/intel/issues/563
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#879]: https://gitlab.freedesktop.org/drm/intel/issues/879
  [i915#889]: https://gitlab.freedesktop.org/drm/intel/issues/889


Participating hosts (44 -> 39)
--

  Additional (8): fi-byt-j1900 fi-glk-dsi fi-kbl-guc fi-kbl-8809g fi-elk-e7500 
fi-kbl-7560u fi-tgl-y fi-bsw-nick 
  Missing(13): fi-ehl-1 fi-bdw-5557u fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-snb-2520m fi-kbl-7500u fi-ctg-p8600 fi-whl-u fi-skl-lmem 
fi-byt-n2820 fi-byt-clapper fi-kbl-r 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7715 -> Patchwork_16048

  CI-20190529: 20190529
  CI_DRM_7715: 337449c74a6745cf1d9d60c41f170d31a291f0c0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5359: 28451bcec2245dcc1fd0eb1d4c76335b2b4f97a5 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16048: 

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Do not use colon characters in PMU names

2020-01-10 Thread Tvrtko Ursulin



On 10/01/2020 11:21, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-01-10 11:11:26)

From: Tvrtko Ursulin 

We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs. But since tools/perf reserves a special meaning to
the colon character we need to transliterate them to something else. We
choose a dash.

Signed-off-by: Tvrtko Ursulin 
Reported-by: Dmitry Rogozhkin 
Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Andi Kleen 
---
  drivers/gpu/drm/i915/i915_pmu.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f3ef6700a5f2..ecbd0e1f1a90 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -1117,12 +1117,22 @@ void i915_pmu_register(struct drm_i915_private *i915)
 hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 pmu->timer.function = i915_sample;
  
-   if (!is_igp(i915))

+   if (!is_igp(i915)) {
 pmu->name = kasprintf(GFP_KERNEL,
   "i915-%s",
   dev_name(i915->drm.dev));
-   else
+   if (pmu->name) {


/* tools/perf reserves colons as special. */
strreplace(pmu->name, ':', '-');


I didn't know this exists, thanks.


I worry because the err_idx pointed to the '-'. We may have to use _


What is err_idx? But yes.. it would had served me well to test before 
sending. :) I just find identifiers with a mix of underscores and dashes 
so visually unappealing. :(


Regards,

Tvrtko

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


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

2020-01-10 Thread Maarten Lankhorst
drm-misc-next-2020-01-10:
drm-misc-next for v5.6:

UAPI Changes:

Cross-subsystem Changes:
- Convert simple panel bindings to a template.

Core Changes:
- Revert drm-bridge-state changes, it causes a dependency error
  between drm and drm_kms_helper.
- Fix when disabling crc's.
- Assorted Kconfig fixes.

Driver Changes:
- Add ddc symlinks to more drivers.
- Fix chained bridge handling in exynos and vc4.
- More clock rate fixes in sun4i.
- Add support for AUO B116XAK01, GiantPlus GPM940B0, Sony ACX424AKP,
  BOE NV140FHM-N49, Satoz SAT050AT40H12R2 and Sharp LS020B1DD01D panels.
- Assorted small bugfixes.
The following changes since commit 3cacb2086e41bbdf4a43e494d47d05db356992b9:

  drm/mgag200: Add module parameter to pin all buffers at offset 0 (2020-01-07 
11:53:19 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-01-10

for you to fetch changes up to 44c58c520ffc4b1f75241e5029c5ae6b223d0623:

  drm/panel: simple: Add Satoz SAT050AT40H12R2 panel support (2020-01-09 
20:27:06 +0100)


drm-misc-next for v5.6:

UAPI Changes:

Cross-subsystem Changes:
- Convert simple panel bindings to a template.

Core Changes:
- Revert drm-bridge-state changes, it causes a dependency error
  between drm and drm_kms_helper.
- Fix when disabling crc's.
- Assorted Kconfig fixes.

Driver Changes:
- Add ddc symlinks to more drivers.
- Fix chained bridge handling in exynos and vc4.
- More clock rate fixes in sun4i.
- Add support for AUO B116XAK01, GiantPlus GPM940B0, Sony ACX424AKP,
  BOE NV140FHM-N49, Satoz SAT050AT40H12R2 and Sharp LS020B1DD01D panels.
- Assorted small bugfixes.


Andrzej Pietrasiewicz (4):
  drm/tegra: Provide ddc symlink in output connector sysfs directory
  drm/vc4: Provide ddc symlink in connector sysfs directory
  drm: zte: Provide ddc symlink in hdmi connector sysfs directory
  drm: zte: Provide ddc symlink in vga connector sysfs directory

Arnd Bergmann (1):
  drm: meson: fix address type confusion

Benjamin Gaignard (2):
  drm/modes: tag unused variables to avoid warnings
  drm/fb-cma-helpers: Fix include issue

Boris Brezillon (8):
  drm/bridge: Fix a NULL pointer dereference in 
drm_atomic_bridge_chain_check()
  Revert "drm/bridge: Fix a NULL pointer dereference in 
drm_atomic_bridge_chain_check()"
  Revert "drm/bridge: Add the necessary bits to support bus format 
negotiation"
  Revert "drm/bridge: Add an ->atomic_check() hook"
  Revert "drm/bridge: Patch atomic hooks to take a drm_bridge_state"
  Revert "drm/bridge: Add a drm_bridge_state object"
  drm/vc4: dsi: Fix bridge chain handling
  drm/exynos: dsi: Fix bridge chain handling

Chen Zhou (1):
  drm/gma500: remove set but not used variables 'hist_reg'

Dan Carpenter (1):
  gpu/drm: clean up white space in drm_legacy_lock_master_cleanup()

Dingchen Zhang (2):
  drm: remove the newline for CRC source name.
  drm: Set crc->opened to false before setting crc source to NULL.

Hans Verkuil (1):
  drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CEC

Linus Walleij (1):
  drm/panel: Add driver for Sony ACX424AKP panel

Maxime Ripard (3):
  drm/sun4i: backend: Make sure we enforce the clock rate
  drm/sun4i: drc: Make sure we enforce the clock rate
  dt-bindings: display: Convert Allwinner display pipeline to schemas

Miquel Raynal (3):
  dt-bindings: Add vendor prefix for Satoz
  dt-bindings: display: simple: Add Satoz panel
  drm/panel: simple: Add Satoz SAT050AT40H12R2 panel support

Paul Cercueil (2):
  dt-bindings: panel-simple: Add compatible for GiantPlus GPM940B0
  dt-bindings: panel-simple: Add compatible for Sharp LS020B1DD01D

Qiang Yu (1):
  drm/lima: use drm_sched_fault for error task handling

Rob Clark (2):
  dt-bindings: display: panel: Add AUO B116XAK01 panel bindings
  drm/panel: Add support for AUO B116XAK01 panel

Sam Ravnborg (2):
  dt-bindings: one binding file for all simple panels
  dt-bindings: display: add BOE 14" panel

Thomas Zimmermann (1):
  drm/udl: Make udl driver depend on CONFIG_USB

Tobias Schramm (1):
  drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple

Wambui Karuga (1):
  drm/omapdrm: use BUG_ON macro for error debugging.

kbuild test robot (1):
  video: fbdev: mmp: fix platform_get_irq.cocci warnings

 .../allwinner,sun4i-a10-display-backend.yaml   | 291 +
 .../allwinner,sun4i-a10-display-engine.yaml| 114 
 .../allwinner,sun4i-a10-display-frontend.yaml  | 138 +
 .../bindings/display/allwinner,sun4i-a10-hdmi.yaml | 183 ++
 .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 676 +
 .../display/allwinner,sun4i-a10-tv-encoder.yaml|  62 ++
 .../bindings/display/allwinner,sun6i-a31-drc.yaml  | 138 

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Do not use colon characters in PMU names

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 11:27:55)
> 
> On 10/01/2020 11:21, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-01-10 11:11:26)
> >> From: Tvrtko Ursulin 
> >>
> >> We use PCI device path in the registered PMU name in order to distinguish
> >> between multiple GPUs. But since tools/perf reserves a special meaning to
> >> the colon character we need to transliterate them to something else. We
> >> choose a dash.
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> >> Reported-by: Dmitry Rogozhkin 
> >> Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
> >> Cc: Chris Wilson 
> >> Cc: Michal Wajdeczko 
> >> Cc: Andi Kleen 
> >> ---
> >>   drivers/gpu/drm/i915/i915_pmu.c | 14 --
> >>   1 file changed, 12 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> >> b/drivers/gpu/drm/i915/i915_pmu.c
> >> index f3ef6700a5f2..ecbd0e1f1a90 100644
> >> --- a/drivers/gpu/drm/i915/i915_pmu.c
> >> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> >> @@ -1117,12 +1117,22 @@ void i915_pmu_register(struct drm_i915_private 
> >> *i915)
> >>  hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> >>  pmu->timer.function = i915_sample;
> >>   
> >> -   if (!is_igp(i915))
> >> +   if (!is_igp(i915)) {
> >>  pmu->name = kasprintf(GFP_KERNEL,
> >>"i915-%s",
> >>dev_name(i915->drm.dev));
> >> -   else
> >> +   if (pmu->name) {
> > 
> > /* tools/perf reserves colons as special. */
> > strreplace(pmu->name, ':', '-');
> 
> I didn't know this exists, thanks.
> 
> > I worry because the err_idx pointed to the '-'. We may have to use _
> 
> What is err_idx? But yes.. it would had served me well to test before 
> sending. :) I just find identifiers with a mix of underscores and dashes 
> so visually unappealing. :(

event syntax error: 'i915-:00:02.0/bcs0-busy/'
 \___ parser error

The parser sets err_idx on the character it failed at, and the error
message includes it. So unless we lost whitespace in all the cutting and
pasting, that says it barfed at '-'
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] drm/i915/pmu: Do not use colons or dashes in PMU names

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs. But since tools/perf reserves a special meaning to
dash and colon characters we need to transliterate them to something else.
We choose an underscore.

v2:
 * Use strreplace. (Chris)
 * Dashes are not good either. (Chris)

Signed-off-by: Tvrtko Ursulin 
Reported-by: Dmitry Rogozhkin 
Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Andi Kleen 
---
 drivers/gpu/drm/i915/i915_pmu.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f3ef6700a5f2..28a82c849bac 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -1117,12 +1117,17 @@ void i915_pmu_register(struct drm_i915_private *i915)
hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
pmu->timer.function = i915_sample;
 
-   if (!is_igp(i915))
+   if (!is_igp(i915)) {
pmu->name = kasprintf(GFP_KERNEL,
- "i915-%s",
+ "i915_%s",
  dev_name(i915->drm.dev));
-   else
+   if (pmu->name) {
+   /* tools/perf reserves colons as special. */
+   strreplace((char *)pmu->name, ':', '_');
+   }
+   } else {
pmu->name = "i915";
+   }
if (!pmu->name)
goto err;
 
-- 
2.20.1

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


[Intel-gfx] [PATCH i-g-t v3] i915/perf: Find the associated perf-type for a particular device

2020-01-10 Thread Chris Wilson
Since with multiple devices, we may have multiple different perf_pmu
each with their own type, we want to find the right one for the job.

The tests are run with a specific fd, from which we can extract the
appropriate bus-id and find the associated perf-type. The performance
monitoring tools are a little more general and not yet ready to probe
all device or bind to one in particular, so we just assume the default
igfx for the time being.

v2: Extract the bus address from out of sysfs
v3: A new name for a new decade!

Signed-off-by: Chris Wilson 
Cc: "Robert M. Fosha" 
Cc: Tvrtko Ursulin 
Cc: Michal Wajdeczko 
Reviewed-by: "Robert M. Fosha"  #v2
---
 benchmarks/gem_wsim.c  |  4 +-
 lib/igt_perf.c | 91 +++---
 lib/igt_perf.h | 13 +++--
 overlay/gem-interrupts.c   |  2 +-
 overlay/gpu-freq.c |  4 +-
 overlay/gpu-top.c  | 12 ++---
 overlay/rc6.c  |  2 +-
 tests/i915/gem_ctx_freq.c  |  2 +-
 tests/i915/gem_ctx_sseu.c  |  2 +-
 tests/i915/gem_exec_balancer.c | 18 ---
 tests/perf_pmu.c   | 84 ---
 tools/intel_gpu_top.c  |  2 +-
 12 files changed, 166 insertions(+), 70 deletions(-)

diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 6305e0d7a..9156fdc90 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -2268,8 +2268,8 @@ busy_init(const struct workload_balancer *balancer, 
struct workload *wrk)
for (d = [0]; d->id != VCS; d++) {
int pfd;
 
-   pfd = perf_i915_open_group(I915_PMU_ENGINE_BUSY(d->class,
-   d->inst),
+   pfd = perf_igfx_open_group(I915_PMU_ENGINE_BUSY(d->class,
+   d->inst),
   bb->fd);
if (pfd < 0) {
if (d->id != VCS2)
diff --git a/lib/igt_perf.c b/lib/igt_perf.c
index e3dec2cc2..418c1c188 100644
--- a/lib/igt_perf.c
+++ b/lib/igt_perf.c
@@ -4,17 +4,84 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "igt_perf.h"
 
-uint64_t i915_type_id(void)
+static char *bus_address(int i915, char *path, int pathlen)
+{
+   struct stat st;
+   int len = -1;
+   int dir;
+   char *s;
+
+   if (fstat(i915, ) || !S_ISCHR(st.st_mode))
+   return NULL;
+
+   snprintf(path, pathlen, "/sys/dev/char/%d:%d",
+major(st.st_rdev), minor(st.st_rdev));
+
+   dir = open(path, O_RDONLY);
+   if (dir != -1) {
+   len = readlinkat(dir, "device", path, pathlen - 1);
+   close(dir);
+   }
+   if (len < 0)
+   return NULL;
+
+   path[len] = '\0';
+
+   /* strip off the relative path */
+   s = strrchr(path, '/');
+   if (s)
+   memmove(path, s + 1, len - (s - path) + 1);
+
+   return path;
+}
+
+const char *i915_perf_device(int i915, char *buf, int buflen)
+{
+   char *s;
+
+#define prefix "i915_"
+#define plen strlen(prefix)
+
+   if (!buf || buflen < plen)
+   return "i915";
+
+   memcpy(buf, prefix, plen);
+
+   if (!bus_address(i915, buf + plen, buflen - plen) ||
+   strcmp(buf + plen, ":00:02.0") == 0) /* legacy name for igfx */
+   buf[plen - 1] = '\0';
+
+   /* Convert all colons in the address to '_', thanks perf! */
+   for (s = buf; *s; s++)
+   if (*s == ':')
+   *s = '_';
+
+   return buf;
+}
+
+uint64_t i915_perf_type_id(int i915)
+{
+   char buf[80];
+
+   return igt_perf_type_id(i915_perf_device(i915, buf, sizeof(buf)));
+}
+
+uint64_t igt_perf_type_id(const char *device)
 {
char buf[64];
ssize_t ret;
int fd;
 
-   fd = open("/sys/bus/event_source/devices/i915/type", O_RDONLY);
+   snprintf(buf, sizeof(buf),
+"/sys/bus/event_source/devices/%s/type", device);
+
+   fd = open(buf, O_RDONLY);
if (fd < 0)
return 0;
 
@@ -52,15 +119,27 @@ _perf_open(uint64_t type, uint64_t config, int group, 
uint64_t format)
return ret;
 }
 
-int perf_i915_open(uint64_t config)
+int perf_igfx_open(uint64_t config)
+{
+   return _perf_open(igt_perf_type_id("i915"), config, -1,
+ PERF_FORMAT_TOTAL_TIME_ENABLED);
+}
+
+int perf_igfx_open_group(uint64_t config, int group)
+{
+   return _perf_open(igt_perf_type_id("i915"), config, group,
+ PERF_FORMAT_TOTAL_TIME_ENABLED | PERF_FORMAT_GROUP);
+}
+
+int perf_i915_open(int i915, uint64_t config)
 {
-   return _perf_open(i915_type_id(), config, -1,
+   return _perf_open(i915_perf_type_id(i915), config, -1,
  PERF_FORMAT_TOTAL_TIME_ENABLED);
 }
 
-int perf_i915_open_group(uint64_t config, int group)
+int 

[Intel-gfx] [PATCH 2/3] drm/i915/gt: Mark context->state vma as active while pinned

2020-01-10 Thread Chris Wilson
As we use the active state to keep the vma alive while we are reading
its contents during GPU error capture, we need to mark the
context->state vma as active during execution if we want to include it
in the error state.

Reported-by: Lionel Landwerlin 
Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Lionel Landwerlin 
Acked-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/gt/intel_context.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 9796a54b4f47..8774c18f405e 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -160,6 +160,10 @@ static int __context_pin_state(struct i915_vma *vma)
if (err)
return err;
 
+   err = i915_active_acquire(>active);
+   if (err)
+   goto err_unpin;
+
/*
 * And mark it as a globally pinned object to let the shrinker know
 * it cannot reclaim the object until we release it.
@@ -168,11 +172,16 @@ static int __context_pin_state(struct i915_vma *vma)
vma->obj->mm.dirty = true;
 
return 0;
+
+err_unpin:
+   i915_vma_unpin(vma);
+   return err;
 }
 
 static void __context_unpin_state(struct i915_vma *vma)
 {
i915_vma_make_shrinkable(vma);
+   i915_active_release(>active);
__i915_vma_unpin(vma);
 }
 
-- 
2.25.0.rc2

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


Re: [Intel-gfx] [PATCH 13/14] drm/i915: Drop request list from error state

2020-01-10 Thread Andi Shyti
Hi Chris,

On Thu, Jan 09, 2020 at 08:58:38AM +, Chris Wilson wrote:
> The list of requests from after the hang tells little about the hang
> itself, only how busy userspace was after the fact. As it pertains
> nothing to the HW state, drop it from the error state.
> 
> Signed-off-by: Chris Wilson 

Acked-by: Andi Shyti 

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


[Intel-gfx] [PATCH 1/3] drm/i915/gt: Skip trying to unbind in restore_ggtt_mappings

2020-01-10 Thread Chris Wilson
Currently we first to try to unbind the VMA (and lazily rebind on next
use) as an optimisation during restore_ggtt_mappings. Ideally, the only
objects in the GGTT upon resume are the pinned kernel objects which
can't be unbound and need to be restored. As the unbind interferes with
the plan to mark those objects as active for error capture, forgo the
optimisation.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 795cd267e28e..eb9365741ff8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1197,7 +1197,7 @@ void i915_ggtt_disable_guc(struct i915_ggtt *ggtt)
 
 static void ggtt_restore_mappings(struct i915_ggtt *ggtt)
 {
-   struct i915_vma *vma, *vn;
+   struct i915_vma *vma;
bool flush = false;
int open;
 
@@ -1212,15 +1212,12 @@ static void ggtt_restore_mappings(struct i915_ggtt 
*ggtt)
open = atomic_xchg(>vm.open, 0);
 
/* clflush objects bound into the GGTT and rebind them. */
-   list_for_each_entry_safe(vma, vn, >vm.bound_list, vm_link) {
+   list_for_each_entry(vma, >vm.bound_list, vm_link) {
struct drm_i915_gem_object *obj = vma->obj;
 
if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
continue;
 
-   if (!__i915_vma_unbind(vma))
-   continue;
-
clear_bit(I915_VMA_GLOBAL_BIND_BIT, __i915_vma_flags(vma));
WARN_ON(i915_vma_bind(vma,
  obj ? obj->cache_level : 0,
-- 
2.25.0.rc2

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


[Intel-gfx] [PATCH 3/3] drm/i915/gt: Mark ring->vma as active while pinned

2020-01-10 Thread Chris Wilson
As we use the active state to keep the vma alive while we are reading
its contents during GPU error capture, we need to mark the
ring->vma as active during execution if we want to include the rinbuffer
in the error state.

Reported-by: Lionel Landwerlin 
Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Lionel Landwerlin 
Acked-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/gt/intel_context.c | 31 ++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 8774c18f405e..23137b2a8689 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -185,6 +185,31 @@ static void __context_unpin_state(struct i915_vma *vma)
__i915_vma_unpin(vma);
 }
 
+static int __ring_active(struct intel_ring *ring)
+{
+   int err;
+
+   err = i915_active_acquire(>vma->active);
+   if (err)
+   return err;
+
+   err = intel_ring_pin(ring);
+   if (err)
+   goto err_active;
+
+   return 0;
+
+err_active:
+   i915_active_release(>vma->active);
+   return err;
+}
+
+static void __ring_retire(struct intel_ring *ring)
+{
+   intel_ring_unpin(ring);
+   i915_active_release(>vma->active);
+}
+
 __i915_active_call
 static void __intel_context_retire(struct i915_active *active)
 {
@@ -197,7 +222,7 @@ static void __intel_context_retire(struct i915_active 
*active)
__context_unpin_state(ce->state);
 
intel_timeline_unpin(ce->timeline);
-   intel_ring_unpin(ce->ring);
+   __ring_retire(ce->ring);
 
intel_context_put(ce);
 }
@@ -211,7 +236,7 @@ static int __intel_context_active(struct i915_active 
*active)
 
intel_context_get(ce);
 
-   err = intel_ring_pin(ce->ring);
+   err = __ring_active(ce->ring);
if (err)
goto err_put;
 
@@ -231,7 +256,7 @@ static int __intel_context_active(struct i915_active 
*active)
 err_timeline:
intel_timeline_unpin(ce->timeline);
 err_ring:
-   intel_ring_unpin(ce->ring);
+   __ring_retire(ce->ring);
 err_put:
intel_context_put(ce);
return err;
-- 
2.25.0.rc2

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


[Intel-gfx] [PATCH] drm/i915/pmu: Do not use colon characters in PMU names

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs. But since tools/perf reserves a special meaning to
the colon character we need to transliterate them to something else. We
choose a dash.

Signed-off-by: Tvrtko Ursulin 
Reported-by: Dmitry Rogozhkin 
Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Andi Kleen 
---
 drivers/gpu/drm/i915/i915_pmu.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f3ef6700a5f2..ecbd0e1f1a90 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -1117,12 +1117,22 @@ void i915_pmu_register(struct drm_i915_private *i915)
hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
pmu->timer.function = i915_sample;
 
-   if (!is_igp(i915))
+   if (!is_igp(i915)) {
pmu->name = kasprintf(GFP_KERNEL,
  "i915-%s",
  dev_name(i915->drm.dev));
-   else
+   if (pmu->name) {
+   char *p;
+
+   /* tools/perf reserves colons as special. */
+   for (p = (char *)pmu->name; *p; p++) {
+   if (*p == ':')
+   *p = '-';
+   }
+   }
+   } else {
pmu->name = "i915";
+   }
if (!pmu->name)
goto err;
 
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH] drm/i915/pmu: Do not use colon characters in PMU names

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 11:11:26)
> From: Tvrtko Ursulin 
> 
> We use PCI device path in the registered PMU name in order to distinguish
> between multiple GPUs. But since tools/perf reserves a special meaning to
> the colon character we need to transliterate them to something else. We
> choose a dash.
> 
> Signed-off-by: Tvrtko Ursulin 
> Reported-by: Dmitry Rogozhkin 
> Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
> Cc: Chris Wilson 
> Cc: Michal Wajdeczko 
> Cc: Andi Kleen 
> ---
>  drivers/gpu/drm/i915/i915_pmu.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index f3ef6700a5f2..ecbd0e1f1a90 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -1117,12 +1117,22 @@ void i915_pmu_register(struct drm_i915_private *i915)
> hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> pmu->timer.function = i915_sample;
>  
> -   if (!is_igp(i915))
> +   if (!is_igp(i915)) {
> pmu->name = kasprintf(GFP_KERNEL,
>   "i915-%s",
>   dev_name(i915->drm.dev));
> -   else
> +   if (pmu->name) {

/* tools/perf reserves colons as special. */
strreplace(pmu->name, ':', '-');

I worry because the err_idx pointed to the '-'. We may have to use _
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 1/2] drm/connector: Split out orientation quirk detection (v2)

2020-01-10 Thread Jani Nikula
On Sun, 05 Jan 2020, Hans de Goede  wrote:
> From: Derek Basehore 
>
> Not every platform needs quirk detection for panel orientation, so
> split the drm_connector_init_panel_orientation_property into two
> functions. One for platforms without the need for quirks, and the
> other for platforms that need quirks.
>
> Hans de Goede (changes in v2):
>
> Rename the function from drm_connector_init_panel_orientation_property
> to drm_connector_set_panel_orientation[_with_quirk] and pass in the
> panel-orientation to set.
>
> Beside the rename, also make the function set the passed in value
> only once, if the value was set before (to a value other then
> DRM_MODE_PANEL_ORIENTATION_UNKNOWN) make any further set calls a no-op.
>
> This change is preparation for allowing the user to override the
> panel-orientation for any connector from the kernel commandline.
> When the panel-orientation is overridden this way, then we must ignore
> the panel-orientation detection done by the driver.

Acked-by: Jani Nikula 

for merging via drm-misc.

---

Side note, I'm a bit concerned about the gradual accumulation of ad hoc
ways to set various connector properties on the kernel
command-line... without actually making it a generic way to set any
arbitrary connector properties on the kernel command-line.

BR,
Jani.



>
> Reviewed-by: Rodrigo Vivi 
> Signed-off-by: Derek Basehore 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/drm_connector.c | 74 ++---
>  drivers/gpu/drm/i915/display/icl_dsi.c  |  5 +-
>  drivers/gpu/drm/i915/display/intel_dp.c |  9 ++-
>  drivers/gpu/drm/i915/display/vlv_dsi.c  |  5 +-
>  include/drm/drm_connector.h |  9 ++-
>  5 files changed, 71 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2166000ed057..de5031c4aa49 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1139,7 +1139,8 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
> = {
>   *   coordinates, so if userspace rotates the picture to adjust for
>   *   the orientation it must also apply the same transformation to the
>   *   touchscreen input coordinates. This property is initialized by calling
> - *   drm_connector_init_panel_orientation_property().
> + *   drm_connector_set_panel_orientation() or
> + *   drm_connector_set_panel_orientation_with_quirk()
>   *
>   * scaling mode:
>   *   This property defines how a non-native mode is upscaled to the native
> @@ -2046,38 +2047,41 @@ void drm_connector_set_vrr_capable_property(
>  EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>  
>  /**
> - * drm_connector_init_panel_orientation_property -
> - *   initialize the connecters panel_orientation property
> - * @connector: connector for which to init the panel-orientation property.
> - * @width: width in pixels of the panel, used for panel quirk detection
> - * @height: height in pixels of the panel, used for panel quirk detection
> + * drm_connector_set_panel_orientation - sets the connecter's 
> panel_orientation
> + * @connector: connector for which to set the panel-orientation property.
> + * @panel_orientation: drm_panel_orientation value to set
> + *
> + * This function sets the connector's panel_orientation and attaches
> + * a "panel orientation" property to the connector.
>   *
> - * This function should only be called for built-in panels, after setting
> - * connector->display_info.panel_orientation first (if known).
> + * Calling this function on a connector where the panel_orientation has
> + * already been set is a no-op (e.g. the orientation has been overridden with
> + * a kernel commandline option).
>   *
> - * This function will check for platform specific (e.g. DMI based) quirks
> - * overriding display_info.panel_orientation first, then if panel_orientation
> - * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
> - * "panel orientation" property to the connector.
> + * It is allowed to call this function with a panel_orientation of
> + * DRM_MODE_PANEL_ORIENTATION_UNKNOWN, in which case it is a no-op.
>   *
>   * Returns:
>   * Zero on success, negative errno on failure.
>   */
> -int drm_connector_init_panel_orientation_property(
> - struct drm_connector *connector, int width, int height)
> +int drm_connector_set_panel_orientation(
> + struct drm_connector *connector,
> + enum drm_panel_orientation panel_orientation)
>  {
>   struct drm_device *dev = connector->dev;
>   struct drm_display_info *info = >display_info;
>   struct drm_property *prop;
> - int orientation_quirk;
>  
> - orientation_quirk = drm_get_panel_orientation_quirk(width, height);
> - if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> - info->panel_orientation = orientation_quirk;
> + /* Already set? */
> + if (info->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> + return 0;
>  
> 

Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Do not use colons or dashes in PMU names

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 11:32:53)
> From: Tvrtko Ursulin 
> 
> We use PCI device path in the registered PMU name in order to distinguish
> between multiple GPUs. But since tools/perf reserves a special meaning to
> dash and colon characters we need to transliterate them to something else.
> We choose an underscore.
> 
> v2:
>  * Use strreplace. (Chris)
>  * Dashes are not good either. (Chris)
> 
> Signed-off-by: Tvrtko Ursulin 
> Reported-by: Dmitry Rogozhkin 
> Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
> Cc: Chris Wilson 
> Cc: Michal Wajdeczko 
> Cc: Andi Kleen 
> ---
>  drivers/gpu/drm/i915/i915_pmu.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index f3ef6700a5f2..28a82c849bac 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -1117,12 +1117,17 @@ void i915_pmu_register(struct drm_i915_private *i915)
> hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> pmu->timer.function = i915_sample;
>  
> -   if (!is_igp(i915))
> +   if (!is_igp(i915)) {
> pmu->name = kasprintf(GFP_KERNEL,
> - "i915-%s",
> + "i915_%s",
>   dev_name(i915->drm.dev));
> -   else
> +   if (pmu->name) {
> +   /* tools/perf reserves colons as special. */
> +   strreplace((char *)pmu->name, ':', '_');
> +   }
> +   } else {
> pmu->name = "i915";
> +   }
> if (!pmu->name)
> goto err;

Sadly I have no nicer suggestion, so
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC 1/8] drm/i915: Expose list of clients in sysfs

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Expose a list of clients with open file handles in sysfs.

This will be a basis for a top-like utility showing per-client and per-
engine GPU load.

Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.

For instance:

/sys/class/drm/card0/clients/3/name: Xorg
/sys/class/drm/card0/clients/3/pid: 5664

v2:
 Chris Wilson:
 * Enclose new members into dedicated structs.
 * Protect against failed sysfs registration.

v3:
 * sysfs_attr_init.

v4:
 * Fix for internal clients.

v5:
 * Use cyclic ida for client id. (Chris)
 * Do not leak pid reference. (Chris)
 * Tidy code with some locals.

v6:
 * Use xa_alloc_cyclic to simplify locking. (Chris)
 * No need to unregister individial sysfs files. (Chris)
 * Rebase on top of fpriv kref.
 * Track client closed status and reflect in sysfs.

v7:
 * Make drm_client more standalone concept.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drm_client.c | 150 +
 drivers/gpu/drm/i915/i915_drm_client.h |  61 ++
 drivers/gpu/drm/i915/i915_drv.h|   5 +
 drivers/gpu/drm/i915/i915_gem.c|  35 --
 drivers/gpu/drm/i915/i915_sysfs.c  |   8 ++
 6 files changed, 254 insertions(+), 8 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
 create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b8c5f8934dbd..3a677a20a709 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -36,7 +36,8 @@ subdir-ccflags-y += -I$(srctree)/$(src)
 # Please keep these build lists sorted!
 
 # core driver code
-i915-y += i915_drv.o \
+i915-y += i915_drm_client.o \
+ i915_drv.o \
  i915_irq.o \
  i915_getparam.o \
  i915_params.o \
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
new file mode 100644
index ..02356f48d85b
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -0,0 +1,150 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "i915_drm_client.h"
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+static ssize_t
+show_client_name(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   struct i915_drm_client *client =
+   container_of(attr, typeof(*client), attr.name);
+
+   return snprintf(buf, PAGE_SIZE, "%s%s%s",
+   client->closed ? "<" : "",
+   client->name,
+   client->closed ? ">" : "");
+}
+
+static ssize_t
+show_client_pid(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   struct i915_drm_client *client =
+   container_of(attr, typeof(*client), attr.pid);
+
+   return snprintf(buf, PAGE_SIZE, "%s%u%s",
+   client->closed ? "<" : "",
+   pid_nr(client->pid),
+   client->closed ? ">" : "");
+}
+
+static int
+__i915_drm_client_register(struct i915_drm_client *client,
+  struct task_struct *task)
+{
+   struct i915_drm_clients *clients = client->clients;
+   struct device_attribute *attr;
+   int ret = -ENOMEM;
+   char idstr[32];
+
+   if (!clients->root)
+   return 0; /* intel_fbdev_init registers a client before sysfs */
+
+   client->name = kstrdup(task->comm, GFP_KERNEL);
+   if (!client->name)
+   goto err_name;
+
+   snprintf(idstr, sizeof(idstr), "%u", client->id);
+   client->root = kobject_create_and_add(idstr, clients->root);
+   if (!client->root)
+   goto err_client;
+
+   attr = >attr.name;
+   sysfs_attr_init(>attr);
+   attr->attr.name = "name";
+   attr->attr.mode = 0444;
+   attr->show = show_client_name;
+
+   ret = sysfs_create_file(client->root, (struct attribute *)attr);
+   if (ret)
+   goto err_attr;
+
+   attr = >attr.pid;
+   sysfs_attr_init(>attr);
+   attr->attr.name = "pid";
+   attr->attr.mode = 0444;
+   attr->show = show_client_pid;
+
+   ret = sysfs_create_file(client->root, (struct attribute *)attr);
+   if (ret)
+   goto err_attr;
+
+   client->pid = get_task_pid(task, PIDTYPE_PID);
+
+   return 0;
+
+err_attr:
+   kobject_put(client->root);
+err_client:
+   kfree(client->name);
+err_name:
+   return ret;
+}
+
+static void __i915_drm_client_unregister(struct i915_drm_client *client)
+{
+   if (!client->name)
+   return; /* fbdev client or error during drm open */
+
+   kobject_put(fetch_and_zero(>root));
+   put_pid(fetch_and_zero(>pid));
+   kfree(fetch_and_zero(>name));
+}
+
+struct i915_drm_client *
+i915_drm_client_add(struct 

[Intel-gfx] [RFC 8/8] drm/i915: Fallback to hw context runtime when sw tracking is not available

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

In GuC mode we are not receiving the context switch interrupts to be able
to accurately track context runtimes.

We can fallback to using PPHWSP counter updated by the GPU on context save.

QQQ
Downsides are: 1) we do not see currently executing batch and 2) with a
12MHz command streamer timestamp timer frequency the 32-bit counter wraps
every ~358 seconds. This makes endless OpenCL batches with hearbeats
turned off also a problem.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drm_client.c | 34 --
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index 55b2f86cc4c1..0b84ae528dcc 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -58,6 +58,24 @@ sw_busy_add(struct i915_gem_context *ctx, unsigned int 
engine_class)
return total;
 }
 
+static u64
+hw_busy_add(struct i915_gem_context *ctx, unsigned int engine_class)
+{
+   struct i915_gem_engines *engines = rcu_dereference(ctx->engines);
+   struct i915_gem_engines_iter it;
+   struct intel_context *ce;
+   u64 total = 0;
+
+   for_each_gem_engine(ce, engines, it) {
+   if (ce->engine->uabi_class != engine_class)
+   continue;
+
+   total += intel_context_get_hw_runtime_ns(ce);
+   }
+
+   return total;
+}
+
 static ssize_t
 show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
 {
@@ -68,12 +86,14 @@ show_client_busy(struct device *kdev, struct 
device_attribute *attr, char *buf)
struct i915_gem_context *ctx;
u64 total = 0;
 
-   if (i915_attr->no_busy_stats)
-   return -ENODEV;
-
rcu_read_lock();
-   list_for_each_entry_rcu(ctx, list, client_link)
-   total += sw_busy_add(ctx, engine_class);
+   if (i915_attr->no_busy_stats) {
+   list_for_each_entry_rcu(ctx, list, client_link)
+   total += hw_busy_add(ctx, engine_class);
+   } else {
+   list_for_each_entry_rcu(ctx, list, client_link)
+   total += sw_busy_add(ctx, engine_class);
+   }
rcu_read_unlock();
 
return snprintf(buf, PAGE_SIZE, "%llu\n", total);
@@ -164,7 +184,7 @@ __i915_drm_client_register(struct i915_drm_client *client,
if (ret) {
int j, k;
 
-   /* Unwind if not available. */
+   /* Unwind and fallback if not available. */
j = 0;
for_each_uabi_engine(engine, i915) {
if (j++ == i)
@@ -181,7 +201,7 @@ __i915_drm_client_register(struct i915_drm_client *client,
}
 
dev_notice_once(i915->drm.dev,
-   "Engine busy stats not 
available! (%d)",
+   "Reduced accuracy context 
runtime mode (%d)",
ret);
break;
}
-- 
2.20.1

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


[Intel-gfx] [RFC 0/8] Per client engine busyness

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Another re-spin of the per-client engine busyness series. Highlights from this
version:

 * Two patches added on top of the series to provide the data in GuC mode.
   (For warnings and limitations please read the respective commit messages.)
 * Refactor to introduce a notion of i915_drm_client and move to separate source
   file.

Internally we track time spent on engines for each struct intel_context. This
can serve as a building block for several features from the want list:
smarter scheduler decisions, getrusage(2)-like per-GEM-context functionality
wanted by some customers, cgroups controller, dynamic SSEU tuning,...

Externally, in sysfs, we expose time spent on GPU per client and per engine
class.

Sysfs interface enables us to implement a "top-like" tool for GPU tasks. Or with
a "screenshot":

intel-gpu-top -  906/ 955 MHz;0% RC6;  5.30 Watts;  933 irqs/s

  IMC reads: 4414 MiB/s
 IMC writes: 3805 MiB/s

  ENGINE  BUSY  MI_SEMA MI_WAIT
 Render/3D/0   93.46% |▋  |  0%  0%
   Blitter/00.00% |   |  0%  0%
 Video/00.00% |   |  0%  0%
  VideoEnhance/00.00% |   |  0%  0%

  PIDNAME  Render/3D  BlitterVideo  VideoEnhance
 2733   neverball |██▌ |||||||
 2047Xorg |███▊|||||||
 2737glxgears |█▍  |||||||
 2128   xfwm4 ||||||||
 2047Xorg ||||||||


Implementation wise we add a a bunch of files in sysfs like:

# cd /sys/class/drm/card0/clients/
# tree
.
├── 7
│   ├── busy
│   │   ├── 0
│   │   ├── 1
│   │   ├── 2
│   │   └── 3
│   ├── name
│   └── pid
├── 8
│   ├── busy
│   │   ├── 0
│   │   ├── 1
│   │   ├── 2
│   │   └── 3
│   ├── name
│   └── pid
└── 9
├── busy
│   ├── 0
│   ├── 1
│   ├── 2
│   └── 3
├── name
└── pid


Files in 'busy' directories are numbered using the engine class ABI values and
they contain accumulated nanoseconds each client spent on engines of a
respective class.

Tvrtko Ursulin (8):
  drm/i915: Expose list of clients in sysfs
  drm/i915: Update client name on context create
  drm/i915: Track per-context engine busyness
  drm/i915: Track all user contexts per client
  drm/i915: Contexts can use struct pid stored in the client
  drm/i915: Expose per-engine client busyness
  drm/i915: Track hw reported context runtime
  drm/i915: Fallback to hw context runtime when sw tracking is not
available

 drivers/gpu/drm/i915/Makefile |   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  60 +++-
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  16 +-
 drivers/gpu/drm/i915/gt/intel_context.c   |  20 ++
 drivers/gpu/drm/i915/gt/intel_context.h   |  18 ++
 drivers/gpu/drm/i915/gt/intel_context_types.h |  14 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  16 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  55 +++-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drm_client.c| 298 ++
 drivers/gpu/drm/i915/i915_drm_client.h|  83 +
 drivers/gpu/drm/i915/i915_drv.h   |   5 +
 drivers/gpu/drm/i915/i915_gem.c   |  35 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |   8 +-
 drivers/gpu/drm/i915/i915_sysfs.c |   8 +
 drivers/gpu/drm/i915/intel_device_info.c  |   2 +
 drivers/gpu/drm/i915/intel_device_info.h  |   1 +
 17 files changed, 606 insertions(+), 43 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
 create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h

-- 
2.20.1

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


Re: [Intel-gfx] [RFC 1/8] drm/i915: Expose list of clients in sysfs

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 13:30:42)
> +static ssize_t
> +show_client_name(struct device *kdev, struct device_attribute *attr, char 
> *buf)
> +{
> +   struct i915_drm_client *client =
> +   container_of(attr, typeof(*client), attr.name);
> +
> +   return snprintf(buf, PAGE_SIZE, "%s%s%s",
> +   client->closed ? "<" : "",
> +   client->name,
> +   client->closed ? ">" : "");

client->closed ? "<%s>" : "%s", unspeakably evil?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()

2020-01-10 Thread Jani Nikula
On Fri, 10 Jan 2020, Thomas Zimmermann  wrote:
> Hi
>
> Am 10.01.20 um 12:59 schrieb Jani Nikula:
>> On Fri, 10 Jan 2020, Thomas Zimmermann  wrote:
>>> The callback struct drm_driver.get_scanout_position() is deprecated in
>>> favor of struct drm_crtc_helper_funcs.get_scanout_position().
>>>
>>> i915 doesn't use CRTC helpers. The patch duplicates the caller
>>> drm_calc_vbltimestamp_from_scanoutpos() for i915, such that the callback
>>> function is not needed.
>>>
>>> Signed-off-by: Thomas Zimmermann 
>>> ---
>>>  drivers/gpu/drm/i915/i915_drv.c |   3 +-
>>>  drivers/gpu/drm/i915/i915_irq.c | 117 ++--
>>>  drivers/gpu/drm/i915/i915_irq.h |   9 +--
>>>  3 files changed, 119 insertions(+), 10 deletions(-)
>> 
>> Not really enthusiastic about the diffstat in a "cleanup" series.
>
> Well, the cleanup is about the content of drm_driver :)
>
>> 
>> I wonder if you could add a generic helper version of
>> drm_calc_vbltimestamp_from_scanoutpos where you pass the
>> get_scanout_position function as a parameter. Both
>> drm_calc_vbltimestamp_from_scanoutpos and the new
>> i915_calc_vbltimestamp_from_scanoutpos would then be fairly thin
>> wrappers passing in the relevant get_scanout_position function.
>
> Of course. Will be in v2 of the series.

Please give Ville (Cc'd) a moment before sending v2 in case he wants to
chime in on this.

Thanks,
Jani.


>
> Best regards
> Thomas
>
>> 
>> This would reduce the almost identical duplication of the function in
>> i915.
>> 
>> BR,
>> Jani.
>> 
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>>> b/drivers/gpu/drm/i915/i915_drv.c
>>> index f7385abdd74b..4a0a7fb85c53 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.c
>>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>>> @@ -2769,8 +2769,7 @@ static struct drm_driver driver = {
>>> .gem_prime_export = i915_gem_prime_export,
>>> .gem_prime_import = i915_gem_prime_import,
>>>  
>>> -   .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
>>> -   .get_scanout_position = i915_get_crtc_scanoutpos,
>>> +   .get_vblank_timestamp = i915_calc_vbltimestamp_from_scanoutpos,
>>>  
>>> .dumb_create = i915_gem_dumb_create,
>>> .dumb_map_offset = i915_gem_dumb_mmap_offset,
>>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>>> b/drivers/gpu/drm/i915/i915_irq.c
>>> index afc6aad9bf8c..99d0c3b0feae 100644
>>> --- a/drivers/gpu/drm/i915/i915_irq.c
>>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>>> @@ -52,6 +52,11 @@
>>>  #include "i915_trace.h"
>>>  #include "intel_pm.h"
>>>  
>>> +/* Retry timestamp calculation up to 3 times to satisfy
>>> + * drm_timestamp_precision before giving up.
>>> + */
>>> +#define I915_TIMESTAMP_MAXRETRIES 3
>>> +
>>>  /**
>>>   * DOC: interrupt handling
>>>   *
>>> @@ -762,10 +767,11 @@ static int __intel_get_crtc_scanline(struct 
>>> intel_crtc *crtc)
>>> return (position + crtc->scanline_offset) % vtotal;
>>>  }
>>>  
>>> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int index,
>>> - bool in_vblank_irq, int *vpos, int *hpos,
>>> - ktime_t *stime, ktime_t *etime,
>>> - const struct drm_display_mode *mode)
>>> +static bool i915_get_crtc_scanoutpos(struct drm_device *dev,
>>> +unsigned int index, bool in_vblank_irq,
>>> +int *vpos, int *hpos,
>>> +ktime_t *stime, ktime_t *etime,
>>> +const struct drm_display_mode *mode)
>>>  {
>>> struct drm_i915_private *dev_priv = to_i915(dev);
>>> struct intel_crtc *crtc = to_intel_crtc(drm_crtc_from_index(dev, 
>>> index));
>>> @@ -879,6 +885,109 @@ bool i915_get_crtc_scanoutpos(struct drm_device *dev, 
>>> unsigned int index,
>>> return true;
>>>  }
>>>  
>>> +bool i915_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
>>> +   unsigned int pipe,
>>> +   int *max_error,
>>> +   ktime_t *vblank_time,
>>> +   bool in_vblank_irq)
>>> +{
>>> +   struct timespec64 ts_etime, ts_vblank_time;
>>> +   ktime_t stime, etime;
>>> +   bool vbl_status;
>>> +   struct drm_crtc *crtc;
>>> +   const struct drm_display_mode *mode;
>>> +   struct drm_vblank_crtc *vblank = >vblank[pipe];
>>> +   int vpos, hpos, i;
>>> +   int delta_ns, duration_ns;
>>> +
>>> +   crtc = drm_crtc_from_index(dev, pipe);
>>> +
>>> +   if (pipe >= dev->num_crtcs || !crtc) {
>>> +   DRM_ERROR("Invalid crtc %u\n", pipe);
>>> +   return false;
>>> +   }
>>> +
>>> +   if (drm_drv_uses_atomic_modeset(dev))
>>> +   mode = >hwmode;
>>> +   else
>>> +   mode = >hwmode;
>>> +
>>> +   /* If mode timing undefined, just return as no-op:
>>> +* Happens during initial modesetting of a crtc.
>>> +*/
>>> +   if (mode->crtc_clock == 0) {
>>> +   DRM_DEBUG("crtc %u: Noop 

Re: [Intel-gfx] [RFC 7/8] drm/i915: Track hw reported context runtime

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 13:30:48)
> From: Tvrtko Ursulin 
> 
> GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP
> which will be useful for us in cases when we are not able to track context
> busyness ourselves (like with GuC). Keep a copy of this in struct
> intel_context from where it can be easily read even if the context is not
> pinned.
> 
> QQQ: Do we want to make this accounting conditional / able to turn on/off?
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/gt/intel_context.h   | 7 +++
>  drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +
>  drivers/gpu/drm/i915/gt/intel_lrc.c   | 9 +
>  drivers/gpu/drm/i915/intel_device_info.c  | 2 ++
>  drivers/gpu/drm/i915/intel_device_info.h  | 1 +
>  5 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index 30f0268fcc9a..389a05736fc7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -12,6 +12,7 @@
>  #include 
>  
>  #include "i915_active.h"
> +#include "i915_drv.h"
>  #include "intel_context_types.h"
>  #include "intel_engine_types.h"
>  #include "intel_ring_types.h"
> @@ -235,4 +236,10 @@ __intel_context_stats_start(struct intel_context_stats 
> *stats, ktime_t now)
>  
>  ktime_t intel_context_get_busy_time(struct intel_context *ce);
>  
> +static inline u64 intel_context_get_hw_runtime_ns(struct intel_context *ce)
> +{
> +   return ce->total_runtime *
> +  RUNTIME_INFO(ce->engine->i915)->cs_timestamp_period_ns;
> +}
> +
>  #endif /* __INTEL_CONTEXT_H__ */
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index 963d33dc5289..7b08bf87fb82 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -69,6 +69,11 @@ struct intel_context {
> u64 lrc_desc;
> u32 tag; /* cookie passed to HW to track this context on submission */
>  
> +   /* Time on GPU as tracked by the hw. */
> +   u32 last_runtime;
> +   u64 total_runtime;
> +   u32 *pphwsp;

I wouldn't bother with keeping pphwsp, we know it's the page before the
reg state. At least for the foreseeable future.

> unsigned int active_count; /* protected by timeline->mutex */
>  
> atomic_t pin_count;
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index dd559547500f..26999b43e5a1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1289,6 +1289,7 @@ __execlists_schedule_out(struct i915_request *rq,
>  struct intel_engine_cs * const engine)
>  {
> struct intel_context *ce = rq->context;
> +   u32 old, new;
>  
> /*
>  * NB process_csb() is not under the engine->active.lock and hence
> @@ -1309,6 +1310,13 @@ __execlists_schedule_out(struct i915_request *rq,
> execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
> intel_gt_pm_put_async(engine->gt);
>  
> +   old = ce->last_runtime;
> +   ce->last_runtime = new = ce->pphwsp[16];
> +   if (new > old)
> +   ce->total_runtime += new - old;
> +   else
> +   ce->total_runtime += (~0UL - old) + new + 1;

It's u32, unsigned wrap-around arithmetic is defined, so just
ce->total_runtime += new - old;

> +
> /*
>  * If this is part of a virtual engine, its next request may
>  * have been blocked waiting for access to the active context.
> @@ -2608,6 +2616,7 @@ __execlists_context_pin(struct intel_context *ce,
>  
> ce->lrc_desc = lrc_descriptor(ce, engine) | CTX_DESC_FORCE_RESTORE;
> ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
> +   ce->pphwsp = vaddr + LRC_PPHWSP_PN * PAGE_SIZE;
> __execlists_update_reg_state(ce, engine);
>  
> return 0;
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 6670a0763be2..7732748e1939 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -1042,6 +1042,8 @@ void intel_device_info_runtime_init(struct 
> drm_i915_private *dev_priv)
>  
> /* Initialize command stream timestamp frequency */
> runtime->cs_timestamp_frequency_khz = 
> read_timestamp_frequency(dev_priv);
> +   runtime->cs_timestamp_period_ns =
> +   div_u64(1e6, runtime->cs_timestamp_frequency_khz);

drm_debug(_priv->drm, "CS timestamp wraparound in %lld\n",
div_u64(U32_MAX * runtime->cs_timestamp_period_ns, NSEC_PER_SEC);
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 03/14] drm/i915/gt: runtime-pm is no longer required for ce->ops->pin()

2020-01-10 Thread Mika Kuoppala
Chris Wilson  writes:

> Now that we have moved the runtime-pm management out of
> intel_context_acctive_acquire, and that itself out of ce->ops->pin(),
> no

s/acctive/active

> explicit runtime pm wakeref is required in intel_context_pin().
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/gt/intel_context.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index cac80d87b2bb..9796a54b4f47 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -105,14 +105,11 @@ int __intel_context_do_pin(struct intel_context *ce)
>   return -EINTR;
>  
>   if (likely(!atomic_read(>pin_count))) {
> - intel_wakeref_t wakeref;
> -
>   err = intel_context_active_acquire(ce);
>   if (unlikely(err))
>   goto err;
>  
> - with_intel_runtime_pm(ce->engine->uncore->rpm, wakeref)
> - err = ce->ops->pin(ce);
> + err = ce->ops->pin(ce);
>   if (unlikely(err))
>   goto err_active;
>  
> -- 
> 2.25.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Skip trying to unbind in restore_ggtt_mappings

2020-01-10 Thread Matthew Auld
On Fri, 10 Jan 2020 at 11:04, Chris Wilson  wrote:
>
> Currently we first to try to unbind the VMA (and lazily rebind on next
> use) as an optimisation during restore_ggtt_mappings. Ideally, the only
> objects in the GGTT upon resume are the pinned kernel objects which
> can't be unbound and need to be restored. As the unbind interferes with
> the plan to mark those objects as active for error capture, forgo the
> optimisation.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex

2020-01-10 Thread Chris Wilson
We need to hold the runtime-pm wakeref to update the global PTEs (as
they exist behind a PCI BAR). However, some systems invoke ACPI during
runtime resume and so require allocations, which is verboten inside the
vm->mutex. Ergo, we must not use intel_runtime_pm_get() inside the
mutex, but lift the call outside.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/958
Signed-off-by: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 28 +---
 drivers/gpu/drm/i915/i915_vma.c  | 13 +
 2 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 795cd267e28e..6474c6190d3d 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -430,9 +430,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
 enum i915_cache_level cache_level,
 u32 flags)
 {
-   struct drm_i915_private *i915 = vma->vm->i915;
struct drm_i915_gem_object *obj = vma->obj;
-   intel_wakeref_t wakeref;
u32 pte_flags;
 
/* Applicable to VLV (gen8+ do not support RO in the GGTT) */
@@ -440,8 +438,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
if (i915_gem_object_is_readonly(obj))
pte_flags |= PTE_READ_ONLY;
 
-   with_intel_runtime_pm(>runtime_pm, wakeref)
-   vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
+   vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
 
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
 
@@ -457,11 +454,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
 
 static void ggtt_unbind_vma(struct i915_vma *vma)
 {
-   struct drm_i915_private *i915 = vma->vm->i915;
-   intel_wakeref_t wakeref;
-
-   with_intel_runtime_pm(>runtime_pm, wakeref)
-   vma->vm->clear_range(vma->vm, vma->node.start, vma->size);
+   vma->vm->clear_range(vma->vm, vma->node.start, vma->size);
 }
 
 static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt)
@@ -569,7 +562,6 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
 enum i915_cache_level cache_level,
 u32 flags)
 {
-   struct drm_i915_private *i915 = vma->vm->i915;
u32 pte_flags;
int ret;
 
@@ -597,28 +589,18 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
 cache_level, pte_flags);
}
 
-   if (flags & I915_VMA_GLOBAL_BIND) {
-   intel_wakeref_t wakeref;
-
-   with_intel_runtime_pm(>runtime_pm, wakeref) {
-   vma->vm->insert_entries(vma->vm, vma,
-   cache_level, pte_flags);
-   }
-   }
+   if (flags & I915_VMA_GLOBAL_BIND)
+   vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
 
return 0;
 }
 
 static void aliasing_gtt_unbind_vma(struct i915_vma *vma)
 {
-   struct drm_i915_private *i915 = vma->vm->i915;
-
if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
struct i915_address_space *vm = vma->vm;
-   intel_wakeref_t wakeref;
 
-   with_intel_runtime_pm(>runtime_pm, wakeref)
-   vm->clear_range(vm, vma->node.start, vma->size);
+   vm->clear_range(vm, vma->node.start, vma->size);
}
 
if (test_and_clear_bit(I915_VMA_ALLOC_BIT, __i915_vma_flags(vma))) {
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 43d5c270bdb0..c702708131b8 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -858,6 +858,7 @@ static void vma_unbind_pages(struct i915_vma *vma)
 int i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
 {
struct i915_vma_work *work = NULL;
+   intel_wakeref_t wakeref = 0;
unsigned int bound;
int err;
 
@@ -883,6 +884,9 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
}
}
 
+   if (flags & PIN_GLOBAL)
+   wakeref = intel_runtime_pm_get(>vm->i915->runtime_pm);
+
/* No more allocations allowed once we hold vm->mutex */
err = mutex_lock_interruptible(>vm->mutex);
if (err)
@@ -946,6 +950,8 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
 err_fence:
if (work)
dma_fence_work_commit(>base);
+   if (wakeref)
+   intel_runtime_pm_put(>vm->i915->runtime_pm, wakeref);
 err_pages:
vma_put_pages(vma);
return err;
@@ -1246,11 +1252,15 @@ int __i915_vma_unbind(struct i915_vma *vma)
 int i915_vma_unbind(struct i915_vma *vma)
 {
struct i915_address_space *vm = vma->vm;
+   intel_wakeref_t wakeref = 0;
int err;
 
   

[Intel-gfx] ✓ Fi.CI.IGT: success for Add support for mipi dsi cmd mode (rev5)

2020-01-10 Thread Patchwork
== Series Details ==

Series: Add support for mipi dsi cmd mode (rev5)
URL   : https://patchwork.freedesktop.org/series/69290/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7712_full -> Patchwork_16037_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@bcs0-mixed-process:
- shard-skl:  [PASS][1] -> [FAIL][2] ([i915#679])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-skl4/igt@gem_ctx_persiste...@bcs0-mixed-process.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-skl8/igt@gem_ctx_persiste...@bcs0-mixed-process.html

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) 
+1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-iclb1/igt@gem_ctx_persiste...@vcs1-queued.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-iclb3/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_eio@in-flight-suspend:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#69]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-skl3/igt@gem_...@in-flight-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-skl3/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-iclb2/igt@gem_exec_balan...@smoke.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-iclb8/igt@gem_exec_balan...@smoke.html
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([fdo#111593] / 
[i915#472]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-tglb2/igt@gem_exec_balan...@smoke.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-tglb2/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_create@forked:
- shard-kbl:  [PASS][11] -> [TIMEOUT][12] ([i915#940])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-kbl7/igt@gem_exec_cre...@forked.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-kbl4/igt@gem_exec_cre...@forked.html

  * igt@gem_exec_parallel@basic:
- shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([i915#472] / 
[i915#476])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-tglb1/igt@gem_exec_paral...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-tglb9/igt@gem_exec_paral...@basic.html

  * igt@gem_exec_parallel@vcs1-fds:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112080]) +11 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +3 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-iclb3/igt@gem_exec_sched...@in-order-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-iclb4/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_exec_schedule@pi-common-bsd1:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109276]) +19 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-iclb7/igt@gem_exec_sched...@pi-common-bsd1.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][21] -> [SKIP][22] ([i915#677])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-iclb6/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@preempt-queue-chain-blt:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([fdo#111606] / 
[fdo#111677] / [i915#472])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-tglb3/igt@gem_exec_sched...@preempt-queue-chain-blt.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16037/shard-tglb6/igt@gem_exec_sched...@preempt-queue-chain-blt.html

  * igt@gem_exec_schedule@preempt-queue-contexts-chain-render:
- shard-tglb: [PASS][25] -> [INCOMPLETE][26] ([fdo#111677] / 
[i915#472])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7712/shard-tglb2/igt@gem_exec_sched...@preempt-queue-contexts-chain-render.html
   

Re: [Intel-gfx] [RFC 2/8] drm/i915: Update client name on context create

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 13:30:43)
> From: Tvrtko Ursulin 
> 
> Some clients have the DRM fd passed to them over a socket by the X server.
> 
> Grab the real client and pid when they create their first context and
> update the exposed data for more useful enumeration.
> 
> v2:
>  * Do not leak the pid reference and borrow context idr_lock. (Chris)
> 
> v3:
>  * More avoiding leaks. (Chris)
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 36 ++---
>  drivers/gpu/drm/i915/i915_drm_client.c  |  4 +--
>  drivers/gpu/drm/i915/i915_drm_client.h  |  4 +++
>  3 files changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index a2e57e62af30..ba3c29a01535 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -77,6 +77,7 @@
>  #include "gt/intel_lrc_reg.h"
>  #include "gt/intel_ring.h"
>  
> +#include "i915_drm_client.h"
>  #include "i915_gem_context.h"
>  #include "i915_globals.h"
>  #include "i915_trace.h"
> @@ -2181,7 +2182,10 @@ int i915_gem_context_create_ioctl(struct drm_device 
> *dev, void *data,
>  {
> struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_context_create_ext *args = data;
> +   struct drm_i915_file_private *file_priv = file->driver_priv;
> +   struct i915_drm_client *client = file_priv->client;
> struct create_ext ext_data;
> +   struct pid *pid;
> int ret;
> u32 id;
>  
> @@ -2195,16 +2199,35 @@ int i915_gem_context_create_ioctl(struct drm_device 
> *dev, void *data,
> if (ret)
> return ret;
>  
> -   ext_data.fpriv = file->driver_priv;
> +   pid = get_task_pid(current, PIDTYPE_PID);
> +
> +   ext_data.fpriv = file_priv;

Might as well do this in the declaration ?

struct create_ext ext_data {
.fpriv = file->driver_priv,
};
struct i915_drm_client *client = ext_data.fpriv->client;

?

> if (client_is_banned(ext_data.fpriv)) {
> DRM_DEBUG("client %s[%d] banned from creating ctx\n",
> - current->comm, task_pid_nr(current));
> -   return -EIO;
> + current->comm, pid_nr(pid));
> +   ret = -EIO;
> +   goto err_pid;
> +   }
> +
> +   /*
> +* Borrow struct_mutex to protect the client remove-add cycle.
> +*/
> +   ret = mutex_lock_interruptible(>struct_mutex);
> +   if (ret)
> +   goto err_pid;
> +   if (client->pid != pid) {
> +   __i915_drm_client_unregister(client);
> +   ret = __i915_drm_client_register(client, current);
> }
> +   mutex_unlock(>struct_mutex);
> +   if (ret)
> +   goto err_pid;

-> i915_drm_client_update();

And let it manage the pid locally?

>  
> ext_data.ctx = i915_gem_create_context(i915, args->flags);
> -   if (IS_ERR(ext_data.ctx))
> -   return PTR_ERR(ext_data.ctx);
> +   if (IS_ERR(ext_data.ctx)) {
> +   ret = PTR_ERR(ext_data.ctx);
> +   goto err_pid;
> +   }
>  
> if (args->flags & I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS) {
> ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
> @@ -2226,6 +2249,9 @@ int i915_gem_context_create_ioctl(struct drm_device 
> *dev, void *data,
>  
>  err_ctx:
> context_close(ext_data.ctx);
> +err_pid:
> +   put_pid(pid);
> +
> return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index 02356f48d85b..666ec67c77e9 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -36,7 +36,7 @@ show_client_pid(struct device *kdev, struct 
> device_attribute *attr, char *buf)
> client->closed ? ">" : "");
>  }
>  
> -static int
> +int
>  __i915_drm_client_register(struct i915_drm_client *client,
>struct task_struct *task)
>  {
> @@ -89,7 +89,7 @@ __i915_drm_client_register(struct i915_drm_client *client,
> return ret;
>  }
>  
> -static void __i915_drm_client_unregister(struct i915_drm_client *client)
> +void __i915_drm_client_unregister(struct i915_drm_client *client)
>  {
> if (!client->name)
> return; /* fbdev client or error during drm open */
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
> b/drivers/gpu/drm/i915/i915_drm_client.h
> index 8b261dc4a1f3..2c692345bc4e 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.h
> +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> @@ -58,4 +58,8 @@ void i915_drm_client_close(struct i915_drm_client *client);
>  struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients,
> struct task_struct 

Re: [Intel-gfx] [RFC 6/8] drm/i915: Expose per-engine client busyness

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 13:30:47)
> +static ssize_t
> +show_client_busy(struct device *kdev, struct device_attribute *attr, char 
> *buf)
> +{
> +   struct i915_engine_busy_attribute *i915_attr =
> +   container_of(attr, typeof(*i915_attr), attr);
> +   struct list_head *list = _attr->client->ctx_list;
> +   unsigned int engine_class = i915_attr->engine_class;
> +   struct i915_gem_context *ctx;
> +   u64 total = 0;
> +
> +   if (i915_attr->no_busy_stats)
> +   return -ENODEV;
> +
> +   rcu_read_lock();
> +   list_for_each_entry_rcu(ctx, list, client_link)
> +   total += sw_busy_add(ctx, engine_class);
> +   rcu_read_unlock();
> +
> +   return snprintf(buf, PAGE_SIZE, "%llu\n", total);
> +}
> +
> +static const char *uabi_class_names[] = {
> +   [I915_ENGINE_CLASS_RENDER] = "0",
> +   [I915_ENGINE_CLASS_COPY] = "1",
> +   [I915_ENGINE_CLASS_VIDEO] = "2",
> +   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "3",
> +};

Hmm. /sys/class/drm/card0/clients/0/busy/0

Ok. I was worried this was 0/0 and so very bland and liable to clash
later.

> +
>  int
>  __i915_drm_client_register(struct i915_drm_client *client,
>struct task_struct *task)
>  {
> struct i915_drm_clients *clients = client->clients;
> +   struct drm_i915_private *i915 =
> +   container_of(clients, typeof(*i915), clients);
> +   struct intel_engine_cs *engine;
> struct device_attribute *attr;
> -   int ret = -ENOMEM;
> +   int i, ret = -ENOMEM;
> char idstr[32];
>  
> if (!clients->root)
> @@ -77,10 +130,71 @@ __i915_drm_client_register(struct i915_drm_client 
> *client,
> if (ret)
> goto err_attr;
>  
> +   if (HAS_LOGICAL_RING_CONTEXTS(i915)) {
> +   client->busy_root =
> +   kobject_create_and_add("busy", client->root);
> +   if (!client->busy_root)
> +   goto err_attr;
> +
> +   for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) {
> +   struct i915_engine_busy_attribute *i915_attr =
> +   >attr.busy[i];


if (!intel_engine_lookup_user(i915, i, 0))
continue;

i.e. skip if we don't have any engines of that class in the system.

> +
> +   i915_attr->client = client;
> +   i915_attr->engine_class = i;
> +
> +   attr = _attr->attr;
> +
> +   sysfs_attr_init(>attr);
> +
> +   attr->attr.name = uabi_class_names[i];
> +   attr->attr.mode = 0444;
> +   attr->show = show_client_busy;
> +
> +   ret = sysfs_create_file(client->busy_root,
> +   (struct attribute *)attr);
> +   if (ret)
> +   goto err_busy;
> +   }
> +
> +   /* Enable busy stats on all engines. */
> +   i = 0;
> +   for_each_uabi_engine(engine, i915) {
> +   ret = intel_enable_engine_stats(engine);

Hmm. We gave it a global bit in 

i915->caps.scheduler & I915_SCHEDULER_CAP_ENABLED.

That'll avoid having to do the individual checking and rollback.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 0/5] drm/i915: conversion to new drm logging macros.

2020-01-10 Thread Jani Nikula
On Tue, 07 Jan 2020, Wambui Karuga  wrote:
> This series begins the conversion to using the new struct drm_device
> based logging macros in drm/i915.
>
> Wambui Karuga (5):
>   drm/i915: convert to using the drm_dbg_kms() macro.
>   drm/i915: use new struct drm_device logging macros.
>   drm/i915: use new struct drm_device based logging macros.
>   drm/i915: convert to using new struct drm_device logging macros
>   drm/i915: use new struct drm_device based macros.

Thanks for the patches, pushed to drm-intel-next-queued.

As it's impossible to distinguish the commits from each other by the
subject line alone, I've amended the prefix while pushing as follows:

drm/i915/pch: convert to using the drm_dbg_kms() macro.
drm/i915/pm: use new struct drm_device logging macros.
drm/i915/lmem: use new struct drm_device based logging macros.
drm/i915/sideband: convert to using new struct drm_device logging macros
drm/i915/uncore: use new struct drm_device based macros.

Please pay attention to this in future work. It's not always obvious
what the prefix should be, but 'git log -- path/to/file.c' will go a
long way.

BR,
Jani.


>
>  drivers/gpu/drm/i915/intel_pch.c |  46 +--
>  drivers/gpu/drm/i915/intel_pm.c  | 351 +--
>  drivers/gpu/drm/i915/intel_region_lmem.c |  10 +-
>  drivers/gpu/drm/i915/intel_sideband.c|  29 +-
>  drivers/gpu/drm/i915/intel_uncore.c  |  25 +-
>  5 files changed, 254 insertions(+), 207 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
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/3] drm/i915/gt: Skip trying to unbind in restore_ggtt_mappings

2020-01-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/gt: Skip trying to unbind in 
restore_ggtt_mappings
URL   : https://patchwork.freedesktop.org/series/71876/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7716 -> Patchwork_16049


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_sync@basic-store-each:
- fi-tgl-y:   [PASS][1] -> [INCOMPLETE][2] ([CI#80] / [i915#472])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-tgl-y/igt@gem_s...@basic-store-each.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-tgl-y/igt@gem_s...@basic-store-each.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#889])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-cfl-guc/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-cfl-guc/igt@i915_module_l...@reload-with-fault-injection.html
- fi-skl-6770hq:  [PASS][5] -> [DMESG-WARN][6] ([i915#889])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
- fi-kbl-x1275:   [PASS][7] -> [INCOMPLETE][8] ([i915#879])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-kbl-x1275/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-kbl-x1275/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-guc: [PASS][9] -> [INCOMPLETE][10] ([i915#148])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-cfl-guc/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-cfl-guc/igt@i915_pm_...@module-reload.html
- fi-skl-6770hq:  [PASS][11] -> [FAIL][12] ([i915#178])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][13] -> [FAIL][14] ([fdo#111407])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2:  [INCOMPLETE][15] ([i915#671]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
- fi-bsw-nick:[DMESG-FAIL][17] ([i915#723]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-bsw-nick/igt@i915_selftest@live_blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-bsw-nick/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gt_heartbeat:
- fi-bsw-n3050:   [DMESG-FAIL][19] ([i915#541]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-bsw-n3050/igt@i915_selftest@live_gt_heartbeat.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-bsw-n3050/igt@i915_selftest@live_gt_heartbeat.html

  
 Warnings 

  * igt@i915_selftest@live_blt:
- fi-hsw-4770r:   [DMESG-FAIL][21] ([i915#553] / [i915#725]) -> 
[DMESG-FAIL][22] ([i915#725])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7716/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16049/fi-hsw-4770r/igt@i915_selftest@live_blt.html

  
  [CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [i915#148]: https://gitlab.freedesktop.org/drm/intel/issues/148
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
  [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
  [i915#671]: https://gitlab.freedesktop.org/drm/intel/issues/671
  [i915#723]: 

[Intel-gfx] [RFC 5/8] drm/i915: Contexts can use struct pid stored in the client

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Now that contexts keep their parent client reference counted, we can
remove separate struct pid reference owned by contexts in favour of the
one already held by the client.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 13 -
 drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 10 --
 drivers/gpu/drm/i915/i915_debugfs.c   |  7 ---
 drivers/gpu/drm/i915/i915_gpu_error.c |  8 
 4 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ba8ccc754f20..758cebb99ba4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -323,7 +323,6 @@ static void i915_gem_context_free(struct i915_gem_context 
*ctx)
if (ctx->timeline)
intel_timeline_put(ctx->timeline);
 
-   put_pid(ctx->pid);
mutex_destroy(>mutex);
 
kfree_rcu(ctx, rcu);
@@ -794,24 +793,20 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
WRITE_ONCE(vm->file, fpriv); /* XXX */
mutex_unlock(>mutex);
 
-   ctx->pid = get_task_pid(current, PIDTYPE_PID);
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
-current->comm, pid_nr(ctx->pid));
+current->comm, pid_nr(client->pid));
 
/* And finally expose ourselves to userspace via the idr */
ret = xa_alloc(>context_xa, id, ctx, xa_limit_32b, GFP_KERNEL);
-   if (ret) {
-   put_pid(fetch_and_zero(>pid));
-   goto out;
-   }
+   if (ret)
+   return ret;
 
ctx->client = client = i915_drm_client_get(fpriv->client);
spin_lock(>ctx_lock);
list_add_tail_rcu(>client_link, >ctx_list);
spin_unlock(>ctx_lock);
 
-out:
-   return ret;
+   return 0;
 }
 
 int i915_gem_context_open(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 879824159646..23421377a43d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -90,16 +90,6 @@ struct i915_gem_context {
 */
struct i915_address_space __rcu *vm;
 
-   /**
-* @pid: process id of creator
-*
-* Note that who created the context may not be the principle user,
-* as the context may be shared across a local socket. However,
-* that should only affect the default context, all contexts created
-* explicitly by the client are expected to be isolated.
-*/
-   struct pid *pid;
-
/** link: place with _i915_private.context_list */
struct list_head link;
struct llist_node free_link;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8f01c2bc7355..bc533501b4e0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -346,7 +346,8 @@ static void print_context_stats(struct seq_file *m,
rcu_read_unlock();
 
rcu_read_lock();
-   task = pid_task(ctx->pid ?: file->pid, PIDTYPE_PID);
+   task = pid_task(ctx->client->pid ?: file->pid,
+   PIDTYPE_PID);
snprintf(name, sizeof(name), "%s",
 task ? task->comm : "");
rcu_read_unlock();
@@ -1492,10 +1493,10 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
spin_unlock(>gem.contexts.lock);
 
seq_puts(m, "HW context ");
-   if (ctx->pid) {
+   if (ctx->client->pid) {
struct task_struct *task;
 
-   task = get_pid_task(ctx->pid, PIDTYPE_PID);
+   task = get_pid_task(ctx->client->pid, PIDTYPE_PID);
if (task) {
seq_printf(m, "(%s [%d]) ",
   task->comm, task->pid);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index fda0977d2059..9240327bdb7d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1235,8 +1235,8 @@ static void record_request(const struct i915_request 
*request,
erq->pid = 0;
rcu_read_lock();
ctx = rcu_dereference(request->context->gem_context);
-   if (ctx)
-   erq->pid = pid_nr(ctx->pid);
+   if (ctx && ctx->client->pid)
+   erq->pid = pid_nr(ctx->client->pid);
rcu_read_unlock();
 }
 
@@ -1313,11 +1313,11 @@ static bool record_context(struct 
drm_i915_error_context *e,
if (ctx && !kref_get_unless_zero(>ref))
 

[Intel-gfx] [RFC 7/8] drm/i915: Track hw reported context runtime

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP
which will be useful for us in cases when we are not able to track context
busyness ourselves (like with GuC). Keep a copy of this in struct
intel_context from where it can be easily read even if the context is not
pinned.

QQQ: Do we want to make this accounting conditional / able to turn on/off?

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_context.h   | 7 +++
 drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 9 +
 drivers/gpu/drm/i915/intel_device_info.c  | 2 ++
 drivers/gpu/drm/i915/intel_device_info.h  | 1 +
 5 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
index 30f0268fcc9a..389a05736fc7 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -12,6 +12,7 @@
 #include 
 
 #include "i915_active.h"
+#include "i915_drv.h"
 #include "intel_context_types.h"
 #include "intel_engine_types.h"
 #include "intel_ring_types.h"
@@ -235,4 +236,10 @@ __intel_context_stats_start(struct intel_context_stats 
*stats, ktime_t now)
 
 ktime_t intel_context_get_busy_time(struct intel_context *ce);
 
+static inline u64 intel_context_get_hw_runtime_ns(struct intel_context *ce)
+{
+   return ce->total_runtime *
+  RUNTIME_INFO(ce->engine->i915)->cs_timestamp_period_ns;
+}
+
 #endif /* __INTEL_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 963d33dc5289..7b08bf87fb82 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -69,6 +69,11 @@ struct intel_context {
u64 lrc_desc;
u32 tag; /* cookie passed to HW to track this context on submission */
 
+   /* Time on GPU as tracked by the hw. */
+   u32 last_runtime;
+   u64 total_runtime;
+   u32 *pphwsp;
+
unsigned int active_count; /* protected by timeline->mutex */
 
atomic_t pin_count;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index dd559547500f..26999b43e5a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1289,6 +1289,7 @@ __execlists_schedule_out(struct i915_request *rq,
 struct intel_engine_cs * const engine)
 {
struct intel_context *ce = rq->context;
+   u32 old, new;
 
/*
 * NB process_csb() is not under the engine->active.lock and hence
@@ -1309,6 +1310,13 @@ __execlists_schedule_out(struct i915_request *rq,
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
intel_gt_pm_put_async(engine->gt);
 
+   old = ce->last_runtime;
+   ce->last_runtime = new = ce->pphwsp[16];
+   if (new > old)
+   ce->total_runtime += new - old;
+   else
+   ce->total_runtime += (~0UL - old) + new + 1;
+
/*
 * If this is part of a virtual engine, its next request may
 * have been blocked waiting for access to the active context.
@@ -2608,6 +2616,7 @@ __execlists_context_pin(struct intel_context *ce,
 
ce->lrc_desc = lrc_descriptor(ce, engine) | CTX_DESC_FORCE_RESTORE;
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
+   ce->pphwsp = vaddr + LRC_PPHWSP_PN * PAGE_SIZE;
__execlists_update_reg_state(ce, engine);
 
return 0;
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 6670a0763be2..7732748e1939 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -1042,6 +1042,8 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
 
/* Initialize command stream timestamp frequency */
runtime->cs_timestamp_frequency_khz = 
read_timestamp_frequency(dev_priv);
+   runtime->cs_timestamp_period_ns =
+   div_u64(1e6, runtime->cs_timestamp_frequency_khz);
 }
 
 void intel_driver_caps_print(const struct intel_driver_caps *caps,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 2725cb7fc169..9ec816dbc418 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -216,6 +216,7 @@ struct intel_runtime_info {
struct sseu_dev_info sseu;
 
u32 cs_timestamp_frequency_khz;
+   u32 cs_timestamp_period_ns;
 
/* Media engine access to SFC per instance */
u8 vdbox_sfc_access;
-- 
2.20.1

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


[Intel-gfx] [RFC 4/8] drm/i915: Track all user contexts per client

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.

To enable this we start tracking all context belonging to a client on a
separate list, plus we make contexts take a reference on their clients
file_priv.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 21 ++-
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  6 ++
 drivers/gpu/drm/i915/i915_drm_client.c|  3 +++
 drivers/gpu/drm/i915/i915_drm_client.h|  5 +
 4 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ba3c29a01535..ba8ccc754f20 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -301,8 +301,18 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
 
 static void i915_gem_context_free(struct i915_gem_context *ctx)
 {
+   struct i915_drm_client *client = ctx->client;
+
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
 
+   if (client) {
+   spin_lock(>ctx_lock);
+   list_del_rcu(>client_link);
+   spin_unlock(>ctx_lock);
+
+   i915_drm_client_put(client);
+   }
+
spin_lock(>i915->gem.contexts.lock);
list_del(>link);
spin_unlock(>i915->gem.contexts.lock);
@@ -772,6 +782,7 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
struct drm_i915_file_private *fpriv,
u32 *id)
 {
+   struct i915_drm_client *client;
struct i915_address_space *vm;
int ret;
 
@@ -789,9 +800,17 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
 
/* And finally expose ourselves to userspace via the idr */
ret = xa_alloc(>context_xa, id, ctx, xa_limit_32b, GFP_KERNEL);
-   if (ret)
+   if (ret) {
put_pid(fetch_and_zero(>pid));
+   goto out;
+   }
 
+   ctx->client = client = i915_drm_client_get(fpriv->client);
+   spin_lock(>ctx_lock);
+   list_add_tail_rcu(>client_link, >ctx_list);
+   spin_unlock(>ctx_lock);
+
+out:
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 017ca803ab47..879824159646 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -104,6 +104,12 @@ struct i915_gem_context {
struct list_head link;
struct llist_node free_link;
 
+   /** client: struct i915_drm_client */
+   struct i915_drm_client *client;
+
+   /** link: _list */
+   struct list_head client_link;
+
/**
 * @ref: reference count
 *
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index 666ec67c77e9..195777b95891 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -111,6 +111,9 @@ i915_drm_client_add(struct i915_drm_clients *clients, 
struct task_struct *task)
return ERR_PTR(-ENOMEM);
 
kref_init(>kref);
+   spin_lock_init(>ctx_lock);
+   INIT_LIST_HEAD(>ctx_list);
+
client->clients = clients;
 
ret = xa_alloc_cyclic(>xarray, >id, client,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
b/drivers/gpu/drm/i915/i915_drm_client.h
index 2c692345bc4e..16d8db075a7d 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -10,9 +10,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct i915_drm_clients {
@@ -30,6 +32,9 @@ struct i915_drm_client {
char *name;
bool closed;
 
+   spinlock_t ctx_lock;
+   struct list_head ctx_list;
+
struct i915_drm_clients *clients;
 
struct kobject *root;
-- 
2.20.1

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


[Intel-gfx] [RFC 2/8] drm/i915: Update client name on context create

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Some clients have the DRM fd passed to them over a socket by the X server.

Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.

v2:
 * Do not leak the pid reference and borrow context idr_lock. (Chris)

v3:
 * More avoiding leaks. (Chris)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 36 ++---
 drivers/gpu/drm/i915/i915_drm_client.c  |  4 +--
 drivers/gpu/drm/i915/i915_drm_client.h  |  4 +++
 3 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a2e57e62af30..ba3c29a01535 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -77,6 +77,7 @@
 #include "gt/intel_lrc_reg.h"
 #include "gt/intel_ring.h"
 
+#include "i915_drm_client.h"
 #include "i915_gem_context.h"
 #include "i915_globals.h"
 #include "i915_trace.h"
@@ -2181,7 +2182,10 @@ int i915_gem_context_create_ioctl(struct drm_device 
*dev, void *data,
 {
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_context_create_ext *args = data;
+   struct drm_i915_file_private *file_priv = file->driver_priv;
+   struct i915_drm_client *client = file_priv->client;
struct create_ext ext_data;
+   struct pid *pid;
int ret;
u32 id;
 
@@ -2195,16 +2199,35 @@ int i915_gem_context_create_ioctl(struct drm_device 
*dev, void *data,
if (ret)
return ret;
 
-   ext_data.fpriv = file->driver_priv;
+   pid = get_task_pid(current, PIDTYPE_PID);
+
+   ext_data.fpriv = file_priv;
if (client_is_banned(ext_data.fpriv)) {
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
- current->comm, task_pid_nr(current));
-   return -EIO;
+ current->comm, pid_nr(pid));
+   ret = -EIO;
+   goto err_pid;
+   }
+
+   /*
+* Borrow struct_mutex to protect the client remove-add cycle.
+*/
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   goto err_pid;
+   if (client->pid != pid) {
+   __i915_drm_client_unregister(client);
+   ret = __i915_drm_client_register(client, current);
}
+   mutex_unlock(>struct_mutex);
+   if (ret)
+   goto err_pid;
 
ext_data.ctx = i915_gem_create_context(i915, args->flags);
-   if (IS_ERR(ext_data.ctx))
-   return PTR_ERR(ext_data.ctx);
+   if (IS_ERR(ext_data.ctx)) {
+   ret = PTR_ERR(ext_data.ctx);
+   goto err_pid;
+   }
 
if (args->flags & I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS) {
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
@@ -2226,6 +2249,9 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, 
void *data,
 
 err_ctx:
context_close(ext_data.ctx);
+err_pid:
+   put_pid(pid);
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index 02356f48d85b..666ec67c77e9 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -36,7 +36,7 @@ show_client_pid(struct device *kdev, struct device_attribute 
*attr, char *buf)
client->closed ? ">" : "");
 }
 
-static int
+int
 __i915_drm_client_register(struct i915_drm_client *client,
   struct task_struct *task)
 {
@@ -89,7 +89,7 @@ __i915_drm_client_register(struct i915_drm_client *client,
return ret;
 }
 
-static void __i915_drm_client_unregister(struct i915_drm_client *client)
+void __i915_drm_client_unregister(struct i915_drm_client *client)
 {
if (!client->name)
return; /* fbdev client or error during drm open */
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
b/drivers/gpu/drm/i915/i915_drm_client.h
index 8b261dc4a1f3..2c692345bc4e 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -58,4 +58,8 @@ void i915_drm_client_close(struct i915_drm_client *client);
 struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients,
struct task_struct *task);
 
+int __i915_drm_client_register(struct i915_drm_client *client,
+  struct task_struct *task);
+void __i915_drm_client_unregister(struct i915_drm_client *client);
+
 #endif /* !__I915_DRM_CLIENT_H__ */
-- 
2.20.1

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


[Intel-gfx] [RFC 6/8] drm/i915: Expose per-engine client busyness

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Expose per-client and per-engine busyness under the previously added sysfs
client root.

The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing on the GPU.

This enables userspace to create a top-like tool for GPU utilization:

==
intel-gpu-top -  935/ 935 MHz;0% RC6; 14.73 Watts; 1097 irqs/s

  IMC reads: 1401 MiB/s
 IMC writes:4 MiB/s

  ENGINE  BUSY MI_SEMA MI_WAIT
 Render/3D/0   63.73% |███   |  3%  0%
   Blitter/09.53% |██▊   |  6%  0%
 Video/0   39.32% |███▊  | 16%  0%
 Video/1   15.62% |▋ |  0%  0%
  VideoEnhance/00.00% |  |  0%  0%

  PIDNAME RCS  BCS  VCS VECS
 4084gem_wsim |█▌ ||█  ||   ||   |
 4086gem_wsim |█▌ ||   ||███||   |
==

v2: Use intel_context_engine_get_busy_time.
v3: New directory structure.
v4: Rebase.
v5: sysfs_attr_init.
v6: Small tidy in i915_gem_add_client.
v7: Rebase to be engine class based.
v8:
 * Always enable stats.
 * Walk all client contexts.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drm_client.c | 127 -
 drivers/gpu/drm/i915/i915_drm_client.h |  13 +++
 2 files changed, 139 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index 195777b95891..55b2f86cc4c1 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -8,7 +8,11 @@
 #include 
 #include 
 
+#include 
+
 #include "i915_drm_client.h"
+#include "gem/i915_gem_context.h"
+#include "i915_drv.h"
 #include "i915_gem.h"
 #include "i915_utils.h"
 
@@ -36,13 +40,62 @@ show_client_pid(struct device *kdev, struct 
device_attribute *attr, char *buf)
client->closed ? ">" : "");
 }
 
+static u64
+sw_busy_add(struct i915_gem_context *ctx, unsigned int engine_class)
+{
+   struct i915_gem_engines *engines = rcu_dereference(ctx->engines);
+   struct i915_gem_engines_iter it;
+   struct intel_context *ce;
+   u64 total = 0;
+
+   for_each_gem_engine(ce, engines, it) {
+   if (ce->engine->uabi_class != engine_class)
+   continue;
+
+   total += ktime_to_ns(intel_context_get_busy_time(ce));
+   }
+
+   return total;
+}
+
+static ssize_t
+show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   struct i915_engine_busy_attribute *i915_attr =
+   container_of(attr, typeof(*i915_attr), attr);
+   struct list_head *list = _attr->client->ctx_list;
+   unsigned int engine_class = i915_attr->engine_class;
+   struct i915_gem_context *ctx;
+   u64 total = 0;
+
+   if (i915_attr->no_busy_stats)
+   return -ENODEV;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ctx, list, client_link)
+   total += sw_busy_add(ctx, engine_class);
+   rcu_read_unlock();
+
+   return snprintf(buf, PAGE_SIZE, "%llu\n", total);
+}
+
+static const char *uabi_class_names[] = {
+   [I915_ENGINE_CLASS_RENDER] = "0",
+   [I915_ENGINE_CLASS_COPY] = "1",
+   [I915_ENGINE_CLASS_VIDEO] = "2",
+   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "3",
+};
+
 int
 __i915_drm_client_register(struct i915_drm_client *client,
   struct task_struct *task)
 {
struct i915_drm_clients *clients = client->clients;
+   struct drm_i915_private *i915 =
+   container_of(clients, typeof(*i915), clients);
+   struct intel_engine_cs *engine;
struct device_attribute *attr;
-   int ret = -ENOMEM;
+   int i, ret = -ENOMEM;
char idstr[32];
 
if (!clients->root)
@@ -77,10 +130,71 @@ __i915_drm_client_register(struct i915_drm_client *client,
if (ret)
goto err_attr;
 
+   if (HAS_LOGICAL_RING_CONTEXTS(i915)) {
+   client->busy_root =
+   kobject_create_and_add("busy", client->root);
+   if (!client->busy_root)
+   goto err_attr;
+
+   for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) {
+   struct i915_engine_busy_attribute *i915_attr =
+   >attr.busy[i];
+
+   i915_attr->client = client;
+   i915_attr->engine_class = i;
+
+   attr = _attr->attr;
+
+  

[Intel-gfx] [RFC 3/8] drm/i915: Track per-context engine busyness

2020-01-10 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.

With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.

v2: Fix accounting for tail updates.
v3: Rebase.
v4: Mark currently running contexts as active on stats enable.
v5: Include some headers to fix the build.
v6: Added fine grained lock.
v7: Convert to seqlock. (Chris Wilson)
v8: Rebase and tidy with helpers.
v9: Refactor.
v10: Move recording start to promotion. (Chris)
v11: Consolidate duplicated code. (Chris)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_context.c   | 20 
 drivers/gpu/drm/i915/gt/intel_context.h   | 11 +
 drivers/gpu/drm/i915/gt/intel_context_types.h |  9 
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 ++-
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 46 ---
 5 files changed, 94 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 9796a54b4f47..93894460f008 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -248,6 +248,7 @@ intel_context_init(struct intel_context *ce,
INIT_LIST_HEAD(>signals);
 
mutex_init(>pin_mutex);
+   seqlock_init(>stats.lock);
 
i915_active_init(>active,
 __intel_context_active, __intel_context_retire);
@@ -342,6 +343,25 @@ struct i915_request *intel_context_create_request(struct 
intel_context *ce)
return rq;
 }
 
+ktime_t intel_context_get_busy_time(struct intel_context *ce)
+{
+   unsigned int seq;
+   ktime_t total;
+
+   do {
+   seq = read_seqbegin(>stats.lock);
+
+   total = ce->stats.total;
+
+   if (ce->stats.active)
+   total = ktime_add(total,
+ ktime_sub(ktime_get(),
+   ce->stats.start));
+   } while (read_seqretry(>stats.lock, seq));
+
+   return total;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftest_context.c"
 #endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
index 30bd248827d8..30f0268fcc9a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -224,4 +224,15 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >flags);
 }
 
+static inline void
+__intel_context_stats_start(struct intel_context_stats *stats, ktime_t now)
+{
+   if (!stats->active) {
+   stats->start = now;
+   stats->active = true;
+   }
+}
+
+ktime_t intel_context_get_busy_time(struct intel_context *ce);
+
 #endif /* __INTEL_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index ca1420fb8b53..963d33dc5289 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_active_types.h"
 #include "i915_utils.h"
@@ -83,6 +84,14 @@ struct intel_context {
 
/** sseu: Control eu/slice partitioning */
struct intel_sseu sseu;
+
+   /** stats: Context GPU engine busyness tracking. */
+   struct intel_context_stats {
+   seqlock_t lock;
+   bool active;
+   ktime_t start;
+   ktime_t total;
+   } stats;
 };
 
 #endif /* __INTEL_CONTEXT_TYPES__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 825c94e7ca0b..9a346c060469 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1543,8 +1543,20 @@ int intel_enable_engine_stats(struct intel_engine_cs 
*engine)
 
engine->stats.enabled_at = ktime_get();
 
-   /* XXX submission method oblivious? */
-   for (port = execlists->active; (rq = *port); port++)
+   /*
+* Mark currently running context as active.
+* XXX submission method oblivious?
+*/
+
+   rq = NULL;
+   port = execlists->active;
+   if (port)
+   rq = *port;
+   if (rq)
+   __intel_context_stats_start(>context->stats,
+   engine->stats.enabled_at);
+
+   for (; (rq = *port); port++)
engine->stats.active++;
 
for (port = execlists->pending; (rq = *port); port++) {
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 9af1b2b493f4..dd559547500f 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

2020-01-10 Thread Ville Syrjälä
On Thu, Jan 09, 2020 at 09:19:07PM +0100, Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä 
> wrote:
> 
> > On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> > > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä <
> > ville.syrj...@linux.intel.com>
> > > wrote:
> > >
> > > > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > > > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> > > > ville.syrj...@linux.intel.com>
> > > > > wrote:
> > > > >
> >
> 
> > wouldn't work if dpcd[0x1] == 0xa, which it likely is [*]. AMD DC
> > > identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only
> > > part of DP 1.3+ if i understand the comments in
> > > intel_dp_extended_receiver_capabilities() correctly.
> >
> >
> Ok, looking at previous debug output logs shows that those extended caps
> are not present on the systems, ie. that extended caps bit is not set. So
> dpcd[0x1] == 0xa.
> 
> 
> > Yeah, but you never know how creative they've been with the DPCD in
> > such a propritary machine. A full DPCD dump from /dev/drm_dp_aux* would
> > be nice. Can you file a bug an attach the DPCD dump there so we have a
> > good reference on what we're talking about (also for future if/when
> > someone eventually starts to wonder why we have such hacks in the
> > code)?
> >
> >
> True, it's Apple which likes to "Think different..." :/
> 
> Will do. But is there a proper/better way to do the /dev/drm_dp_aux0 dump?
> I used cat /dev/drm_dp_aux0 > dump, and that hangs, but if i interrupt it
> after a few seconds, i get a dump file of 512k size, which seems excessive?
> On AMD DC atm., in case that matters.

It can take a while to dump the whole thing. If there are errors in some
parts (against the spec but some devices simply don't care about the
spec) you may need to use ddrescue/etc. to dump everything that can be
dumped.

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


Re: [Intel-gfx] [PATCH 18/23] drm/sti: Convert to CRTC VBLANK callbacks

2020-01-10 Thread Benjamin Gaignard
Le ven. 10 janv. 2020 à 10:21, Thomas Zimmermann  a écrit :
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert sti over.
>

Hi Thomas,

Since you remove the last calls to sti_crtc functions from sti_drv.c I
think that the include could also be removed.

Anyway that looks for me:
Acked-by: Benjamin Gaignard 

Thanks,
Benjamin

> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/sti/sti_crtc.c | 11 ---
>  drivers/gpu/drm/sti/sti_crtc.h |  2 --
>  drivers/gpu/drm/sti/sti_drv.c  |  3 ---
>  3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index dc64fbfc4e61..49e6cb8f5836 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -279,12 +279,13 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
> return 0;
>  }
>
> -int sti_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe)
> +static int sti_crtc_enable_vblank(struct drm_crtc *crtc)
>  {
> +   struct drm_device *dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> struct sti_private *dev_priv = dev->dev_private;
> struct sti_compositor *compo = dev_priv->compo;
> struct notifier_block *vtg_vblank_nb = >vtg_vblank_nb[pipe];
> -   struct drm_crtc *crtc = >mixer[pipe]->drm_crtc;
> struct sti_vtg *vtg = compo->vtg[pipe];
>
> DRM_DEBUG_DRIVER("\n");
> @@ -297,8 +298,10 @@ int sti_crtc_enable_vblank(struct drm_device *dev, 
> unsigned int pipe)
> return 0;
>  }
>
> -void sti_crtc_disable_vblank(struct drm_device *drm_dev, unsigned int pipe)
> +static void sti_crtc_disable_vblank(struct drm_crtc *crtc)
>  {
> +   struct drm_device *drm_dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> struct sti_private *priv = drm_dev->dev_private;
> struct sti_compositor *compo = priv->compo;
> struct notifier_block *vtg_vblank_nb = >vtg_vblank_nb[pipe];
> @@ -330,6 +333,8 @@ static const struct drm_crtc_funcs sti_crtc_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> .late_register = sti_crtc_late_register,
> +   .enable_vblank = sti_crtc_enable_vblank,
> +   .disable_vblank = sti_crtc_disable_vblank,
>  };
>
>  bool sti_crtc_is_main(struct drm_crtc *crtc)
> diff --git a/drivers/gpu/drm/sti/sti_crtc.h b/drivers/gpu/drm/sti/sti_crtc.h
> index df489ab14e2b..1132b4586712 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.h
> +++ b/drivers/gpu/drm/sti/sti_crtc.h
> @@ -15,8 +15,6 @@ struct sti_mixer;
>
>  int sti_crtc_init(struct drm_device *drm_dev, struct sti_mixer *mixer,
>   struct drm_plane *primary, struct drm_plane *cursor);
> -int sti_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe);
> -void sti_crtc_disable_vblank(struct drm_device *dev, unsigned int pipe);
>  int sti_crtc_vblank_cb(struct notifier_block *nb,
>unsigned long event, void *data);
>  bool sti_crtc_is_main(struct drm_crtc *drm_crtc);
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index a39fc36f815b..8e30001bf545 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -146,9 +146,6 @@ static struct drm_driver sti_driver = {
> .dumb_create = drm_gem_cma_dumb_create,
> .fops = _driver_fops,
>
> -   .enable_vblank = sti_crtc_enable_vblank,
> -   .disable_vblank = sti_crtc_disable_vblank,
> -
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> --
> 2.24.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC 3/8] drm/i915: Track per-context engine busyness

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 13:30:44)
>  #endif /* __INTEL_CONTEXT_TYPES__ */
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 825c94e7ca0b..9a346c060469 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1543,8 +1543,20 @@ int intel_enable_engine_stats(struct intel_engine_cs 
> *engine)
>  
> engine->stats.enabled_at = ktime_get();
>  
> -   /* XXX submission method oblivious? */
> -   for (port = execlists->active; (rq = *port); port++)
> +   /*
> +* Mark currently running context as active.
> +* XXX submission method oblivious?
> +*/
> +
> +   rq = NULL;
> +   port = execlists->active;

execlists->active is never NULL (it always points at one of the arrays).
*execlists->active may be NULL.

> +   if (port)
> +   rq = *port;
> +   if (rq)
> +   __intel_context_stats_start(>context->stats,
> +   engine->stats.enabled_at);
> +
> +   for (; (rq = *port); port++)
> engine->stats.active++;
>  
> @@ -2250,6 +2277,7 @@ static void process_csb(struct intel_engine_cs *engine)
> rmb();
>  
> do {
> +   struct i915_request *rq;
> bool promote;
>  
> if (++head == num_entries)
> @@ -2305,7 +2333,11 @@ static void process_csb(struct intel_engine_cs *engine)
>  
> WRITE_ONCE(execlists->pending[0], NULL);
> } else {
> -   GEM_BUG_ON(!*execlists->active);
> +   rq = *execlists->active++;
> +   GEM_BUG_ON(!rq);
> +
> +   GEM_BUG_ON(execlists->active - execlists->inflight >
> +  execlists_num_ports(execlists));
>  
> /* port0 completed, advanced to port1 */
> trace_ports(execlists, "completed", 
> execlists->active);
> @@ -2316,13 +2348,15 @@ static void process_csb(struct intel_engine_cs 
> *engine)
>  * coherent (visible from the CPU) before the
>  * user interrupt and CSB is processed.
>  */
> -   
> GEM_BUG_ON(!i915_request_completed(*execlists->active) &&
> +   GEM_BUG_ON(!i915_request_completed(rq) &&
>!reset_in_progress(execlists));
> -   execlists_schedule_out(*execlists->active++);
>  
> -   GEM_BUG_ON(execlists->active - execlists->inflight >
> -  execlists_num_ports(execlists));
> +   execlists_schedule_out(rq);
> }
> +
> +   rq = *execlists->active;
> +   if (rq)
> +   intel_context_stats_start(>context->stats);
> } while (head != tail);

Actually, we can do this after processing the entire event buf.

if (execlists_active(execlists))
intel_context_stats_start((*execlists->active)->context->stats);

Once we apply the fix in
https://patchwork.freedesktop.org/patch/347934/?series=71809=1

We can in fact do this as a part of set_timeslice() which means we have
all the time-related updates in the same spot.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v3] drm/i915/hdcp: update HDCP CP property as per port authentication state

2020-01-10 Thread Anshuman Gupta
When port is disabled due to modeset crtc disable sequence
or DPMS off, it eventually disables the HDCP encryption
keeping its content protection property to CP_ENABLED.
Since content protection property left at CP_ENABLED by
mistake, HDCP authentication is not attempted at next DDI
enable sequence.
HDCP content property should be updated accordingly
as per port authentication state.

v2:
 - Incorporated the necessary locking. (Ram)
 - Set content protection property to CP_DESIRED only when
   user has not asked explicitly to set CP_UNDESIRED.

v3:
 - Reset the is_hdcp_undesired flag to false. (Ram)
 - Rephrasing commit log and small comment for is_hdcp_desired
   flag. (Ram)

CC: Ramalingam C 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_display_types.h |  6 ++
 drivers/gpu/drm/i915/display/intel_hdcp.c  | 13 -
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 630a94892b7b..a7b4c8324838 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -345,6 +345,12 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;
 
+   /*
+* Track new_conn CP UNDESIRED state as DDI disable
+* code path does't have access to new conn state.
+*/
+   bool is_hdcp_undesired;
+
/* HDCP1.4 Encryption status */
bool hdcp_encrypted;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0fdbd39f6641..7f631ebd8395 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2002,11 +2002,18 @@ int intel_hdcp_disable(struct intel_connector 
*connector)
mutex_lock(>mutex);
 
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_UNDESIRED;
if (hdcp->hdcp2_encrypted)
ret = _intel_hdcp2_disable(connector);
else if (hdcp->hdcp_encrypted)
ret = _intel_hdcp_disable(connector);
+
+   if (hdcp->is_hdcp_undesired) {
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_UNDESIRED;
+   hdcp->is_hdcp_undesired = false;
+   } else {
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   }
}
 
mutex_unlock(>mutex);
@@ -2044,6 +2051,7 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
 {
u64 old_cp = old_state->content_protection;
u64 new_cp = new_state->content_protection;
+   struct intel_connector *intel_conn = to_intel_connector(connector);
struct drm_crtc_state *crtc_state;
 
if (!new_state->crtc) {
@@ -2069,6 +2077,9 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
return;
}
 
+   if (new_cp == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   intel_conn->hdcp.is_hdcp_undesired  =  true;
+
crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
   new_state->crtc);
crtc_state->mode_changed = true;
-- 
2.24.0

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


Re: [Intel-gfx] [RFC 6/8] drm/i915: Expose per-engine client busyness

2020-01-10 Thread Tvrtko Ursulin



On 10/01/2020 13:58, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-01-10 13:30:47)

+static ssize_t
+show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   struct i915_engine_busy_attribute *i915_attr =
+   container_of(attr, typeof(*i915_attr), attr);
+   struct list_head *list = _attr->client->ctx_list;
+   unsigned int engine_class = i915_attr->engine_class;
+   struct i915_gem_context *ctx;
+   u64 total = 0;
+
+   if (i915_attr->no_busy_stats)
+   return -ENODEV;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ctx, list, client_link)
+   total += sw_busy_add(ctx, engine_class);
+   rcu_read_unlock();
+
+   return snprintf(buf, PAGE_SIZE, "%llu\n", total);
+}
+
+static const char *uabi_class_names[] = {
+   [I915_ENGINE_CLASS_RENDER] = "0",
+   [I915_ENGINE_CLASS_COPY] = "1",
+   [I915_ENGINE_CLASS_VIDEO] = "2",
+   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "3",
+};


Hmm. /sys/class/drm/card0/clients/0/busy/0

Ok. I was worried this was 0/0 and so very bland and liable to clash
later.


+
  int
  __i915_drm_client_register(struct i915_drm_client *client,
struct task_struct *task)
  {
 struct i915_drm_clients *clients = client->clients;
+   struct drm_i915_private *i915 =
+   container_of(clients, typeof(*i915), clients);
+   struct intel_engine_cs *engine;
 struct device_attribute *attr;
-   int ret = -ENOMEM;
+   int i, ret = -ENOMEM;
 char idstr[32];
  
 if (!clients->root)

@@ -77,10 +130,71 @@ __i915_drm_client_register(struct i915_drm_client *client,
 if (ret)
 goto err_attr;
  
+   if (HAS_LOGICAL_RING_CONTEXTS(i915)) {

+   client->busy_root =
+   kobject_create_and_add("busy", client->root);
+   if (!client->busy_root)
+   goto err_attr;
+
+   for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) {
+   struct i915_engine_busy_attribute *i915_attr =
+   >attr.busy[i];



if (!intel_engine_lookup_user(i915, i, 0))
continue;

i.e. skip if we don't have any engines of that class in the system.


Yes, thanks.


+
+   i915_attr->client = client;
+   i915_attr->engine_class = i;
+
+   attr = _attr->attr;
+
+   sysfs_attr_init(>attr);
+
+   attr->attr.name = uabi_class_names[i];
+   attr->attr.mode = 0444;
+   attr->show = show_client_busy;
+
+   ret = sysfs_create_file(client->busy_root,
+   (struct attribute *)attr);
+   if (ret)
+   goto err_busy;
+   }
+
+   /* Enable busy stats on all engines. */
+   i = 0;
+   for_each_uabi_engine(engine, i915) {
+   ret = intel_enable_engine_stats(engine);


Hmm. We gave it a global bit in

i915->caps.scheduler & I915_SCHEDULER_CAP_ENABLED.

That'll avoid having to do the individual checking and rollback.


I could add a top level check as a short circuit, but I prefer to check 
return code from intel_enable_engine_stats since it returns one.


Also if new GuC will have I915_SCHEDULER_CAP_ENABLED it will still fail 
to enable engine stats and then fallback to pphwsp has to happen.


Regards,

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


Re: [Intel-gfx] [RFC 5/8] drm/i915: Contexts can use struct pid stored in the client

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 13:30:46)
> From: Tvrtko Ursulin 
> 
> Now that contexts keep their parent client reference counted, we can
> remove separate struct pid reference owned by contexts in favour of the
> one already held by the client.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 13 -
>  drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 10 --
>  drivers/gpu/drm/i915/i915_debugfs.c   |  7 ---
>  drivers/gpu/drm/i915/i915_gpu_error.c |  8 
>  4 files changed, 12 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ba8ccc754f20..758cebb99ba4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -323,7 +323,6 @@ static void i915_gem_context_free(struct i915_gem_context 
> *ctx)
> if (ctx->timeline)
> intel_timeline_put(ctx->timeline);
>  
> -   put_pid(ctx->pid);
> mutex_destroy(>mutex);
>  
> kfree_rcu(ctx, rcu);
> @@ -794,24 +793,20 @@ static int gem_context_register(struct i915_gem_context 
> *ctx,
> WRITE_ONCE(vm->file, fpriv); /* XXX */
> mutex_unlock(>mutex);
>  
> -   ctx->pid = get_task_pid(current, PIDTYPE_PID);
> snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
> -current->comm, pid_nr(ctx->pid));
> +current->comm, pid_nr(client->pid));
>  
> /* And finally expose ourselves to userspace via the idr */
> ret = xa_alloc(>context_xa, id, ctx, xa_limit_32b, GFP_KERNEL);
> -   if (ret) {
> -   put_pid(fetch_and_zero(>pid));
> -   goto out;
> -   }
> +   if (ret)
> +   return ret;
>  
> ctx->client = client = i915_drm_client_get(fpriv->client);
> spin_lock(>ctx_lock);
> list_add_tail_rcu(>client_link, >ctx_list);
> spin_unlock(>ctx_lock);
>  
> -out:
> -   return ret;
> +   return 0;
>  }
>  
>  int i915_gem_context_open(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 879824159646..23421377a43d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -90,16 +90,6 @@ struct i915_gem_context {
>  */
> struct i915_address_space __rcu *vm;
>  
> -   /**
> -* @pid: process id of creator
> -*
> -* Note that who created the context may not be the principle user,
> -* as the context may be shared across a local socket. However,
> -* that should only affect the default context, all contexts created
> -* explicitly by the client are expected to be isolated.
> -*/
> -   struct pid *pid;
> -
> /** link: place with _i915_private.context_list */
> struct list_head link;
> struct llist_node free_link;
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 8f01c2bc7355..bc533501b4e0 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -346,7 +346,8 @@ static void print_context_stats(struct seq_file *m,
> rcu_read_unlock();
>  
> rcu_read_lock();
> -   task = pid_task(ctx->pid ?: file->pid, PIDTYPE_PID);
> +   task = pid_task(ctx->client->pid ?: file->pid,
> +   PIDTYPE_PID);
> snprintf(name, sizeof(name), "%s",
>  task ? task->comm : "");
> rcu_read_unlock();
> @@ -1492,10 +1493,10 @@ static int i915_context_status(struct seq_file *m, 
> void *unused)
> spin_unlock(>gem.contexts.lock);
>  
> seq_puts(m, "HW context ");
> -   if (ctx->pid) {
> +   if (ctx->client->pid) {
> struct task_struct *task;
>  
> -   task = get_pid_task(ctx->pid, PIDTYPE_PID);
> +   task = get_pid_task(ctx->client->pid, PIDTYPE_PID);
> if (task) {
> seq_printf(m, "(%s [%d]) ",
>task->comm, task->pid);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index fda0977d2059..9240327bdb7d 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1235,8 +1235,8 @@ static void record_request(const struct i915_request 
> *request,
> erq->pid = 0;
> rcu_read_lock();
> ctx = rcu_dereference(request->context->gem_context);
> -   if (ctx)
> -   

Re: [Intel-gfx] [PATCH v4 2/7] drm: always determine branch device with drm_dp_is_branch()

2020-01-10 Thread Jani Nikula
On Thu, 29 Aug 2019, Oleg Vasilev  wrote:
> The helper should always be used.
>
> Reviewed-by: Emil Velikov 
> Signed-off-by: Oleg Vasilev 
> Cc: Ville Syrjälä 
> Cc: intel-gfx@lists.freedesktop.org

Pushed patches 1-2 to drm-misc-next, thanks for the patches and review.

BR,
Jani.


> ---
>  drivers/gpu/drm/drm_dp_helper.c | 3 +--
>  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index ffc68d305afe..14320930091b 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -573,8 +573,7 @@ void drm_dp_downstream_debug(struct seq_file *m,
>   int len;
>   uint8_t rev[2];
>   int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
> - bool branch_device = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> -  DP_DWN_STRM_PORT_PRESENT;
> + bool branch_device = drm_dp_is_branch(dpcd);
>  
>   seq_printf(m, "\tDP branch device present: %s\n",
>  branch_device ? "yes" : "no");
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 23908da1cd5d..6da6a4859f06 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2922,7 +2922,7 @@ static bool downstream_hpd_needs_d0(struct intel_dp 
> *intel_dp)
>* FIXME should really check all downstream ports...
>*/
>   return intel_dp->dpcd[DP_DPCD_REV] == 0x11 &&
> - intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
> DP_DWN_STRM_PORT_PRESENT &&
> + drm_dp_is_branch(intel_dp->dpcd) &&
>   intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC 6/8] drm/i915: Expose per-engine client busyness

2020-01-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-10 14:09:09)
> 
> On 10/01/2020 13:58, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-01-10 13:30:47)
> >> +static ssize_t
> >> +show_client_busy(struct device *kdev, struct device_attribute *attr, char 
> >> *buf)
> >> +{
> >> +   struct i915_engine_busy_attribute *i915_attr =
> >> +   container_of(attr, typeof(*i915_attr), attr);
> >> +   struct list_head *list = _attr->client->ctx_list;
> >> +   unsigned int engine_class = i915_attr->engine_class;
> >> +   struct i915_gem_context *ctx;
> >> +   u64 total = 0;
> >> +
> >> +   if (i915_attr->no_busy_stats)
> >> +   return -ENODEV;
> >> +
> >> +   rcu_read_lock();
> >> +   list_for_each_entry_rcu(ctx, list, client_link)
> >> +   total += sw_busy_add(ctx, engine_class);
> >> +   rcu_read_unlock();
> >> +
> >> +   return snprintf(buf, PAGE_SIZE, "%llu\n", total);
> >> +}
> >> +
> >> +static const char *uabi_class_names[] = {
> >> +   [I915_ENGINE_CLASS_RENDER] = "0",
> >> +   [I915_ENGINE_CLASS_COPY] = "1",
> >> +   [I915_ENGINE_CLASS_VIDEO] = "2",
> >> +   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "3",
> >> +};
> > 
> > Hmm. /sys/class/drm/card0/clients/0/busy/0
> > 
> > Ok. I was worried this was 0/0 and so very bland and liable to clash
> > later.
> > 
> >> +
> >>   int
> >>   __i915_drm_client_register(struct i915_drm_client *client,
> >> struct task_struct *task)
> >>   {
> >>  struct i915_drm_clients *clients = client->clients;
> >> +   struct drm_i915_private *i915 =
> >> +   container_of(clients, typeof(*i915), clients);
> >> +   struct intel_engine_cs *engine;
> >>  struct device_attribute *attr;
> >> -   int ret = -ENOMEM;
> >> +   int i, ret = -ENOMEM;
> >>  char idstr[32];
> >>   
> >>  if (!clients->root)
> >> @@ -77,10 +130,71 @@ __i915_drm_client_register(struct i915_drm_client 
> >> *client,
> >>  if (ret)
> >>  goto err_attr;
> >>   
> >> +   if (HAS_LOGICAL_RING_CONTEXTS(i915)) {
> >> +   client->busy_root =
> >> +   kobject_create_and_add("busy", client->root);
> >> +   if (!client->busy_root)
> >> +   goto err_attr;
> >> +
> >> +   for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) {
> >> +   struct i915_engine_busy_attribute *i915_attr =
> >> +   >attr.busy[i];
> > 
> > 
> > if (!intel_engine_lookup_user(i915, i, 0))
> >   continue;
> > 
> > i.e. skip if we don't have any engines of that class in the system.
> 
> Yes, thanks.
> 
> >> +
> >> +   i915_attr->client = client;
> >> +   i915_attr->engine_class = i;
> >> +
> >> +   attr = _attr->attr;
> >> +
> >> +   sysfs_attr_init(>attr);
> >> +
> >> +   attr->attr.name = uabi_class_names[i];
> >> +   attr->attr.mode = 0444;
> >> +   attr->show = show_client_busy;
> >> +
> >> +   ret = sysfs_create_file(client->busy_root,
> >> +   (struct attribute *)attr);
> >> +   if (ret)
> >> +   goto err_busy;
> >> +   }
> >> +
> >> +   /* Enable busy stats on all engines. */
> >> +   i = 0;
> >> +   for_each_uabi_engine(engine, i915) {
> >> +   ret = intel_enable_engine_stats(engine);
> > 
> > Hmm. We gave it a global bit in
> > 
> >   i915->caps.scheduler & I915_SCHEDULER_CAP_ENABLED.
> > 
> > That'll avoid having to do the individual checking and rollback.
> 
> I could add a top level check as a short circuit, but I prefer to check 
> return code from intel_enable_engine_stats since it returns one.

My suggestion was to remove the return code and make it bug out, as we
[can] check before use in i915_pmu.c as well.

> Also if new GuC will have I915_SCHEDULER_CAP_ENABLED it will still fail 
> to enable engine stats and then fallback to pphwsp has to happen.

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


[Intel-gfx] [PATCH] i915: ggtt: include asm/smp.h

2020-01-10 Thread Arnd Bergmann
Splitting up the i915_gem_gtt caused a build failure in some configurations:

drivers/gpu/drm/i915/gt/intel_ggtt.c: In function 'ggtt_restore_mappings':
drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of 
function 'wbinvd_on_all_cpus'; did you mean 'wrmsr_on_cpus'? 
[-Werror=implicit-function-declaration]
   wbinvd_on_all_cpus();
   ^~
   wrmsr_on_cpus

Add the missing header file.

Fixes: 2c86e55d2ab5 ("drm/i915/gtt: split up i915_gem_gtt")
Signed-off-by: Arnd Bergmann 
---
I ran into this bug a few days ago on linux-next. Please just ignore
if it's already fixed in the meantime.
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1a2b5dcde960..9ef8ed85a738 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 
 #include "intel_gt.h"
 #include "i915_drv.h"
-- 
2.20.0

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


  1   2   >